На форуме не раз поднимались вопросы обхода NAT.
Но так никто и не вывел четкие схемы обхода.

Существуют программки, которые работают со STUN серверами и определяют какой у тебя тип NAT.

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

Ниже хочу представить вам схемы обхода NAT для различных типов NAT.
Не знаю, правильно ли нарисовал или нет.
Прошу меня подправить и дать дельные советы.

А также прошу не посылать меня в гугл или яндекс.
Может у кого есть схемы лучше, я буду только рад.

Итак, что удалось на данный момент:


External IP
Ситуация, когда один из peer-ов имеет внешний IP, пусть даже динамический, тривиальна, и ее можно не рассматривать – один peer просто коннектится напрямую на другой peer.

Full cone NAT <-> Any
Ситуация, в которой хотя бы один из peer-ов находится за Full cone NAT, тоже достаточно проста. Full cone peer сообщает свои внешние IP:Port через сервер другому peer-у, и тоннель образуется путем отправки сообщения с не-Full cone peer на Full cone. Схема:

p1(IP:Port) -> s [Привет, я ищу p2, готов принимать на p1(IP:Port)]
p2(IP:Port) -> s [Привет, я ищу p1]
s -> p2(IP:Port) [p1 готов принимать на p1(IP:Port)]
p2(Any) -> p1(IP:Port) [Привет, я p2]

Address-restricted NAT <-> Any
Peer-ы узнают друг о друге через внешний сервер, после чего Address-restricted peer отправляет любое UDP-сообщение второму пиру, чтобы NAT пустил последующий входящий пакет. По описанию с вики может показаться, что это не сработает когда второй peer находится в Symmetric NAT, потому что отправка пакета на первый peer может пойти не с того IP, с которого пакет ушел на сервер. На практике я такого не видел – при изменении получателя с внешней стороны Symmetric NAT меняется только порт. IP остается тот же. Схема:

p1(IP:Port) -> s [Привет, я ищу p2, готов принимать на p1(IP:Port)]
p2(IP:Port) -> s [Привет, я ищу p1]
s -> p2(IP:Port) [p1 готов принимать на p1(IP:Port)]
p1(IP:Port) -> p2(Any) [Кукусики, это сообщение просто чтобы продырявить NAT]
p2(Any) -> p1(IP:Port) [Привет, я p2]

Port-restricted NAT <-> Port-restricted NAT
Peer-ы узнают друг о друге через внешний сервер, и отправляют друг другу на свои внешние IP:Port по сообщению. На этом все – тоннель готов, можно общаться. Схема:

p1(IP:Port) -> s [Привет, я ищу p2, готов принимать на p1(IP:Port)]
p2(IP:Port) -> s [Привет, я ищу p1, готов принимать на p2(IP:Port)]
s -> p1(IP:Port) [p2 готов принимать на p2(IP:Port)]
s -> p2(IP:Port) [p1 готов принимать на p1(IP:Port)]
p1(IP:Port) -> p2(IP:Port) [Кукусики, это сообщение просто чтобы продырявить NAT]
p2(IP:Port) -> p1(IP:Port) [Кукусики, это сообщение просто чтобы продырявить NAT]

ПОЯСНЕНИЕ К СХЕМЕ

Также я считаю, что у меня есть мой внешний сервер с внешним статическим IP, который «помогает» организовать тоннель. На сервере нет никаких ограничений, можно считать, что он умеет выполнять любые IP/TCP/UDP/ICMP/etc манипуляции. Я буду использовать следующие обозначения:
s – внешний сервер
p1(IP:Port) – внешний IP:Port со стороны peer1 (со стороны его NAT-а)
p2(IP:Port) – внешний IP:Port со стороны peer2 (со стороны его NAT-а)

Это

http://pda.delphimaster.net/?id=1333340925&n=4

читал ?

> Это
>
> http://pda.delphimaster.net/?id=1333340925&n=4
>
> читал ?
>


Да, читал.
именно поэтому и создал конкретную тему именно по схемам

Так там же приведена ссылка

http://ilya-314.livejournal.com/109479.html

на которой достаточно ясно проиллюстрировано, что можно и чего нельзя сделать при той или иной схеме трансляции адресов из 4-х самых распространенных ..

> Так там же приведена ссылка
>
> http://ilya-314.livejournal.com/109479.html
>
> на которой достаточно ясно проиллюстрировано, что можно
> и чего нельзя сделать при той или иной схеме трансляции
> адресов из 4-х самых распространенных ..


Выше я привел детальные схемы того, что нужно сделать, чтобы был открыт туннель.
http://ilya-314.livejournal.com/109479.html
- не дает такого представления. А только общую схему.

Правильно ли мною составлены схемы?
И что делать, если мы изначально не знаем тип NAT.
А, как я говорил выше, разные программы по разному отпределяют тип NAT.

> разные программы по разному отпределяют тип NAT.


Тут все просто - либо программы кривые либо разработчики каждой из этих программ фривольно трактуют/искажают устоявшиеся термины для обозначения типов NAT. Либо и то и другое одновременно.


> что делать, если мы изначально не знаем тип NAT


Ну как что ?
Определять самостоятельно тип NAT в соответствии с иллюстрациями.
STUN-сервис в этом как раз и помощник.
Можно и свой нестандартный "эквивалент" STUN-сервиса организовать, коль уж скоро есть возможность ооганизовать его на своем хосте с глобально-маршрутизируемым IP-адресом.

Ребята, как я понял, достаточно реализовать схему ниже, и тогда также смогут держать связь те, у кого тип NAT:
Address-restricted NAT
и
Full cone NAT
Я правильно понял?

Port-restricted NAT <-> Port-restricted NAT
Peer-ы узнают друг о друге через внешний сервер, и отправляют друг другу на свои внешние IP:Port по сообщению. На этом все – тоннель готов, можно общаться. Схема:

p1(IP:Port) -> s [Привет, я ищу p2, готов принимать на p1(IP:Port)]
p2(IP:Port) -> s [Привет, я ищу p1, готов принимать на p2(IP:Port)]
s -> p1(IP:Port) [p2 готов принимать на p2(IP:Port)]
s -> p2(IP:Port) [p1 готов принимать на p1(IP:Port)]
p1(IP:Port) -> p2(IP:Port) [Кукусики, это сообщение просто чтобы продырявить NAT]
p2(IP:Port) -> p1(IP:Port) [Кукусики, это сообщение просто чтобы продырявить NAT]

Находится ли инициатор UDP-"соединения" за NAT или не находится - это вообще не играет роли, если инф.обмен построен классически "запрос - немедленный ответ"

> Находится ли инициатор UDP-"соединения" за NAT или не находится
> - это вообще не играет роли, если инф.обмен построен классически
> "запрос - немедленный ответ"


А если ответ не немедленный?
скажем так.

после вышеуказанной схемы p1(IP:Port)
ожидает пакеты от p2(IP:Port)

> А если ответ не немедленный?


А если он не немежденный, то вопрошающая сторона должна с использованием того же открытого сокета не реже раза в минуту-полторы заявлять о себе отвечающей "Я жив, жду ответа на такой-то запрос".
Тогда connection tracking system даже самого захудалого NAT'а, какого бы типа он ни был, не закроет порт.

> Сергей М.  (13.04.2012 12:47:10)  [10]

Минута много, уже через пару секунд сокет умрет на сервере ISA

> Anatoly Podgoretsky ©   (13.04.12 13:22) [11]


А что, в ISA-сервер еще и НАТ встроена ?
Я просто не в курсе ..

> Сергей М.  (13.04.2012 13:42:12)  [12]

А как бы оно работало в корпорациях с одним ИП?
Более того там сети настраиваемые, можно выбрать NAT или ROUTE
Кроме того поддержан и reverse NAT, наряду с форвардингом и пубилкацией
сервисов
ISA это крупный корпоративный файрвол, легко конфигурируется и расширяется с
помощь СОМ, в дополнение к ГУИ
Кроме того он представляет собой массив.

> Anatoly Podgoretsky  (13.04.2012 14:00:13)  [13]

Вот про СОМ многие не знают.

Ребята, помогите  разобраться схематично.

Вот здесь представлен Алгоритм UDP hole punching для Full cone NAT.
http://ilya-314.livejournal.com/109825.html

Может кто сможет нарисовать:
- Алгоритм UDP hole punching для Address restricted NAT.
- Алгоритм UDP hole punching для Port restricted NAT.

ТОЛЬКО НЕ ФУТБОЛЬТЕ МЕНЯ ПОЖАЛУЙСТА.
ПОМОГИТЕ РАЗОБРАТЬСЯ РАЗ И НАВСЕГДА.

> UDP hole punching для Address restricted NAT


Работать не будет.


> UDP hole punching для Port restricted NAT


Будет работать только если инициатор имеет возможность заставить свой NAT занять конкретно нужный порт (например, с использованием UPnP)

>
> > UDP hole punching для Address restricted NAT
>
>
> Работать не будет.
>
>
> > UDP hole punching для Port restricted NAT
>
>
> Будет работать только если инициатор имеет возможность заставить
> свой NAT занять конкретно нужный порт (например, с использованием
> UPnP)


Какие тогда существуют схемы обхода NAT?
Ранее было сказано, что обойти нельзя только симметричный NAT.
Full cone NAT
Address restricted NAT
Port restricted NAT
- можно обойти.
Но как? Плиз, дайте схему!

> дайте схему!


До чего ж ты нудный)
Ну чем тебе картинки на http://ilya-314.livejournal.com не схемы ?
На мой взгляд там отлично проиллюстрированные схемы..


> Address restricted NAT
> можно обойти


Да не обойдешь ты его без постоянного (!) участия сервера-посредника)

> Сергей М. ©   (16.04.12 10:12) [18]
>
>
> > дайте схему!
>
>
> До чего ж ты нудный)
> Ну чем тебе картинки на http://ilya-314.livejournal.com
> не схемы ?
> На мой взгляд там отлично проиллюстрированные схемы..
>
>
> > Address restricted NAT
> > можно обойти
>
>
> Да не обойдешь ты его без постоянного (!) участия сервера-
> посредника)
>


Не доходит до меня суть этих картинок.
Прошу написать поэтапные действия для обхода
Address-restricted NAT
Port-restricted NAT

> tvmagic  (16.04.2012 19:42:19)  [19]

NAT (все виды НАТ) обходится или симметричным (реверсным НАТ) или
форвардингом (в любом виде и название).