더 많은 조직에서 NAT 내부 핀을 허용하기 위해 내부-내부 NAT 또는 유사한 솔루션을 사용하지 않는 이유는 무엇입니까?

내부-내부 NAT 일명 NAT 루프백은 내부 인터페이스의 컴퓨터에서 ASA 또는 유사한 장치의 외부 인터페이스에있는 웹 서버에 액세스 할 때 헤어핀 NAT 문제를 해결합니다. 이렇게하면 DNS 관리자가 공개 주소로 NAT 된 서버에 해당하는 RFC1918 주소가있는 중복 내부 DNS 영역을 유지 관리하지 않아도됩니다. 저는 네트워크 엔지니어가 아니므로 뭔가 빠졌을 지 모르지만 구성하고 구현하는 것은 쉬운 일이 아닙니다. 비대칭 라우팅은 문제가 될 수 있지만 쉽게 완화됩니다.

필자의 경험에 따르면 네트워크 관리자 / 엔지니어는 시스템 사람들이 NAT 헤어핀을 올바르게 처리하도록 방화벽을 구성하는 대신 split-dn을 실행하는 것을 선호합니다. 왜 이런거야?

내가하지 않는 몇 가지 이유가 있습니다.

• 필요하지 않은 경우 DMZ 라우터 및 방화벽에 추가 부담을주는 이유는 무엇입니까? 대부분의 내부 서비스는 DMZ가 아니라 일반 회사 영역에 있으며 DMZ에는 원격 액세스를위한 프록시 서비스가 있습니다. 내부에서 내부로 nat를 수행하면 DMZ에 더 많은 부하가 가해지며,이 경우에는 중요합니다.
• DNAT + SNAT를 수행하지 않으면 비정형 라우팅이 이루어지며 이는 올바른 방법으로 까다 롭습니다. 따라서 SNAT하고 소스 IP 정보를 잃게됩니다. 그러나 문제 해결을 위해 소스 IP를 사람들에게 연결하는 것은 피의 유용합니다. 또는 어리석은 경우 때때로 nerfshooting 목적. "이 IP가 인증되지 않은 서비스 X에서 이상한 일을하고 있습니다" "아, imap 서버가 누구인지 로그를 보자".

분명히 이것에 대한 명확한 대답 은 없지만 여러 가지 이유를 생각할 수 있습니다.

1. 우아함 : NAT는 처음에는 매우 우아하지 않지만 IPv4의 제한된 주소 공간이 필요합니다. NAT를 피할 수 있다면 그렇게 할 것입니다. IPv6을 사용하면 문제가 해결되지 않습니다.
2. 복잡성 : 특히 모든 보안 경계를 생성하는 단일 "코어"라우터가없는 경우 필터 구성이 까다로울 수 있습니다. 또는 거의 모든 라우터 장치에 NAT 규칙을 적용하고 유지해야합니다.
3. 참조 : 방화벽 관리자가 다른 서버 관리자 팀과 다른 사람이라면 도달하기 어려울 수 있습니다. 방화벽 관리자의 백 로그 (또는 휴가)에 의해 변경이 지연되지 않도록 동일한 팀에서 책임을 유지하는 옵션이 선택됩니다.
4. 이식성 및 일반적인 관행 : DNS보기를 사용하는 것은이 문제를 해결하기 위해 "모두가 알고있는 것"입니다. 모든 경계 라우터가 간단한 방식으로 루프백 NAT를 지원하는 것은 아니며, 특정 환경에서 올바르게 설정하는 방법을 아는 사람이 적습니다. 네트워크 문제를 해결할 때 승무원은 분명히 관련이없는 문제를 쫓을 때도 ​​헤어핀 NAT 구성과 그 의미에 대해 알아야합니다.

면책 조항-이것은 화염 미끼 답변입니다.

이와 같은 솔루션을 피할 수있는 일반적인 이유 는 네트워크 엔지니어 측의 NAT에 대한 비합리적인 두려움 / 증오 때문입니다 . 이에 대한 토론의 예를 보려면 다음을 확인하십시오.

• http://packetpushers.net/show-86-connect-to-the-ipv6-internet-for-free-using-tunnelbroker-net/
• http://networkingnerd.net/2012/04/02/ipv6-nat-and-the-sme-a-response/ (Tom의 블로그는 여전히 열렬한 NAT / IPv6 토론을 계속 유치하고있는 것으로 보입니다)
• http://libertysys.com.au/blog/nat-is-evil-but-not-bad (내 블로그)

내가 알 수 있듯이, 이러한 두려움의 많은 부분은 Cisco의 NAT 구현이 나쁘다는 것에서 비롯된 것입니다. 나쁜 "세계관, 그와 그녀는 완벽하게 이해하고 실제로 솔루션을 단순화하는 이와 같은 명백한 예를 볼 수 없습니다.

당신은 간다-당신의 마음의 내용으로 downvote! :-)

내 추측은 :

1. 분할 DNS는 더 쉽게 이해됩니다.
2. NAT 헤어핀은 라우터의 리소스를 사용하지만 split-dn은 그렇지 않습니다.
3. 라우터에는 split-dns 설정을 거치지 않는 대역폭 제한이있을 수 있습니다.
4. 라우팅 / NAT 단계를 피하면 Split-dn의 성능이 항상 향상됩니다.

헤어핀 NAT의 장점은

• 일단 설정되면 작동합니다.
• 랩톱 용 DNS 캐시와 관련된 문제는 업무용 네트워크와 공용 인터넷간에 이동하지 않았습니다.
• 서버의 DNS는 한 곳에서만 관리됩니다.

내부 서버에 대한 트래픽 요구 사항이 적은 소규모 네트워크의 경우 헤어핀 NAT를 사용합니다. 서버에 많은 연결이 있고 대역폭과 대기 시간이 중요한 대규모 네트워크의 경우 split-dn을 사용하십시오.

필자의 관점에서 볼 때 이것은 Cisco Pix에서 ASA 전환으로 약간 변경되었습니다. alias명령을 잃어 버렸습니다 . 일반적으로 Cisco 방화벽의 내부 인터페이스에서 외부 주소에 액세스하려면 일종의 속임수가 필요합니다. 외부 IP에서 내부 서버에 어떻게 접근합니까?를 참조하십시오.

그러나 항상 내부 DNS 영역을 복제 할 필요는 없습니다. NAT 문에 구성된 경우 Cisco ASA는 외부 주소에 대한 DNS 쿼리를 내부 주소로 리디렉션 할 수 있습니다. 그러나 저는 그 세분성을 확보하고 방화벽 단계보다 한 곳에서이를 관리 할 수 ​​있도록 퍼블릭 DNS 영역의 내부 영역을 유지하는 것을 선호합니다.

일반적으로 환경 (메일, 웹, 몇 개의 공공 서비스) 내에이 서버를 필요로하는 서버는 거의 없으므로 큰 문제가되지 않았습니다.

몇 가지 이유를 생각할 수 있습니다.

1. 많은 조직에서 내부 DNS 정보를 모두 전세계에 게시하고 싶지 않아서 이미 DNS를 분할했기 때문에 공용 IP를 통해 노출되는 몇 개의 서버를 처리하는 것은 별다른 노력이 아닙니다.
2. 조직과 네트워크의 규모가 커짐에 따라 내부 직원을 서비스하는 시스템과 외부 서비스를 제공하는 서버를 분리하는 경우가 많으므로 내부 사용을 위해 외부 시스템으로 라우팅하는 것이 훨씬 더 긴 네트워크 경로 일 수 있습니다.
3. 중간 장치가 패킷을 수정하는 횟수가 적을수록 대기 시간, 응답 시간, 장치로드 및 문제 해결에있어 더 좋습니다.
4. NAT 장치가 패킷 헤더를 넘어서지 않고 새 IP 주소로 데이터를 수정해도 NAT가 여전히 깨지는 프로토콜이 있습니다. 그것이 단지 제도적 기억의 경우 일지라도, 특히 그들이 그들이 100 % 확실하지 않은 프로토콜을 다루는 경우, 사람들이 그것을 피하는 것이 유효한 이유입니다.

NAT 루프백을 사용하려는 경우 NAT 장치가 스푸핑 된 소스 주소를 처리하는 방법이 약간 걱정됩니다. 패킷이 들어온 인터페이스를 확인하지 않으면 WAN에서 내부 주소를 스푸핑하고 내부 주소로 서버로 패킷을 보낼 수 있습니다. 회신을받을 수 없지만 내부 주소를 사용하여 서버를 손상시킬 수 있습니다.

NAT 루프백을 설정하고 DMZ 스위치에 연결 한 다음 스푸핑 된 내부 소스 주소로 패킷을 보냅니다. 수신 된 서버 로그를 확인하십시오. 그런 다음 커피 숍에 가서 ISP가 스푸핑 된 주소를 차단하고 있는지 확인합니다. NAT 라우터가 소스 인터페이스를 확인하지 않는 것을 발견 한 경우 ISP가 확인하더라도 NAT 루프백을 사용하지 않을 수 있습니다.