대칭 NAT 및 UDP 홀 펀칭

8

이 질문을 읽었 지만 대칭 NAT에 대한 설명이 충분하지 않습니다.

누군가가 다음 단락을 이해하도록 도와 줄 수 있습니까?

대칭 NAT 에 대해 이것을 읽었습니다 .

동일한 내부 호스트가 동일한 소스 주소 및 포트를 사용하지만 패킷이 다른 패킷을 보내는 경우 동일한 내부 IP 주소 및 포트에서 특정 대상 IP 주소 및 포트로의 각 요청은 고유 한 외부 소스 IP 주소 및 포트에 매핑됩니다. 대상에 다른 매핑이 사용됩니다. 내부 호스트에서 패킷을받는 외부 호스트 만 패킷을 다시 보낼 수 있습니다.

http://en.wikipedia.org/wiki/Network_address_translation#Types_of_NAT

그리고 UDP 홀 펀칭에 대한 :

UDP 홀 펀칭은 대기업 네트워크에서 발견되는 대칭 NAT 장치 (양방향 NAT라고도 함)에서 작동하지 않습니다. 대칭 NAT에서, 잘 알려진 STUN 서버로의 연결과 관련된 NAT의 맵핑은 잘 알려진 서버로부터 데이터를 수신하는 것으로 제한되므로, 잘 알려진 서버가 보는 NAT 맵핑은 엔드 포인트에 유용한 정보가 아닙니다.

http://en.wikipedia.org/wiki/UDP_hole_punching

그러나 나는 그것을 정말로 흡수하지 않습니다. 클라이언트가 통신을 시작하는 클라이언트-서버 응용 프로그램에서 NAT 장치가 명시 적으로 허용하지 않는 한 서버가 다른 방식으로 통신 할 수 없다는 느낌이 들었습니다. 나는 그것이 왜 그런지 이해하지 못합니다. 가능하다면이 설명을 약간 단순화시켜 주시겠습니까?

우리의 환경에서 잘 알려진 원격 지원 도구를 잘 알려진 소프트웨어 공급 업체가 우리를 지원하기 위해 사용할 수없는 문제가 있습니다. 클라이언트는 프록시를 인식하지만 일부 공명의 경우 클라이언트를 사용하지 않고 포트 1153의 UDP를 통해 완전히 다른 작업을 수행하는 것이 좋습니다.

— 남자
소스

1

대답하기 전에 UDP 홀 펀칭이 대칭 NAT에서 작동하지 않는 이유를 알고 싶거나 특정 문제에 대해 질문하고 있습니까? 귀하의 문제가 반드시 관련이있는 것은 아니기 때문에 궁금합니다.

— TheCleaner

좋아, 아마 둘 다 설명 할 수 있니? 왜 작동하지 않는지와 왜 내 문제가 관련이없는 것 같습니다.

— john

대화방을 만들고 싶다면 대화방부터 시작하겠습니다 ... 시간이 조금있어 더 쉬울 수 있습니다. 나중에 여기에서 답변으로 설명을 잘라내어 붙여 넣습니다.

— TheCleaner

6

우리의 채팅에서 ... 그래서 다른 사람들은 완전한 대화를 얻지 못할 수도 있지만 기본 사항은 여기 있습니다.

기본 NAT = source address:port >> external address:port >> NAT>> new source address:port >> external address port

대칭 NAT를 사용하면 정적 매핑이며 매번 소스와 대상 모두에서 동일합니다.

예: 192.168.100.5:34983 going to 4.2.2.2:53 then REQUIRE it to be 216.222.222.222:44444 with destination 8.8.8.8:333333

"클라이언트가 통신을 시작하는 클라이언트-서버 응용 프로그램에서 NAT 서버가 명시 적으로 허용하지 않는 한 서버는 다른 방식으로 다시 통신 할 수 없습니다."

당신이 말한 그 부분은 올바르지 않습니다 .

클라이언트가 통신을 시작하는 클라이언트-서버 응용 프로그램에서) 서버는 소스가 세션에 사용 된 포트를 통해 세션을 설정 한 후 다른 방법으로 다시 통신 할 수 있습니다.

2.2.2.2:43424가 5.5.5.5:80으로 이동하고 5.5.5.5:80이 세션이 설정되면 2.2.2.2:43424로 정보를 다시 보내는 것을 의미합니다. 문장에서 ... 세션은 목적지와 패킷 / 정보 / 그래픽 / 어떤 것에도 응답하지 않는 대상과의 소스 통신 만 가능합니다.

"우리는 잘 알려진 원격 지원 도구를 잘 알려진 소프트웨어 공급 업체가 우리에게 지원을 제공하는 데 사용할 수없는 문제가 있습니다. 클라이언트는 프록시를 인식하지만 일부는 공감할 수 있습니다. "사용하지 말고 포트 1153의 UDP를 통해 완전히 다른 작업을 수행하지 않는 것이 좋습니다."

그들은 다른 포트를 사용하도록 요청하기 때문에 Logmein / Teamviewer / 포트 수준에서 무엇이든 단순히 차단하기 때문에 1153에서 허용하거나 통신하면 자체 IT 제한을 우회 할 것이라고 생각합니다 ... 어떤 앱이나 세부 사항을 자세하게 알지 않고도 생각할 수 있습니다. 대칭 NAT 또는 UDP 홀 펀칭과는 아무 관련이 없습니다.

지원 도구와 함께 어떤 원격 지원 도구를 사용하는지 또는 그들과 함께 작업하여 원하는 도구를 사용하는 방법을 결정하는 것이 좋습니다. 특정 포트 NAT / 규칙을 의미하는 경우 해당 포트 NAT 및 규칙과 협력하여 해당 부분을 파악해야합니다.

모두가 도움이되기를 바랍니다.

— 청소부
소스

원격 지원 도구는 Log Me In이며 일부 타사 공급 업체에서 지원을 위해 사용합니다. 회사 방화벽의 트래픽을 허용했으며 트래픽이 방화벽을 통과하는 것을 볼 수있었습니다. 그래도 아무것도 돌아 오지 않았습니다. 방화벽을 통과 할 수있는 방법이 거의 없거나 원격 서버가 리턴 통신을 보낼 위치를 결정할 수 없었습니다.

— john

우리는 또한 프록시를 가지고 있기 때문에 어떤 식 으로든 방해가 될 수 있습니다.

— john

아웃 바운드 "허용 정책"이있는 경우, 측에서 트래픽을 시작하고 트래픽이 올바른 NAT 정보로 원격 당사자에게 도달하는 경우 작동합니다. 여기도 참조하십시오 : help.logmein.com/… 그러나이 문제를 해결하려면 컨설팅 또는 더 많은 현장 전문 지식이 필요할 수 있습니다.

— TheCleaner

4

여기에 이미지 설명을 입력하십시오

Wikipedia "Network address translation"페이지에서 찍은 사진을보십시오.

"Full Cone NAT"에서

내부 주소 (iAddr : iPort)가 외부 주소 (eAddr : ePort)에 매핑되면 iAddr : iPort의 모든 패킷이 eAddr : ePort를 통해 전송됩니다.
외부 호스트는 패킷을 eAddr : ePort로 보내어 iAddr : iPort로 패킷을 보낼 수 있습니다.

대칭 NAT에서

동일한 내부 IP 주소 및 포트에서 특정 대상 IP 주소 및 포트로의 각 요청은 고유 한 외부 소스 IP 주소 및 포트에 매핑됩니다. 동일한 내부 호스트가 동일한 소스 주소와 포트를 사용하지만 다른 대상으로 패킷을 보내는 경우 다른 매핑이 사용됩니다.
내부 호스트에서 패킷을받는 외부 호스트 만 패킷을 다시 보낼 수 있습니다.

이제 UDP 홀 펀치가 대칭 NAT에서 작동하지 않는 이유에 대해 설명하겠습니다. Server1은 STUN Server이고 Server 2는 다른 개인 네트워크의 NAT 장치라고 가정하겠습니다. UDP 홀 펀칭에서 클라이언트는 Server1과 연결되고 NAT 장치에서 포트 매핑이 생성됩니다. 그러나이 클라이언트가 Server2 뒤의 호스트에 연결되면 NAT 장치는 그림 2와 같이 다른 포트 매핑을 만듭니다. Server1은 Server2 뒤의 호스트와 클라이언트 포트 매핑을 공유하며이 포트 매핑과 함께 Server2는 연결할 수 없으며 Server2는 두 번째 포트를 인식하지 못합니다 NAT 장치에 의해 생성 된 포트 매핑.

— vicky
소스