Можно ли таким образом связать два хоста, находящиеся за 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.  
  

Вопрос, в каких случаях такой способ сработает, а в каких нет? 

 Эмм, поздравляю с изобретением [hole punching](https://en.wikipedia.org/wiki/Hole_punching_(networking)). Проще всего воспользоваться [чем-нибудь готовым](https://zerotier.com/). 

 Какая-то наркомания, честно.  

Просто поднимите tinc и все будет работать.  

<https://habr.com/ru/post/468213/>  
  

В вашем случае даже проще так:  

<https://habr.com/ru/company/flant/blog/338628/> 

[Читайте тут](http://www.cyberguru.ru/networks/network-security/nat-details.html)  
![2.gif](http://www.cyberguru.ru/images/stories/networks/nat-details/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, в противном случае пакет будет уничтожен маршрутизатором. 

 Да, так сработает. Но нужно понимать, что если будет пауза в передаче пакетов, то роутеры могут "забыть" про эту сессию, а восстановить подключение без C, ваши A и B не смогут.  

Надежнее на роутерах сделать нормальный проброс портов.