@DVoropaev
Ставлю + к карме на хабре за ответы на вопросы

Можно ли таким образом связать два хоста, находящиеся за NAT напрямую?

Есть три хоста:
хост A подключен через NAT на роутере R1
хост B подключен через NAT на роутере R2
хост C - сервер, подключен к интернету напрямую, имеет статичный IP

Алгоритм действия такой:
1) хост A стучится на сервер C по UDP
2)NAT на роутере R1 открывает динамический порт (port1), подставляет номер порта и внешний IP в source пакета, который A отсылает C
3) Сервер C получает этот пакет и запоминает, что хост A доступен по IP и порту (port2) из предыдущего пункта
4...6) Аналогичным образом C узнает IP адрес и динамический порт на R2 для хоста B
7) Сервер сообщает данные о хосте B хосту А.
8) Сервер сообщает данные о хосте A хосту B.

А дальше идет такая коммуникация между хостами A и B (уже без посредника C):
A -> R1 -> R2:port2 -> B
Хост A отправляет пакет на адрес R2:port2
пакет проходит через R1, который подставляет свой IP и свой port1
R2 принимает пакет, смотрит port2 и видет что он назначен на хост R2.
Пакет приходит на R2
Аналогичным образом отправка идет с хоста A на хост B.

Вопрос, в каких случаях такой способ сработает, а в каких нет?
  • Вопрос задан
  • 411 просмотров
Пригласить эксперта
Ответы на вопрос 4
@antonwx
Эмм, поздравляю с изобретением hole punching. Проще всего воспользоваться чем-нибудь готовым.
Ответ написан
Комментировать
vasilyevmn
@vasilyevmn
DevOps
Какая-то наркомания, честно.
Просто поднимите tinc и все будет работать.
https://habr.com/ru/post/468213/

В вашем случае даже проще так:
https://habr.com/ru/company/flant/blog/338628/
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Читайте тут
2.gif
Symmetric NAT. До недавнего времени это была наиболее распространённая реализация. Его характерная особенность – в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 – ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже.

Full Cone NAT. Эта реализация NAT – полная противоположность предыдущей. При Full Cone NAT входящие пакеты от любого внешнего хоста будут оттранслированы и переправлены соответствующему хосту в локальной сети, если в таблице NAT присутствует соответствующая запись. Более того, номер порта источника в этом случае тоже не имеет значения – он может быть и 53, и 54, и вообще каким угодно. Например, если некое приложение, запущенное на компьютере в локальной сети, инициировало получение пакетов UDP от внешнего хоста 1.2.3.4 на локальный порт 4444, то пакеты UDP для этого приложения смогут слать также и 1.2.3.5, и 1.2.3.6, и вообще все до тех пор, пока запись в таблице NAT не будет по какой-либо причине удалена. Ещё раз: в этой реализации NAT во входящих пакетах проверяется только транспортный протокол, адрес назначения и порт назначения, адрес и порт источника значения не имеют.

Address Restricted Cone NAT (он же Restricted NAT). Эта реализация занимает промежуточное положение между Symmetric и Full Cone реализациями NAT – маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае 1.2.3.4), но номер порта источника при этом может быть любым.

Port Restricted Cone NAT (или Port Restricted NAT). То же, что и Address Restricted Cone NAT, но в этом случае маршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Компьютерные сети
software engineer
Да, так сработает. Но нужно понимать, что если будет пауза в передаче пакетов, то роутеры могут "забыть" про эту сессию, а восстановить подключение без C, ваши A и B не смогут.
Надежнее на роутерах сделать нормальный проброс портов.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы