mikrotik을 운영하면서 내부 내트워크에 dns서버를 설치하고 운영하면서 npm을 추가하여 여러개의 도메인을 설정하여 사용하고있음. 그러나 외부에서 도메인으로 접속이 가능하지만 내부에서 도메인을 연결하려 하면 되지 않음. 그 원인을 모르겠고, 몇번 질의를 통해 시도하였으나, 지금까지 되지 않음. 해결할수 있을까?

마이크로틱(MikroTik) 환경에서 외부 접속은 되는데 내부에서 도메인으로 접속되지 않는 현상은 네트워크 엔지니어링에서 매우 전형적인 이슈입니다. 이 문제는 보통 'Hairpin NAT' 또는 **'NAT Loopback'**이라고 불리는 메커니즘이 설정되지 않았을 때 발생합니다.

원인과 해결 방법을 단계별로 명확하게 정리해 드릴게요.

1. 원인: 왜 내부에서는 안 될까?

외부 접속 시: 외부 사용자 → 공인 IP(MikroTik) → 포트 포워딩 → 내부 서버 (정상)
내부 접속 시: 내부 사용자 → 도메인 질의(내부 DNS 또는 외부 DNS) → 공인 IP 응답 받음 → 공유기(MikroTik)로 패킷 전송.
문제 발생: MikroTik은 내부에서 온 패킷이 다시 자신의 공인 IP를 향할 때, 이를 내부 서버로 다시 돌려보내야 한다는 것을 모릅니다. 패킷이 공유기에서 길을 잃거나 차단됩니다.

2. 해결 방법 1: Hairpin NAT 설정 (가장 확실한 방법)

MikroTik의 방화벽 설정에서 내부에서 공인 IP로 나가는 트래픽을 다시 내부 서버(Nginx Proxy Manager, NPM)로 돌려주는 규칙을 추가해야 합니다.

터미널(Winbox -> New Terminal)에 아래 명령어를 복사해 넣으세요:

(단, 192.168.88.0/24는 본인의 실제 내부 네트워크 대역으로, 192.168.88.2는 NPM 서버의 IP로 수정하세요.)

Bash

/ip firewall nat
add chain=srcnat src-address=192.168.88.0/24 dst-address=192.168.88.2 \
    protocol=tcp dst-port=80,443 out-interface-list=LAN \
    action=masquerade comment="Hairpin NAT for NPM"

src-address: 내부 PC들이 속한 IP 대역
dst-address: NPM(Nginx Proxy Manager) 서버의 내부 고정 IP
out-interface-list: 내부 네트워크가 속한 인터페이스 리스트 (보통 bridge 또는 LAN)

3. 해결 방법 2: Split-Horizon DNS (내부 DNS 활용)

이미 내부 DNS 서버를 운영 중이시라면, 내부 네트워크 안에서만 해당 도메인이 공인 IP가 아닌 NPM 서버의 내부 IP(192.168.x.x)를 가리키도록 설정하는 방법입니다.

내부 DNS 서버(AD, Pi-hole, AdGuard 등) 설정:
- example.com의 A 레코드를 공인 IP가 아닌 NPM 서버의 내부 IP로 등록합니다.
장점: 패킷이 공유기를 거치지 않고 바로 NPM으로 가기 때문에 속도가 빠르고 공유기 부하가 적습니다.
주의사항: 모든 도메인을 일일이 내부 DNS에 등록해줘야 하며, HTTPS 인증서(Let's Encrypt) 갱신 시 NPM이 포트 80을 통해 외부와 통신하는 데 지장이 없어야 합니다.

4. 해결 방법 3: MikroTik DNS Static 설정

만약 별도의 DNS 서버 설정이 번거롭다면 MikroTik 자체 DNS 기능을 이용할 수도 있습니다.

IP > DNS > Static 메뉴로 들어갑니다.
사용 중인 도메인(example.com)을 추가하고, Address에 NPM 서버의 내부 IP를 적습니다.
내부 PC들의 DNS 서버가 MikroTik IP로 설정되어 있어야 작동합니다.

그래도 접속이 안되

Hairpin NAT 설정이나 DNS 설정을 시도했음에도 여전히 접속이 안 된다면, MikroTik의 방화벽 규칙 순서나 Bridge 설정, 또는 NPM(Nginx Proxy Manager) 자체의 수신 차단 문제일 가능성이 높습니다.

문제를 확실히 해결하기 위해 아래 4가지 체크포인트를 순서대로 점검해 보세요.

1. MikroTik NAT 규칙의 '순서' 확인 (매우 중요)

MikroTik에서 방화벽 규칙은 위에서 아래로 실행됩니다. 만약 일반적인 masquerade 규칙이 Hairpin NAT 규칙보다 위에 있으면 작동하지 않을 수 있습니다.

확인법: IP > Firewall > NAT 탭에서 **Hairpin NAT 규칙을 맨 위(0번 또는 1번)**로 드래그해서 올려보세요.
이유: 일반 인터넷 공유 규칙이 먼저 가로채기 전에 특정 내부 트래픽을 먼저 가로채서 처리해야 하기 때문입니다.

2. Bridge Settings에서 'Use IP Firewall' 체크

MikroTik은 기본적으로 브리지(내부 포트들) 간의 통신을 L2(레이어 2)에서 처리합니다. Hairpin NAT는 L3(IP 레벨) 규칙이므로, 브리지 통신도 방화벽을 거치게 설정해야 할 때가 있습니다.

설정 경로: Bridge -> Settings -> Use IP Firewall 항목에 체크가 되어 있는지 확인하세요.
(이미 체크되어 있다면 그대로 두시고, 안 되어 있다면 체크 후 테스트해 보세요.)

3. NPM 서버가 '게이트웨이'를 MikroTik으로 보고 있는가?

내부 서버(NPM)가 응답을 보낼 때, 요청이 들어온 경로로 되돌려 보내야 합니다.

NPM 서버의 **기본 게이트웨이(Default Gateway)**가 MikroTik의 내부 IP(예: 192.168.88.1)로 정확히 잡혀 있는지 확인하세요.
NPM 서버 자체 방화벽(Ubuntu의 ufw 등)에서 내부 대역폭의 80, 443 포트 접근을 허용하고 있는지 확인하세요.

4. '가장 확실한' Hairpin NAT 스크립트 재적용

기존에 입력하신 규칙이 복잡하다면, 가장 단순하고 강력한 아래 방식을 터미널에 입력해 보세요. (IP 대역만 본인 환경에 맞게 수정하세요)

Bash

# 1. 내부에서 공인IP로 들어오는 요청을 NPM으로 토스 (DST-NAT)
/ip firewall nat
add chain=dstnat dst-address-type=local protocol=tcp dst-port=80,443 \
    src-address=192.168.0.0/16 action=dst-nat to-addresses=NPM서버IP

# 2. 돌아가는 패킷이 길을 잃지 않게 주소 변환 (SRC-NAT)
add chain=srcnat src-address=192.168.0.0/16 dst-address=NPM서버IP \
    protocol=tcp dst-port=80,443 action=masquerade

참고: 192.168.0.0/16은 192.168.x.x 전체 대역을 포함하므로 안전합니다.

마지막으로 확인해 주세요

지금 접속을 시도할 때 어떤 에러 메시지가 뜨나요?

"연결 거부(Connection Refused)": 포트는 찾았으나 NPM에서 거절함 (NPM 설정 문제)
"응답 시간 초과(Timeout)": 패킷이 아예 목적지를 못 찾음 (MikroTik NAT/방화벽 문제)
"DNS를 찾을 수 없음": 도메인 자체가 IP로 변환이 안 됨 (DNS 서버 문제)

에러 메시지나 현재 MikroTik의 IP > Firewall > NAT 설정 화면을 텍스트로 복사해 주시면 더 정확한 진단이 가능합니다. 어떤 에러가 뜨나요?

7.4 KiB Raw Blame History