Как пробивать НАТ?

Question

[dinegnet]

Имеем 2 приложения.
Приложения взаимодействуют между собой.
2 компьютера (смартфона и пр) на которых работают приложения могут быть в общем случае подключены к интернету как угодно.

Понятно, что в качестве резерва должен быть метод взаимодействия через внешний сервер.

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

Строго говоря интересуют названия технологий. Какие ключевые слова для Гугля
Дальше - сам.
Для универсального случая - любого НАТ.

Наверняка есть стандартные процедуры обхода/дружбы с НАТ.

Comments

[zeuss56]

Чёрт возьми, джва года ждал ответ. Как любыми способами получить http доступ к серверу с серым IP из интернета?

Answer 1

[15432]

TCP / UDP hole punching, статей куча

Answer 2

[Дмитрий Александров]

Универсального способа нет. Гуглить по фразам UPnP, stun, turn.
Для универсальности надо делать реализации всех способов разом, со стороны клиента перебирать каждый способ до достижения результата, если не один способ не помог то подключаться через промежуточный сервер.

Answer 3

[Дмитрий]

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

Есть несколько RFC на эту тему, сама процедура называется Interactive Connectivity Establishment. Самому писать реализацию крайне не советую, там столько тонкостей, что можно пару лет исследовать. Лучше взять что-то готовое.

Если нужно из коробки на винде, из пакетов на линуксе, и, вроде бы как, кто-то портировал на Андроид — используйте Teredo/Miredo. Там всё довольно просто, в современных версиях пробиваются все типы ната. В случае симметричного, трафик идёт через релей, реализации которого тоже есть в виде демона. Единственное, что может не устраивать из коробки — там IPv6, если нужен v4, придётся реализовывать маппинг.

Более тяжёлая артиллерия — это реализация от гугла. Сейчас она входит в кодовую базу Хромиум, в реализацию стандарта WebRTC. Там всё довольно сильно завязано на фреймворк хрома, очень тяжеловесно, довольно долго собирается, используется непривычная терминология из RFC. Зато эта библиотека самая действенная, огромный опыт гугла даёт о себе знать, демоны релеев (TURN) также есть, за вас написан reliable транспортный протокол, может взаимодействовать с браузерами через WebRTC Data Channel и прочие плюшки.

Есть ещё, конечно, много других библиотек, но они что-то у меня не взлетали, сильно глючили, не всегда правильно тип НАТа определяли и т. п.

Answer 4

[d-stream]

Универсального нет. Выше вариант наводки дали, но это не всегда и не везде.
Посему наверное единственный универсальный вариант - наличие третьей стороны (сервера). Остальное - уже по вкусу:
- все взаимодействия через сервер (типа Hamachi, ammy и т.п.)
- сервер работает только сводником (торренты)

Comments

[dinegnet]

Про сервер, если все плохо и для первоначального коннекта через сервер - это я сразу написал в вопросе.

ОК, торрентом.
А дальше? Как именно? Вам известны названия технологий?

[dinegnet]

Какая в вашем ответе полезная информация, кроме той информации про сервер, что я изложил в своем первоначальном вопросе?

[d-stream]

dinegnet: upnp, µtp например, еще бочком тут и nat-traversal
те же торрент-клиенты перебирают разные варианты обходов nat (в силу множества разных nat)

ГОСТа на эти технологии нет, так же как и стандартизированных названий.

[d-stream]

А про полезность информации - тут как с полезностью очков в басне Крылов -)

[Максим Мосейчук]

"- сервер работает только сводником (торренты)"
В торрентах сервер (трекер) лишь отправляет список пиров роя. Он никак не способствует пробитию NAT.

[dinegnet]

d-stream:
>>> upnp, µtp например, еще бочком тут и nat-traversal

так это был не ваш ответ.
вы просто процитировали соседний ответ. я его и так читал.