UDP дырокол пробивая хост-специфический сбой - PullRequest
Новая
       35

UDP дырокол пробивая хост-специфический сбой

3 голосов
/ 07 марта 2012

Я написал программу, которая устанавливает одноранговые ссылки. Программа, которую можно найти по адресу http://basyl.co.uk/code/punch/doc/files/Readme-txt.html,, состоит из двух частей: сервер, работающий на общедоступном хосте; и клиент, который используется каждым концом желаемой одноранговой ссылки.

У меня есть доступ к двум общедоступным серверам: bonn (home.contextshift.co.uk) и entropy (home2.contextshift.co.uk)

  • Если сервер работает на bonn, а клиенты работают на bonn, entropy и моем домашнем ПК (за NAT), перфорированное соединение от entropy может без проблем общаться с моим ПК. Однако соединение Бонна с ПК не удается; данные с ПК доходят до Бонна, но данные из Бонна через NAT-дыру никогда не поступают.

  • Если сервер находится на энтропии и снова, клиенты работают на bonn, entropy и моем ПК, перфорированные соединения работают нормально между всеми клиентами.

Это сбивает с толку, поскольку сервер не участвует в одноранговом потоке данных. Если вы все еще со мной, вот поток:

  • Клиент-А подключается к серверу по каналу TCP и получает уникальный токен;

  • Клиент-B подключается к серверу по каналу TCP и получает уникальный токен;

  • Клиент-A и клиент-B получают обновления по своей TCP-ссылке, сообщая, кто еще подключен;

  • Клиент-A (или B) отправляет запрос на сервер по вновь созданному каналу UDP, передавая его токен и имя клиента-B;

  • Сервер идентифицирует Клиента-А по токену и перенаправляет запрос Клиенту-В по своей TCP-линии, включая UDP-адрес / номер порта А в запросе;

  • Клиент-A (или B) отправляет подтверждение на сервер по вновь созданному каналу UDP, передавая его токен и имя клиента-A;

  • Сервер идентифицирует Клиента-B по токену и перенаправляет запрос Клиенту-А по своей линии TCP, включая UDP-адрес / номер порта B в запросе;

  • A и B теперь имеют UDP-адрес / порт другого и могут пинговать друг друга и обмениваться данными.

Как видите, Сервер никогда не общается по ссылкам UDP, созданным Клиентами для своих запросов, только по ссылкам TCP.

Итак, в итоге, клиент не работает на определенном хосте, когда сервер находится на том же хосте. Какие-нибудь предложения по причинам такого поведения или по способам, которыми я мог бы исследовать это далее?

Обратите внимание, что этот тест является искусственным, потому что цель пробивания дырок заключается в том, чтобы общаться между двумя хостами, оба за NAT. Это на самом деле работает, где бы ни находился сервер, поэтому проблему можно считать академической.

Обратите внимание, что перед написанием программы я попытался использовать общедоступное приложение под названием NatCheck. Это также не помогло подобным образом, хотя я не исследовал это много - потребовалось три общедоступных хоста, и я изменил его, чтобы использовать только мои два. Когда это не сработало, я предположил, что я каким-то образом облажался и отказался от приложения.

Любые комментарии к коду также приветствуются (вероятно, я опубликую их на сайте обзора кода).

Ответы [ 3 ]

3 голосов
/ 08 марта 2012

Я не совсем понимаю все это, но похоже, что вы хотите использовать промежуточный сервер для обнаружения исходных UDP-портов для клиентов A и B, чтобы A и B могли одновременно отправлять дейтаграммы UDP друг на друга, тем самымоткрытие правил NAT и (в конечном итоге) пропуск трафика через.

Вот проблема: NAT может сопоставить исходный порт с тем, что он хочет.Когда B отправляет дейтаграмму на сервер, нет никакой гарантии, что исходный порт, видимый сервером, будет тем же, который используется, когда B отправляет дейтаграмму A.

Существует множество причин, почемуNAT может изменить номер порта, а из соображений безопасности он будет случайным образом мешать тому, что вы пытаетесь сделать.Поэтому, хотя иногда вы можете использовать двойной перфорирование (NAT-NAT), вы не можете делать это каждый раз.

1 голос
/ 06 апреля 2012

Итак, в итоге, клиент не работает на определенном хосте, когда сервер находится на том же хосте. Любые предложения по причинам такого поведения

Может ли сервер видеть, что clientA находится на 127.0.0.1 (или, возможно, не маршрутизируемом адресе локальной сети?), А не на своем публичном IP-адресе?

Если clientB пытается связаться с clientA, используя неправильный адрес, очевидно, что UDP-датаграмма не попадает к предполагаемому получателю.

или как я мог бы продолжить это расследование?

Некоторый вывод из tcpdump с сервера (AKA clientA) и clientB очень помог бы. Возможно, вы захотите использовать -i any и, возможно, -s 0.

0 голосов
/ 16 марта 2012 
the client doesn't work on a particular host when the server is on the same host

В некоторых угловых случаях NAT принимает трафик только с целевого IP-адреса: порт, используемый для пробивания дыры. Поскольку это не один из удаленных одноранговых узлов NAT, они блокируют трафик от него. Это может объяснить вашу проблему.

...