DSL 두 개의 다른 NAT보다 잘 작동하는 P2P 채팅 응용 프로그램을 개발 중이지만 3G USB 인터넷 연결에는 실패합니다.3G 네트워크 NAT를 바이 패스 할 수없는 이유는 무엇입니까?
3g 네트워크에서는 NAT를 우회 할 수없고 Skype 및 급류와 같은 알려진 P2P 응용 프로그램도 중앙 서버를 통해 데이터를 전송할 때마다 3g 네트워크를 우회 할 수 없음을 알게되었습니다.
3g 네트워크의 아키텍처가 무엇인지 알고 싶습니다. 나는 그들이 사설 IP를 가지고 있지 않다고 들었는데, 포트 쌍만 공용 IP를 사용할 수 있고, 포트는 하나의 공용 포트를 많은 장치에 할당 할 수있다. 맞습니까? 그렇다면 서버가 3g 네트워크로 데이터를 보내는 방법은 무엇입니까?
위키 백과 claims 캐리어 급 NAT 는에도 포트 공유의 존재, P2P 응용 프로그램에서 통과 될 수있다 : 위에서 설명한
기술은 CGN 내에서 잘 작동합니다. CGN도 포트 오버로드 동작을 사용할 수 있습니다. 즉, 동일한 포트 값을 가진 내부 끝 점이 동일한 공용 끝점에 매핑 될 수 있습니다. 이것은 5-uple {프로토콜, 공용 주소, 공용 포트, 원격 주소, 원격 포트} 의 단일성을 깨뜨리지 않으므로 수용 가능합니다. TCP 포트 보존은 또한 으로 이어질 수 있으며 여기서 CGN 포트는 과부하이며 프로토콜 의 건전성 문제가 아닙니다. TCP에 대한 포트 과부하로 인해 CGN은 더 많은 호스트 을 내부적으로 수용하면서 TCP 종단 간 통신 보장을 유지할 수 있습니다.
그러나이 단락에 대해서는 언급 된 내용이 없습니다.
이동 통신사의 경우 내부 클라이언트와 동일한 외부 포트를 선택할 수 없습니다. 이로 인해 TCP와 UDP 구멍 펀칭이 모두 중단됩니다. 여기를 참조하십시오 :
그것은 가능할 것이다, 당신은 정확히 포트 번호를 추측 할 수 있습니다. 너는 조금 떨어져서 연결을 할 수 없을지도 모른다. 대칭 및 대규모 NAT를 통해 작동 할 수있는보다 강력한 홀 펀치 방법의 경우, 다음 방법 중 하나를 시도해보십시오
이것은 실제 4G LTE 라우터에서 작동하지 않습니다. –
3G 네트워크 NAT를 바이 패스 할 수없는 이유는 무엇입니까?
통계로 귀결됩니다. 연결을 설정하려면 패킷이있는 포트로 보내야하며 포트에 패킷을 보내야합니다. 잘못된 포트 번호로 보내거나 잘못된 포트 번호로 보내면 놓치게되고 연결이 설정되지 않습니다.두 사용자가 동시에 포트에 바인딩하고 다른 사용자의 IP 주소로 지정된 패킷을 보내면 65535에 1이 있고 (65535는 IP 주소의 포트 수 임) 해당 포트로 패킷을 보낼 확률이 있으며 포트에 패킷을 전송할 확률은 65535 명 중 1 명입니다. 따라서 연결을 설정할 수있는 기회는 (1/65535) * (1/65535) 또는 (1/65535^2)입니다.
모든 새로운 아웃 바운드 연결에 대해 라우터가 1024와 65535 사이의 간격으로 무작위로 새 포트 번호를 제공하기 때문에 후속 연결에 대한 포트 번호를 알 수 없습니다. 따라서 서버에 IP 및 포트 번호는, 그것은 당신에게 당신의 전화기 또는 그와 비슷한 것을 끄지 않는 한 당신의 IP 주소 (당신의 IP 주소는 자주 바뀌지 않는다)를 말할 수도 있지만, 포트 번호는 바뀔 것이다. 포트 번호를 추측하려고 시도하는 경우 ((65535-1024-1)/(65535-1024)) 또는 99.998 %의 변경이있을 수 있습니다. 가능한 포트 번호의 수는 다음과 같이 가정합니다. 65535-1024).
포트 번호가 예측 가능하지 않으면 (많은 4G 네트워크에서는 그렇지 않습니다), 기회가 없습니다.
다수의 통신 사업자가 이중 NAT를 수행하고 있습니다. 그들은 타워에 가까운 "local"NAT와 캐리어 네트워크 내부의 Carrier-Grade NAT를 가지고 있습니다. 사용 가능한 IPv4 주소를 얻는 것이 점점 더 어려워지고 ARIN은 사용 가능한 IPv4 주소가 완전히 소진되어 오늘날의 이동 통신사에 할당됩니다. –
내가 무슨 뜻인지 알 것 같아. 내 T-Mobile 네트워크에서 처음 네 번 홉은 모두 "10"으로 시작합니다. 그것들은 타워에 더 가까운 "로컬"NAT입니다. 다음 4 개의 홉은 모두 "4"로 시작합니다. 이들은 로컬이 아니지만 동일한 ISP에 속합니다. 그 후, 서로 다른 공용 IP 주소에 바인딩 된 패킷이 다른 경로를 사용하고 공통 접두어를 공유하지 않는 분기점이 있습니다. –
친절하게 설명합니다. ! –
나는 다중 에이전트 시스템을위한 오픈 소스 미들웨어에서 일하고 있으며 최근에는 4G/3G 네트워크에서 P2P 사용을위한 UDP 기반 전송 옵션을 만들어야했습니다. 우리는 T 모바일의 데이터 계획과 NAT 뒤에있는 다양한 학술 네트워크에서이를 테스트했으며, 구현에 대해서는 꽤 확신합니다. 이 질문에 대한 확실한 해결책이 없기 때문에 MADARA 미들웨어 (http://madara.sourceforge.net/)에서 현재 구현 한 솔루션 유형을 REGISTRY_CLIENT 전송 옵션을 통해 공유 할 것이라고 생각했습니다.
우리는 P2P 엔드 포인트에 대해 CORBA에 익숙한 사용자가 레지스트리 서버 또는 이름 서비스라고 부르는 것을 선택했습니다. 레지스트리 서버는 UDP가 일방향 메시지로 도달 할 수있는 일부 공용 IP : 포트에서 실행해야합니다. 테스트를 위해 아마존 EC2 노드를 임대했으며 방화벽 설정에서 바인딩 할 UDP 포트를 통해 UDP 트래픽을 허용하는지 확인했습니다. 서버 측 (레지스트리 서버에 대한 공용 IP : 포트 쌍)에서는 포트에 바인드하여 클라이언트 등록을 기다립니다. 다른 사람과 대화하고 싶은 P2P 클라이언트는 레지스트리 서버에 레지스트리 메시지를 보냅니다.
P2P client ----> [register message] ---> Registry Server
등록 메시지는 임의의 내용을 가질 수 있습니다. 실제로 우리의 일반적인 데이터 프로토콜의 메시지 헤더 이외에는 내용이 없습니다. 서버 측에서는 정상 소켓 recv 호출을 통해 등록 메시지 발신자 (위의 왼쪽에있는 P2P 클라이언트)의 원격 호스트를 확인합니다. 이 원격 호스트는 P2P 클라이언트를 보호하는 방화벽을 통해 끝점 정보 여야합니다.
여기에서 진행되는 작업을 이해하려면 P2P 클라이언트의 공용 레지스트리 서버로 메시지가 라우팅되는 방식을 살펴 봐야합니다. 다음 ASCII 다이어그램은 P2P 클라이언트에서 EC2 서버로의 경로를 따라 소켓이 볼 수있는 원격 정보 (예 : 방화벽 매핑 예)를 보여줍니다. 이것은 하나의 방화벽만을 보여 주지만 P2P 클라이언트와 레지스트리 서버 사이에 여러 개의 NAT가 작동해야합니다. 특정 NAT에서 트래픽이 할당 된 IP : 포트를 통과 할 때 NAT가 공개 IP : 포트를 유지하는 한. 우리는 우리의 레지스트리 서버에서 192.168.1.10:35000에 메시지를 보내려고하면
P2P client ----> [message from 192.168.1.10:35000] ---> Firewall ---> [message from 111.111.50.34:5627] --> Registry Server
지금, 그것은 실패 (또는 적어도, 그것은 거의 확실히 잘못된 장소에 갈 것이다). 마찬가지로 4G 방화벽이 포트를 35000에서 5627로 변경한다는 것을 알 수 있습니다. P2P 클라이언트로 메시지를 다시 보내려면 다음 두 가지 작업을 수행해야합니다. 1) 111.111.50.34:5627을 통해 반송 메시지를 보내십시오. 2) P2P 클라이언트 또는 레지스트리 서버가 서로 데이터를 자주 다시 전송하는지 확인하십시오. - 초당 한 번씩 영구적으로 바인딩하는 것이 좋다고 보입니다. 공개 IP : 포트 111.111.50.34:5627, 우리의 예에서.
우리 프로토콜의 일부로 등록 된 P2P 클라이언트로 쓸모없는 패킷을 다시 보내지 않습니다. 해당 클라이언트의 그룹/도메인/모든 도메인에있는 P2P 클라이언트의 관련 공개 IP : 포트 쌍을 모두 보냅니다. 기본적으로 레지스트리 서버가 P2P 클라이언트와 관련이 있다고 인식하는 모든 것에 대해 P2P 클라이언트 검색 정보를 보냅니다.
예를 들어 두 개의 P2P 클라이언트가 4G 공급자의 방화벽을 통해 111.111.50.34:5627 및 111.111.37.24:15234의 ip : 포트 바인딩을 통해 레지스트리 서버에 메시지를 보냈다고 가정 해 봅니다. 새로운 P2P 클라이언트는 111.111.70.105:7000에서 연결하고, 우리는 간단한 목록에 다시 다른 2 엔드 포인트 응답 :이 목록과 사용을의 P2P 클라이언트 # 3 끝에 지금
[Registry Response for P2P Client #3]
111.111.50.34:5627
111.111.37.24:15234
그것은 P2P 응용 프로그램의 잠재적 종점입니다. 이들은 P2P 동료입니다. 등록한 것과 동일한 소켓을 통해 UDP 패킷을 만들 수 있습니다. 예를 들어 휴대 전화의 모바일 연결형 핫스팟 (예 : 내 경험에 비추어 볼 때 영구적 인 포트의 모든 인바운드 UDP 트래픽을 차단하도록 설계된 방화벽과 같이 보수적 인 방화벽 뒤에 있지 않은 경우) 포트 포워딩을 활성화하는 데 사용할 수있는 구성 설정이없는 바인딩) 및 트래픽이 양방향으로 흐를 수 있어야합니다.
앞서 언급했듯이 P2P UDP 연결을 유효하게 유지하려면 기본적으로 P2P 클라이언트를 보호하는 각 방화벽에서 공용 IP : 포트 바인딩을 유지하고 활성 상태로 유지하기 위해이 끝점으로 /로부터 주기적으로 데이터를 다시 보내야합니다. 이것은 주기적으로 공개 레지스트리 서버에 등록 정보를 다시 보내거나 다른 P2P 클라이언트의 UDP 패킷을 4G 방화벽이 P2P 클라이언트에 할당 한 공개 IP : 포트로 수신하여 수행 할 수 있습니다.
예! 내 대답 좀 봐! 그 위키 피 디아 페이지에서 내 대답에 대한 두 참조했다! –
신경 쓰지 마세요. 와세다 대학의 기술은 일부 소규모 대칭 라우터에서 작동 할 수도 있지만 (필자는 혼자 힘으로 보지 못했지만), 직접 구현했지만 3/4G 네트워크에서는 작동하지 않습니다. –