2011-08-20 2 views
1

3 개의 응용 프로그램 (마스터 서버, 서버 및 클라이언트)이 있습니다. MasterServer이 실행되고Nat 펀치, MasterServer/Server/Client. 클라이언트가 알려진 공용 IP 및 포트에서 서버와 통신 할 수 없음

: 70.105.155.5:15555 (UPnP를 함께 전달 포트)

나는 서버를 생성하고 MasterServer 내가 존재 알려 주시기 바랍니다. MasterServer는 공개 IP와 포트를 유지합니다. MS가 가져 오는 포트는 라우터에 의해 무작위로 할당됩니다 (70.105.155.5:16666). 서버는 동일한 포트를 열어두기 위해 MasterServer에 10 초마다 메시징을 유지합니다.

마스터 서버에 공개 IP 및 서버 포트를 묻는 클라이언트가 열립니다. MasterServer는 70.105.155.5:16666을 반환합니다. 내 로그에서 확인할 수 있기 때문에 서버의 공용 포트 16666이 아직 열려 있는지 100 % 확신합니다.

그러나 Client => Server에서 보낸 모든 메시지는 절대로 수신되지 않습니다. 동시에 서버는 MasterServer에서 16666을 통해 메시지를 받고 있습니다.

그래서 이것은 정말로 수수께끼입니다. 나는 무언가를 잊고 있니? NAT 펀치에 대한 나의 이해가 결함이 있습니까?

도움 주셔서 감사합니다.

답변

2

여기에는 여러 가지 문제가 있으며 라우터의 보안 구성에 따라 달라지며 사용자가 제어 할 수없는 방식으로 자주 발생합니다. 일반적인 변명은 그것이 보안 예방 조치이지만, 실제로 방화벽과 NAT는 두 가지 개별 관심사입니다. 어쨌든, 대부분의 가정 사용자는 그들이 가지고있는 무엇이든 붙어 있습니다. 라우터에는 일반적으로 포트를 명시 적으로 매핑하는 옵션이 있으며 라우터가 지원할 경우 UPnP가 도움을 줄 수 있습니다.

NAT로 돌아가서 서버와 클라이언트가 동일한 NAT 뒤에 앉아있는 경우 문제가 발생할 가능성이 높습니다. 이는 위에서 인용 한 주소의 경우와 같습니다. 대부분의 NAT는 공용 인터페이스에서 들어오는 패킷 만 다시 작성하므로 공용 IP로 주소가 지정된 경우에도 개인 인터페이스에 물리적으로 도착한 패킷은 전달되지 않습니다. 야생에서이 구성을 지원하려면 장치가 자신의 개인 주소를 MasterServer에 광고하고 동일한 NAT 뒤에있는 다른 장치와 통화하고 싶을 때이를 감지해야합니다. 그렇다면 NAT를 통과하는 대신 개인 주소를 사용하십시오. 이것은 여러 가지면에서 결함이 있습니다. 특히 중첩 된 NAT를 사용하는 것이 좋지만, 이것이 최선이라고 생각합니다.

그 외에도 모든 장치가 서로 다른 NAT 뒤에있는 일반적인 경우에는 일부 라우터는 원래 나가는 트래픽을 보낸 위치에서 포트로 들어오는 트래픽 만 허용합니다 (결과적으로 포트 첫 번째 장소에서 개방). 또한 일부는 원격 장치의 동일한 원본 포트에서 오는 것이 필요합니다.

해결 방법은 마스터 서버가 좀 더 많은 작업을 수행하는 것입니다. 요점은 두 피어에게 서로에게 패킷을 보내야한다는 것입니다. 이들은 통과하거나 통과하지 못할 수도 있지만 서버의 NAT를 통해 패킷을 클라이언트의 공용 IP 주소로 보내는 것만으로도 클라이언트의 이후 패킷을 올바르게 전달할 수 있습니다. 그 반대.

실제로 서버의 NAT가 MasterServer와 통신 할 때 Client와 통신 할 때 다른 포트를 사용할 수 있으므로 실제로는 더 복잡합니다. 따라서 이것은 클라이언트가 서버에 다시 말하기위한 포트를 열어 주지만, 클라이언트가 사용할 것으로 기대하는 포트가 아닐 수도 있습니다. NAT가 이와 같이 작동하면 포트 번호 지정 방법이 얼마나 예측 가능한지 알아야합니다. 일부는 하나씩 증가합니다 (그러나 동일한 NAT 뒤에 다른 장치가있어 한 번에 한 단계 씩 여러 단계 씩 이동할 수 있습니다).이 경우, 클라이언트는 어떤 서버 포트를 열어서 어떤 포트를 열어 봤는지 알아 내려고합니다. 다시 한번 MasterServer는 이것을 조정하는 가장 좋은 위치에 있습니다.

다른 것들은 포트 할당에서 완전히 무작위로 보이며, 그것들로 할 수있는 일은 많지 않습니다. 그러나 양쪽 끝이이 임의의 NAT 뒤에있는 경우에만 터미널입니다. 한쪽 끝이 열리기 쉽기 만하면 임의 끝은 중요하지 않습니다.

또한 일부 NAT는 대상의 각 포트에 대해 다른 나가는 포트를 사용하므로 포트가 임의로 할당되지 않은 경우에도 예측이 훨씬 어려워집니다. 연결의 한쪽 끝이 융통성있는 한 다시 한 번 이러한 NAT를 허용 할 수 있지만 피어 - 투 - 피어 컨텍스트에서는 결국 상대방과 대화 할 수 없기 때문에 결국 악몽이됩니다.

+1

대칭 NAT 통과에 대한 참조 - 어색한 NAT에서 포트 할당을 예측하는 것에 대한 내용 : http://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt –

+0

George에게 감사드립니다. . 서버가 항상 적절한 네트워크 설정을 처리하는 전용 리그에서 호스팅되기 때문에 COD 같은 게임에는 이러한 문제가 없다고 생각합니다. STUN 솔루션이 신뢰할 수있는 솔리드인지 알고 계십니까? –

+1

COD가 피어 투 피어 (peer-to-peer) 트래픽을 보내거나 항상 서버를 통해 라우팅하는 경우에 따라 달라집니다 .STUN은 범용 공용 호스트 서버가 자신의 공용 IP/포트 쌍이 연결 상대에게 연결되는 것을 허용하는 서비스입니다 STUN 서버와 대화 할 때입니다. 따라서 목적지에 상관없이 같은 개인 주소/포트 쌍에 동일한 공용 포트를 재사용하는 단순한 NAT로만 작동합니다. –

관련 문제