UDP дырокол и обнаружение оглушения NAT - PullRequest
0 голосов
/ 13 апреля 2020

Я пытаюсь добиться UDP Hole Punching в моей домашней сети, когда два клиента связываются с сервером, который прослушивает перенаправленный порт (так что NAT разрешает входящее соединение с ним), а затем заставляет сервер взаимодействовать с каждым клиентский внешний ip и порт кортежа другого клиента, чтобы они могли начать взаимную пробивку, отправив друг другу конечной точке некоторые данные rubbi sh (просто для создания сопоставления NAT), а затем заставив одного из двух клиентов прослушивать с помощью recvfrom.

И клиенты, и сервер находятся за моей домашней сетью, но я не думаю, что это так важно. Код, который я написал, написан на Python, и, поскольку он стал довольно беспорядочным из-за того, что я комментирую и переписываю части только для тестирования, я не буду публиковать sh, но он работает в точке, где сервер получает запросы обоих клиентов и обрабатывает их надлежащим образом: проблема возникает, когда после того, как у каждого клиента есть ip и порт партнера, и они начинают пытаться пробить, никто из них фактически ничего не получает.

Я пытался сделать это, но с подключением к точке доступа со своего мобильного телефона 4G, и благодаря этому все работает как положено, так что ...

... Я провел небольшое исследование, запустив второй сервер перенаправления портов и отправив данные на первый и второй сервер Исходя из того же клиента, я обнаружил, что внешний порт для каждой конечной точки изменяется динамически, поэтому я подумал, что проблема, с которой я столкнулся, связана с Symmetri c NAT ... но когда я запускаю pystun3 из cmdline, он говорит, что у меня есть Full Cone Nat, и даже если бы я не был за Full Cone Nat, такие приложения, как BitTorre Нет, Skype и Hamachi работают просто отлично.

Кто-нибудь может прояснить, что я испытываю и почему, если я на самом деле отстаю от Symmetri c NAT, большинство приложений p2p работают так, как задумано? Извините, если я использовал плохо engli sh, это не мой родной язык.

...