로컬 네트워크에서 전달 된 퍼블릭 IP 주소로 루프백-Hairpin NAT

이것은 헤어핀 NAT (루프백 NAT)에 대한 정식 질문 입니다.

이 질문의 일반적인 형태는 다음과 같습니다.

클라이언트, 서버 및 NAT 라우터가있는 네트워크가 있습니다. 라우터에서 서버로 포트를 전달하므로 일부 서비스를 외부에서 사용할 수 있습니다. 외부 IP를 가리키는 DNS가 있습니다. 로컬 네트워크 클라이언트가 연결되지 않지만 외부 작업이 수행됩니다.

• 왜 이것이 실패합니까?
• 통합 명명 체계 (로컬 및 외부에서 작동하는 DNS 이름)를 만들려면 어떻게해야합니까?

이 질문에는 다른 여러 질문과 병합 된 답변이 있습니다. 그들은 원래 FreeBSD, D-Link, Microtik 및 기타 장비를 참조했습니다. 그러나 그들은 모두 같은 문제를 해결하려고 노력하고 있습니다.

찾고있는 것을 "헤어핀 NAT"라고합니다. 외부 인터페이스에 할당 된 IP 주소에 대한 내부 인터페이스의 요청은 마치 외부 인터페이스에서 온 것처럼 NAT를 사용해야합니다.

필자는 FreeBSD에 익숙하지 않지만 OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html )에 대한 "pf"매뉴얼을 읽고 분할-수평 DNS의 제안 된 솔루션을 사용합니다. DMZ 네트워크 또는 TCP 프록시는 "pf"가 헤어핀 NAT를 지원하지 않는다고 생각합니다.

분할-수평 DNS의 경로를 살펴보고 내부적으로 URL에서 IP 주소를 사용하지 않고 이름을 사용합니다.

이것이 헤어핀 NAT에 대한 정식 질문으로 높아졌기 때문에 현재 받아 들여진 것보다 더 일반적으로 맞는 대답을해야한다고 생각했습니다. 이것은 FreeBSD와 특히 관련이 있습니다.

이 질문은 게이트웨이에서 대상 NAT (DNAT)를 도입하여 외부 사용자가 사용할 수있는 RFC1918 주소 IPv4 네트워크의 서버에서 제공하는 서비스에 적용됩니다. 그런 다음 내부 사용자는 외부 주소를 통해 해당 서비스에 액세스하려고합니다. 패킷은 클라이언트에서 게이트웨이 장치로 전달되어 대상 주소를 다시 쓰고 내부 네트워크에 즉시 다시 주입합니다. 이름 야기주는 게이트웨이 패킷 차종 차례는 약 그것은이 날카로운 헤어핀 NAT 와 유사하여, 머리핀을 차례 .

게이트웨이 장치가 대상 주소를 다시 쓰지만 소스 주소가 아닌 경우 문제가 발생합니다. 서버는 내부 목적지 주소 (자체)와 내부 소스 주소 (클라이언트)를 가진 패킷을 수신합니다. 그러한 주소에 직접 회신 할 수 있다는 것을 알고 있으므로 그렇게합니다. 응답은 직접적이므로 게이트웨이를 통과하지 않으므로 리턴 패킷의 소스 주소를 다시 작성하여 초기 패킷에 대한 인바운드 대상 NAT의 영향을 균형 잡을 기회가 없습니다.

따라서 클라이언트는 외부 IP 주소 로 패킷을 보내지 만 내부 IP 주소 에서 응답을받습니다 . 두 패킷이 동일한 대화의 일부라는 것을 알 수 없으므로 대화가 발생하지 않습니다.

해결책은 이러한 대상 NAT가 필요하고 내부 네트워크에서 게이트웨이에 도달하는 패킷의 경우 일반적으로 소스 주소를 게이트웨이의 주소로 다시 작성하여 인바운드 패킷에서 소스 NAT (SNAT)를 수행하는 것입니다. 그런 다음 서버는 클라이언트가 게이트웨이 자체라고 생각하고 직접 응답합니다. 그러면 게이트웨이는 리턴 패킷에서 소스 주소와 대상 주소를 모두 다시 작성하여 인바운드 패킷에 대한 DNAT 및 SNAT의 영향을 균형있게 조정할 수 있습니다.

클라이언트는 외부 서버와 통신하고 있다고 생각합니다. 서버는 게이트웨이 장치와 통신하고 있다고 생각합니다. 모든 파티는 행복합니다. 이 시점에서 다이어그램이 도움이 될 수 있습니다.

일부 소비자 게이트웨이 장치는 두 번째 NAT 단계가 필요한 패킷을 인식하기에 충분히 밝으며 아마도 헤어핀 NAT 시나리오에서 즉시 사용할 수 있습니다. 다른 사람들은 그렇지 않으며, 그렇지 않을 것이며, 그들이 일을 할 수 없을 것입니다. 서버 결함에 대한 주제가 아닌 소비자 등급 장치에 대한 설명.

적절한 네트워킹 장치는 일반적으로 작동한다고 말할 수 있지만, 관리자를 추측하는 사업이 아니기 때문에 그렇게해야합니다. 리눅스는 iptablesDNAT를하기 위해 사용 합니다 :

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

HTTP 포트의 간단한 DNAT를 내부 서버의 활성화 할 수 192.168.3.11있습니다. 그러나 헤어핀 NAT를 활성화하려면 다음과 같은 규칙이 필요합니다.

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

이러한 규칙은 올바르게 작동하려면 관련 체인의 올바른 위치에 있어야하며, filter체인의 설정에 따라 NAT 트래픽이 흐르도록 추가 규칙이 필요할 수 있습니다. 이러한 모든 토론은이 답변의 범위를 벗어납니다.

그러나 다른 사람들이 말했듯이 헤어핀 NAT를 올바르게 사용하는 것이 문제를 처리하는 가장 좋은 방법은 아닙니다. 가장 좋은 방법은 스플릿-수평 DNS입니다 . 여기서 조직은 요청하는 클라이언트의 위치에 따라 내부 및 외부 사용자를위한 서로 다른 물리적 서버를 가지거나 DNS 서버를 구성하여 요청하는 클라이언트의 주소

여기서 문제는 라우터가 내부 클라이언트 주소를 NAT하지 않는다는 것입니다. 따라서 TCP 핸드 셰이크가 실패합니다.

다음 IP를 가정 해 봅시다

• 클라이언트 : 192.168.1.3
• 서버 : 192.168.1.2
• 라우터 내부 : 192.168.1
• 라우터 외부 : 123.123.123.1

여기에 무슨 일이 일어나고 있습니까?

1. 클라이언트 (192.168.1.3)는 TCP-SYN을 외부 IP, 포트 80 (123.123.123.1:80)으로 보냅니다.
2. 라우터는 포트 전달 규칙을보고 소스 IP (192.168.1.3)를 변경하지 않고 패킷을 서버 (192.168.1.2:80)로 전달합니다.
3. 클라이언트가 외부 IP에서 SYN-ACK를 기다립니다
4. 서버는 같은 서브넷에 있기 때문에 답변을 클라이언트로 직접 보냅니다. 라우터로 패킷을 보내지 않으므로 NAT를 되돌릴 수 있습니다.
5. 클라이언트는 123.123.123.1 대신 192.168.1.2에서 SYN-ACK를받습니다. 그리고 버립니다.
6. 클라이언트는 여전히 123.123.123.1에서 SYN-ACK를 기다렸다가 시간 초과합니다.

어디서나 IP 주소를 하드 코딩하는 대신 split horizon dns를 사용하지 않겠습니까? ext.yourdomain은 외부에서 217.xxx를 가리키고 내부에서 192.xxx를 가리 킵니다.

원래 D- 링크 라우터 인 경우 (예 : Virgin Media의 Rev. D / 펌웨어 버전 1.00VG가 아님)이 문제를 해결하도록 설정을 조정할 수 있어야합니다. (그러나 나는 여러 가지 이유로 이전 포스터의 DD-WRT 제안에 동의합니다!)

1. 라우터의 웹 인터페이스에 로그인
2. 상단의 고급 탭을 클릭하십시오
3. 왼쪽의 방화벽 설정 탭을 클릭하십시오
4. 아래 스크린 샷과 같이 TCP 엔드 포인트 필터링 아래 의 엔드 포인트 독립 라디오 버튼을 클릭하십시오 (또는 D-Link 웹 사이트 의 라우터 에뮬레이터 참조 ).
5. 변경 사항을 저장하다; 넌 끝났어

이 스크린 샷은 Rev. C 모델에서 가져온 것입니다. 약간 다를 수 있습니다.

최근 비슷한 질문에 대답했습니다. Cisco 정적 NAT가 LAN 측에서 작동하지 않고 이것이 정식 질문이라는 것을 깨달았습니다. 여기에 해결책을 요약하겠습니다.

우선 : NAT에 대해 잊어 버리십시오 (가능한 경우). NAT 구성에 대한 질문은 전혀 아닙니다. 인터넷과 LAN 모두에서 NAT 뒤에있는 서버에 액세스하는 것입니다. 두 개의 DNS 영역을 사용하는 것이 실행 가능한 대안이지만 항상 해결책은 아닙니다. 그러나 해결책은 존재하며 매우 간단합니다 (아마도 완벽하지는 않지만).

(1) 서버에서 : 255.255.255.255 마스크를 사용하여 서버의 네트워크 인터페이스에서 공용 IP 주소를 보조 IP 주소로 추가하십시오 (웹 서비스 또는 서버에서 원하는 것은이 IP 주소에서도 수신해야 함). 모든 최신 운영 체제에서는이를 수행 할 수 있습니다 (또는 공용 IP 주소가 할당 된 루프백 인터페이스를 기본 인터페이스에 보조 IP를 추가하는 대신 사용할 수 있음).

(2) LAN 호스트 : 공용 IP 주소에 대한 호스트 경로를 추가하십시오 (예 : Windows 호스트의 경우) 다음 명령을 사용하십시오. route -p add 203.0.113.130 mask 255.255.255.255 192.168.1.11 (DHCP를 사용할 수도 있음 " 고정 경로 '옵션을 사용하여 경로를 배포). 또는 클라이언트와 인터넷 연결 라우터 사이에 (a) L3 스위치 / 라우터가있는 경우이 중간 스위치 / 라우터에서 해당 호스트 경로를 구성하십시오. 클라이언트에.

TCP 3 방향 핸드 셰이크 관련 사용자의 경우 제안 된 구성에서 정상적으로 작동합니다.

피드백을 제공하십시오 (적어도 투표).

비슷한 문제를 가진 사람들의 지평을 넓히기 위해 내 질문에 대답하겠습니다.

ISP에 연락하여 문제 해결을 요청했습니다. 그들이 나에게 제공 한 것은 서버를위한 또 다른 공개 IP 주소입니다. 이제 FreeBSD의 WAN 측에 로컬 트래픽이 있으며 서버의 퍼블릭 IP에 대한 로컬 트래픽으로 인해 더 빠른 처리량을 위해 특정 파이프를 만들었습니다.

기술적 인 관점에서이 문제에 대한 최상의 솔루션은 네트워크에서 IPv6을 활성화하는 것입니다. IPv6이 활성화되면 도메인에 대한 AAAA 레코드를 작성해야합니다. 기존 A 레코드가 라우터 의 외부 IPv4를 가리 키도록 유지하십시오 . 서버 의 IPv6 주소를 가리키는 AAAA 레코드를 작성하십시오 .

IPv6에는 NAT를 피하기에 충분한 주소가 있으므로 IPv6에 헤어핀 NAT가 필요하지 않습니다. IPv6를 활성화하고 AAAA 레코드를 생성 하면 RFC 8305 를 지원하는 모든 클라이언트 가 IPv4보다 먼저 IPv6을 시도합니다. 즉, 클라이언트가 사용하지 않기 때문에 IPv4 용 헤어핀 NAT도 필요하지 않습니다.

전 세계 대부분이 IPv6를 활성화 할 때까지 나가는 연결 및 들어오는 연결을위한 포트 전달을 위해서는 기존 IPv4 NAT가 여전히 필요합니다.

더 빠릅니다.

IPv6을 사용하면 헤어핀 NAT보다 성능이 향상됩니다.

헤어핀 NAT를 사용하면 클라이언트가 스위치를 통해 라우터로 패킷을 보내면 라우터는 두 번의 변환을 수행하고 마지막으로 스위치를 통해 패킷을 서버로 보냅니다. 서버에서 클라이언트로가는 패킷은 전체 경로를 반대로 거칩니다.

IPv6을 사용하면 NAT를 피할 수 있으며 대신 클라이언트와 서버 간 스위치를 통해 패킷이 직접 전송됩니다. 이것은 왕복 여행에서 스위치를 통과하는 패스 수를 4에서 2로 줄이고 라우터를 통한 2 번의 트립과 라우터가 수행 한 4 개의 변환을 피한다는 것을 의미합니다. 이것은 더 나은 성능으로 해석됩니다.

라우터와 같은 상자에 내장 된 스위치를 사용하더라도 마찬가지입니다.

ISP에 IPv6이 없으면 어떻게합니까?

IPv6를 지원하지 않는 ISP를 사용하는 경우 해당 네트워크에서 서버를 호스팅해야하는지에 대한 질문을합니다. ISP가 현재 IPv6을 지원하지 않는 경우 수행 할 작업에 대한 제안입니다.

먼저 ISP에게 IPv6 이 필요하다고 알리십시오 . 그리고 IPv6 프로토콜은 20 년 동안 사용되어 왔기 때문에 오랫동안 지원하지 않았다는 사실을 상기 시키십시오. ISP가 충분하지 않으면 다른 ISP를 심각하게 찾기 시작합니다.

IPv6을 지원하는 ISP를 찾으면 전환 기간 동안 두 ISP 모두에서 실행할 수 있습니다. 새 ISP에 연결된 라우터에서는 LAN 쪽에서 IPv4를 비활성화 한 다음 두 라우터의 LAN 쪽을 동일한 스위치에 연결할 수 있습니다. IPv4 및 IPv6은 두 개의 독립적 인 프로토콜이므로 연결이 다른 라우터를 통과하더라도 전혀 문제가되지 않습니다. 부작용으로 연결 중 하나에 정전이 발생하면 어느 정도의 중복성이 제공됩니다.

IPv6을 지원하는 ISP를 찾을 수 없으면 서버를 호스팅 시설로 옮기는 것을 고려해야합니다. 호스팅 시설의 서버를 사용하면 지리적 위치에 덜 의존하기 때문에 공급자간에 경쟁이 치열해져 귀하의 요구를 충족시키는 서버가 있는지 확인하는 데 도움이됩니다.

서버를 호스팅 시설로 옮기더라도 클라이언트에 IPv6가 제공되지는 않지만 서버를 옮기면 더 이상 헤어핀 NAT에 연결할 필요가 없습니다.

하지 말아야 할 것

IPv6 트래픽을 라우팅 할 방법이 없으면 IPv6을 켜고 AAAA 레코드를 작성하지 마십시오. ISP가 IPv6을 지원하지 않지만 LAN에서 IPv6을 활성화하도록 선택하고 (RFC 4193 주소를 사용하는 경우) AAAA 레코드를 작성하면 LAN의 클라이언트가 LAN의 서버에 도달 할 수 있습니다. 그러나 LAN과 외부 세계 간의 통신은 먼저 IPv6 (작동하지 않을 것)을 시도하며, 조금 느리거나 최악의 경우에는 발생하지 않는 IPv4로 다시 의존하게됩니다.

나는이 질문을하기 때문에 (참조 나는 그것의 외부 IP를? 사용하여 내부 방화벽을 반드시 NAT 네트워크 서비스에 액세스하려면 어떻게 여기에 리디렉션했지만 답은 여기에 제공하지 않았다) 솔루션 (일반 달리 설명을 하자) 내 iptables여기에 내 Linux ( 구체적인) 솔루션을 제공하여 모든 사람이 몇 시간의 실험을 절약 할 수 있습니다. 이 파일은 iptables-restore형식이며 IP 주소를 직접 편집 한 후 iptables로 직접 읽을 수 있습니다. 이것은 웹 서버 (포트 80) 및 IPv4 전용입니다. IPv6 및 SSL (포트 443)의 규칙은 유사합니다.

# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

교체 lan.local, web.local및 web.public.com로컬 네트워크에 (예를 들면. 10.0.x.0 / 24), 웹 서버의 로컬 IP (예 : 10.0.1.2) 및 라우터의 공개 IP (예. 4.5.6.7). -4는 동일한 파일에서 IPv6 및 IPv4 규칙을 허용하기 위한 것 입니다 (이러한 행은 무시 됨 ip6tables). 또한 IPv6 주소에 포트 선언이 포함 된 경우 [브래킷]에 넣어야합니다 (예 :) [fe0a:bd52::2]:80.

이것들은 이 질문의 설명 을 실제로 구현 하려고 할 때 머리카락을 뽑아 낸 모든 것입니다 . 나는 아무것도 생략하지 않기를 바랍니다.

여기에 의견이 특정 문제를 해결하지 못 했으므로 여기에 답변을 추가하겠습니다. 나는 그것이 불쾌한 리눅스 커널 버그에 부딪 혔기 때문인 것으로 생각된다. 설정은 다음과 같습니다

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

복잡한 그림에도 불구하고 다른 의견에서 다루는 상황에 대한 유일한 관련 변경 사항은 소프트웨어 브리지 인 br0의 추가입니다. 게이트웨이 박스는 LAN의 무선 액세스 포인트이기 때문에 존재합니다.

우리의 게이트웨이 박스는 여전히 LAN상의 머신에 대한 NAT 업무를 수행하고 있습니다. 이더넷 포트는 1 개뿐이므로 헤어핀 NAT를 수행해야합니다. 나는 그것이 다른 의견에 주어진 iptables 규칙과 함께 작동해야한다고 생각하지만 Linux 커널 4.9에서는 적어도 그렇지 않습니다. 4.9 미만에서는 게이트웨이 박스가 인터넷에 액세스 할 수 있지만 LAN상의 머신은 NAT를 통해 액세스 할 수 없습니다.

tcpdumpeth0에 도달하는 들어오는 패킷에 대한 응답을 보여 주지만 br0에서 벗어나지 않습니다. 이 명령을 실행하면 다음이 수정됩니다.

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

이 명령이 실행되기 전에 들어오는 패킷은 커널 기본 동작에 따라 처리됩니다. 즉, 브리지에 전달한 다음 커널의 라우팅 모듈을 전달합니다. 이 명령은 LAN에서 전송되지 않은 패킷이 브리지를 우회하고 직접 라우팅으로 이동하도록하므로 브리지가 패킷을 삭제할 기회를 얻지 못합니다. 브로드 캐스트 및 멀티 캐스트 주소를 브리지해야합니다. 그렇지 않으면 DHCP 및 mDNS와 같은 기능이 작동하지 않습니다. IPv6을 사용하는 경우 해당 규칙도 추가해야합니다.

다음을 사용하여 문제를 해결하려는 유혹을받을 수 있습니다.

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

나는 정말 유혹을 받았다-그것은 나의 첫 번째 시도였다. 내가 LAN에서 기계를 사용하자마자 인터넷에 액세스 할 수 있었으므로 잠시 동안 작동합니다. 그런 다음 다음이 발생했습니다 (실험을 반복하지는 않았습니다).

1. LAN에서 게이트웨이로의 핑 시간은 게이트웨이 상자가 LAN에서 액세스 할 수 없을 때까지 0.1ms에서 0.2ms, 0.4ms, 0.8ms, 2ms 등으로 증가하여 약 10 초 간격으로 두 배가되었습니다. 그것은 패킷 폭풍처럼 제련되었지만 STP는 모든 곳에서 켜졌습니다.
2. 모든 무선 액세스 포인트가 사망 한 지 얼마되지 않아
3. 무선으로 발생한 상황을 진단하려고 시도하는 동안 모든 IP 전화가 재부팅되었습니다.
4. 그 후 얼마되지 않아 유선 기계는 LAN과의 모든 연결을 잃었습니다.

유일한 방법은 건물의 모든 기계를 재부팅하는 것입니다. 한 가지 예외는 재부팅 할 수없는 하드웨어 스위치였습니다. 전원을 껐다 켜야했습니다.

정식 질문입니다. Sonicwall 라우터가 있으면 대답하겠습니다.

알아야 할 표현은 NAT 루프백 정책입니다.

이 문서에서는 SonicWall LAN의 호스트가 서버의 공용 IP 주소를 사용하여 SQWLAN의 서버에 FQDN에 액세스하는 방법을 설명합니다. 기본 LAN 서브넷이 10.100.0.0 / 24이고 기본 WAN IP가 3.3.2.1 인 NSA 4500 (SonicOS Enhanced) 네트워크를 상상해보십시오. 고객을위한 웹 사이트가 있고 호스트 이름이이라고 가정 해 봅시다. 외부인이 웹 사이트에 액세스 할 수 있도록 필요한 정책 및 규칙을 이미 작성했지만 실제로는 개인용 서버 10.100.0.2에서 실행되고 있습니다. 이제 당신이 IP가 10.100.0.200 인 개인용 랩톱을 사용하는 사람이라고 상상해보십시오. 랩톱이 이동 중에도 동일한 작업을 수행하므로 공개 이름을 사용하여 서버에 연결하려고합니다. 비공개로 앉아 http://www.example.com을 요청하는 경우>, 루프백은 서버가 실제로 로컬 IP 주소에서 바로 옆에 있더라도 작동 할 수있게합니다.

이 기능을 사용하려면 NAT 반영 또는 헤어핀이라고도하는 NAT 루프백 정책을 만들어야합니다.

WAN 인터페이스의 IP 주소를 사용하는 루프백 정책

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

sonicwall은 연락하려는 외부 서비스를 인식하고 서버 내부 주소에 맞게 대상 주소를 다시 작성하므로 컴퓨터와 투명합니다.

PF를 사용하는 FreeBSD에서는 다음과 같이 쉽습니다 (pf.conf 파일에서).

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8은 내부 웹 서버입니다.