Связь через NAT и прочее
От: x-code  
Дата: 02.10.22 09:42
Оценка:
Хочется обсудить решения задачи пробивки связи между любыми двумя устройствами в любых сетях.

Допустим есть практическая задача.
Есть смартфон на android, подключен по wi-fi к домашнему роутеру, имеющему выход в инет.
И есть компьютер с windows, подключен к локальной сети организации, также имеющей выход в инет.
Ну или любые другие сочетания.
В обоих случаях ip внутренние.
нужен БЕСПЛАТНЫЙ сервис, позволяющий моему приложению пробить между ними tcp или udp канал.

В идеале — некая библиотека, которую просто подключаешь в свой проект, и она все делает. Скажем, я ей даю некий "GUID другого устройства", а она мне в ответ пару ip:порт или null, если другое устройство не в сети.

Понятно, что в конечном итоге нужен некий внешний сервер с фиксированным белым ip. Как например в TeawViewer.
Но что делать, если такого персонального сервера лично у вас нет и не будет?

Нужно что-то общедоступное и бесплатное, что бы взяло на себя эту функцию.
Что это может быть?

Добавлю уточнение: некоторые порты (или все кроме ограниченного списка) могут блокироваться (например в сети организации).
Отредактировано 02.10.2022 10:07 x-code . Предыдущая версия .
Re: Связь через NAT и прочее
От: L.K. Марс  
Дата: 02.10.22 09:51
Оценка:
XC>Что это может быть?

coturn
Re: Связь через NAT и прочее
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 02.10.22 10:00
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Допустим есть практическая задача.

XC>Есть смартфон на android, подключен по wi-fi к домашнему роутеру, имеющему выход в инет.
XC>И есть компьютер с windows, подключен к локальной сети организации, также имеющей выход в инет.
XC>Ну или любые другие сочетания.
XC>В обоих случаях ip внутренние.

Если один роутер под твоим контролем, то нет проблем. Современные роутеры поддерживают UPNP, и его можно настроить слушать порт снаружи, и перекидывать на внутренний адрес. Так работают, например, торрент клиенты
Маньяк Робокряк колесит по городу
Re: Связь через NAT и прочее
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 02.10.22 10:05
Оценка:
Здравствуйте, x-code, Вы писали:

XC>В обоих случаях ip внутренние.

XC>нужен БЕСПЛАТНЫЙ сервис, позволяющий моему приложению пробить между ними tcp или udp канал.

Фигня в том, что в общем случае задача в принципе нерешаема. Почитай RFC3489 про так называемый symmetric NAT.
Ты на этот сервер идёшь, тебе выдали внешний адрес на NAT, например, 1.2.3.4:5678. Хорошо, можно с ним общаться.
Но чтобы выйти не на сервер, а на пиира, тебе дадут адрес 1.2.3.4:9012. И вот его ты предсказать не сможешь.

NAT в домашних раутерах чаще конусовый, чем симметричный, с ним будет работать, тогда просто бесплатный STUN сервер поможет. Но чем крупнее сеть (предприятие или второй уровень NAT провайдера), тем вероятнее "симметричная" реализация.

В случае TCP есть ещё одно осложнение: входящие на незарегистрированные ассоциации обычный NAT не пропускает. Тебе нужен особый режим старта TCP — не сервер c listen() и клиент с connect(), а два встречных connect() друг к другу, зная точные назначенные адреса. TCP как протокол такое умеет, но не любой стек такое позволяет. (В SCTP так вообще его запретили.) На FreeBSD старых (примерно до 5.0) ещё такое работало. На Linux и новых FreeBSD я уже не могу добиться, чтобы это сработало, при попытке встречного коннекта идёт RST и всё.
Остаётся UDP.

UPD: Рядом намекнули на настройку раутера с пробросом входящих.
Это не полностью соответствует задаче, но может помочь.

Я ещё забыл написать, что именно из-за этой проблемы рекламируют, что "в IPv6 не нужен NAT". Но там тоже сложно.
Если входящие открыты и security by obscurity на незнании внутренних адресов, то достаточно заставить зайти на подконтрольный сайт, чтобы узнать адрес.
Если входящие закрыты, то просто так TCP не пробросишь, см. выше.
Если входящие открыты для SLAAC-адресов, то опять SbO, но на короткий срок.
Решать по-человечески пока никто не захотел.
The God is real, unless declared integer.
Отредактировано 02.10.2022 10:09 netch80 . Предыдущая версия .
Re: Связь через NAT и прочее
От: jahr  
Дата: 02.10.22 11:27
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Что это может быть?


Можно посмотреть на libp2p, в частности — https://docs.libp2p.io/concepts/nat/
Re[2]: Связь через NAT и прочее
От: Pzz Россия https://github.com/alexpevzner
Дата: 02.10.22 20:15
Оценка: +1
Здравствуйте, netch80, Вы писали:

N>Фигня в том, что в общем случае задача в принципе нерешаема. Почитай RFC3489 про так называемый symmetric NAT.

N>Ты на этот сервер идёшь, тебе выдали внешний адрес на NAT, например, 1.2.3.4:5678. Хорошо, можно с ним общаться.
N>Но чтобы выйти не на сервер, а на пиира, тебе дадут адрес 1.2.3.4:9012. И вот его ты предсказать не сможешь.

Alex Pankratov, который сделал LogmeIn Hamachi (такой p2p VPN), утверждал, что по его опыту, между двумя произвольно выбранными машинами вероятность пробивания NAT — где-то 95-97%. У меня, в моих экспериментах на эту тему, не было такой большой экспериментальной базы, но у меня схожее ощущение.

Обычным STUN'ом с ICE при этом не обойдешься, там есть некоторые хитрости.

Остальные 3-5% можно "добить" туннелированием траффика через свои сервера.

N>NAT в домашних раутерах чаще конусовый, чем симметричный, с ним будет работать, тогда просто бесплатный STUN сервер поможет. Но чем крупнее сеть (предприятие или второй уровень NAT провайдера), тем вероятнее "симметричная" реализация.


Симметричный бывает, который выделяет порты по порядку, а бывает, который выделяет их случайно. Тот, который по порядку, он тоже пробивается, даже есло такой с обеих сторон.

Я б сказал, больше всего проблем с дешевенькими домашними роутерами. Они, например, если переполнить таблицу трансляции, могут вообще в перезагрузку уйти или зависнуть, или сеть у них может отвалиться.
Re: Связь через NAT и прочее
От: Vetal_ca Канада http://vetal.ca
Дата: 03.10.22 02:46
Оценка:
Здравствуйте, x-code, Вы писали:

XC>Но что делать, если такого персонального сервера лично у вас нет и не будет?


XC>Нужно что-то общедоступное и бесплатное, что бы взяло на себя эту функцию.

XC>Что это может быть?

XC>Добавлю уточнение: некоторые порты (или все кроме ограниченного списка) могут блокироваться (например в сети организации).



Zerotier. Лучше пробивает во всяких "левых" местах
Tailscale. Новичку проще всего настроить. Использует Wireguard внутри — больше шансов что не пробьет в публичных сетях
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.