Способы обхода NAT?

Question

[devalone]

Если я правильно понимаю, one-to-many NAT работает следующим образом:
Компьютер пользователя посылает запрос на сокет 8.8.8.8:80 с сокета 192.168.0.10:10000, пакет приходит на роутер, откуда тот извлекает информацию об ip адресе и порте отправителя, выбирает свободный порт(допустим 15000), заменяет ip и порт отправителя и сохраняет у себя в недрах памяти примерно следующую запись:
Если придёт пакет на мой внешний интерфейс с таким-то ip и портом получателя 15000, направить его на адрес 192.168.0.10 внутренней сети и изменить порт получателя на 10000.
Только не совсем понятно, как работает ping, ведь он на уровне ниже, чем tcp и udp, ну да ладно.

Так вот, возможно ли соединить 2 компьютера за NAT следующим образом:
ПК1 устанавливает соединение с адресом 8.8.8.8 порт 80 по исходящему сокету 192.168.0.10:10000, его роутер Р1, имеющий адрес 45.160.10.1 запоминает это и выделяет ему порт 5000 и все пакеты приходящие на сокет 45.160.10.1:5000 Р1 отправляет на ПК1.
В тоже самое время ПК2 устанавливает соединение с тем же сервером 8.8.8.8 по порту 80 с сокета 192.168.0.20:10000, его роутер Р2 с ip адресом 165.123.10.2 выделяет ему порт 10000 и все пакеты приходящие на 165.123.10.2:10000 отправляет на ПК2.
Дальше сервер 8.8.8.8 сообщает ПК1 адрес ПК2(165.123.10.2:10000) и ПК2 адрес ПК1(45.160.10.1:5000) и они начинают общаться отправляя пакеты друг другу, а не серверу 8.8.8.8
Такое возможно или роутеры Р1 и Р2 будут игнорировать пакеты пришедшие не с 8.8.8.8, для общения с которым открывалось соединение, а с другого адреса?

Как реализован обход NAT в bittorrent или там его нет и обмениваются все через клиентов, имеющих "белые адреса"?

Comments

[nirvimel]

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

Answer 1

[Дмитрий]

Пробитие НАТа -- это оооочень сложная и неоднозначная тема. Там используется целый комплекс различных процедур, который называется Interactive Connectivity Establishment.
То, что вы описали, это самый элементарный вариант техники. Который применим в 15-20% случаев.

Торрент-клиентам, по сути, это не так важно как, например, для стримминга видео или голоса. Но они тоже используют очень много всего для этой задачи: от UPnP и NAT-PMP до довольно сложных техник из стандарта ICE.
Ещё в торрентах используется DHT, у которой часто есть bootstrap-узлы с постоянными белыми адресами, потом через эти узлы идёт уже инициализация всей системы, и последующий поиск адресов в ней.

В общем, если вам интересно, можете заняться исследованиями, но суть в том, что результат будет зависеть от настроек НАТа провайдера. На вашем провайдере будет работать, а у соседа уже не будет... С этим бьются корпорации типа Гугла, например. Да и то, с переменным результатом.

Если нужно на поиграться, можете взять существующую библиотеку, например, PJNATH или libnice. Если для серьёзного проекта, то лучше выдрать реализацию из гугловского WebRTC, там она постабильнее будет.

Comments

[Игорь Агарков]

Здравствуйте! А вы не подскажите, насколько долго роутер хранит правило, согласно которому он перекидывает входящие пакеты пакеты локальному устройству?

Answer 2

[Андрей Буров]

Верно мыслите:
https://ru.wikipedia.org/wiki/STUN
https://ru.wikipedia.org/wiki/Traversal_Using_Relay_NAT

Answer 3

[Валентин]

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

То, что вы предлагаете, уже давным давно реализовано в различных протоколах, примеры вам привели. Но этот вариант все равно не отменяет того факта, что должен быть сервер 8.8.8.8 под вашим управлением. А если такой сервер есть, гораздо гибче и практичнее поставить на нем vpn или какой-либо вариант прокси.

Comments

[devalone]

А если такой сервер есть, гораздо гибче и практичнее поставить на нем vpn или какой-либо вариант прокси.

А если это распределённая сеть, где клиенты должны по возможности общаться между собой напрямую? Skype и Bittorrent не зря сделаны распределёнными.

[Дмитрий]

devalone: Если сеть распределённая, то вам придётся использовать не одну фичу какую-то, а миллион разных, для разных клиентов, разных вариантов доступа этих клиентов к сети, разных провайдеров, и т. п.

В том числе, в технологию Interactive Connectivity Establishment входит понятие Relay. Это такой сервер, через который пойдёт трафик в случае, если оба клиента не могут установить p2p-соединение — когда у обоих симметричный NAT, например.
Так что, вам просто придётся и такие серверы поднимать в своей инфраструктуре. А чтобы адекватно пользовались вашей технологией из различных областей земного шара, вам придётся поднимать целое облако этих гео-распределённых релей-серверов. Как, например, делал в своё время майкрософтовский Тередо. Потом, правда, из-за ненужности протокола, их почти все свернули.
Или можно, как делал скайп, использовать ваших же клиентов в качестве релеев. Правда, они вас будут за это вспоминать нехорошими словами.

Skype и Bittorrent не зря сделаны распределёнными.

Ваша информация устарела лет на 6... Скайп уже давным-давно перевели в облако и, примерно с 2011-12-го года, весь трафик идёт через майкрософтовский Ажур.

[Валентин]

devalone: skype и торент все равно имеют публичный сервер в своей сети под управлением участника этой сети, который фактически является упрощенной точкой входа в впн.

Answer 4

[Дмитрий]

Про какой обход NAT в bittorrent вы говорите? uPnP?

Comments

[Максим Гришин]

UDP hole punching, скорее всего.

Answer 5

[Юрий Чудновский]

"Обход" NAT который вы имеете в виду, делается путём посылки к серверу запроса на соединение с той стороны, которая имеет белый айпи.

Только не совсем понятно, как работает ping

Никак не работает. Пинговать можно только белые айпишки, пинг на локалку не имеет смысла так как серые айпи не маршрутизируются в Интернете.

Comments

[devalone]

Никак не работает. Пинговать можно только белые айпишки, пинг на локалку не имеет смысла так как серые айпи не маршрутизируются в Интернете.

Я про то, как он работает, когда я пингую за NAT'ом белый адрес, у icmp ведь нет порта, а что-то роутер должен записать себе в память, чтоб ответ вернулся мне, а не соседнему компу из локалки.

[Виктор Бельский]

devalone: Используется IP и ICMP ID