Сетевые технологии / [Из песочницы] Простой NAT traversal на основе OpenVPN и кое-что ещё. Часть 1 Опции

[Decker]

1. Что это такое



Nat traversal, который также называют rendez-vous (ранде-ву, франц.«навстречу вам») — это простая технология на основе UDP-протокола, которая позволяет связать прямым соединением два компьютера, находящиеся за NATом и не имеющие белых IP-адресов.

Чтобы произвести связывание необходимо знать внешний белый адрес, за которым сидит вторая сторона, а той стороне — наш внешний адрес.

Первая сторона начинает посылать UDP-пакеты на внешний белый адрес второй стороны, а вторая, соответственно, на внешний адрес первой.

Пакеты должны быть согласованы по номерам портов, мы с порта A на порт B,

та сторона нам — наоборот с B на A. В итоге оба NATа думают, что от юзера устанавливается исходящее UDP-соединение и по нему пришёл соответствующий (адресами и портами) ответ c той стороны. NATов может быть и больше, например, кроме провайдеров, обе точки могут быть также и за домашними роутерами.



2. Где это уже используется



Много где. В программах типа Hamachi и тому подобных, в том числе во всенародно любимом TeamViewer'е, в Скайпе, в sip-телефонии, в торрентах. Причём в торрентах срабатывание технологии происходит совершенно непроизвольно, если трекер поддерживает UDP (который они называют uTP). С точки зрения трекера каждый пир — это адрес: порт, трекер как раз и видит внешний белый адрес, с которого приходит запрос пира, а порт у каждого фиксирован, о нём сообщается на трекер, когда же пир пытается связаться с другим пиром из списка, он начинает посылать тому UDP-пакеты, при этом порт источника у них не случайный, а тот самый, о котором мы сообщили на трекер как о своём порте, и если тот пир тоже заинтересован с связи с нам, он аналогично периодически шлёт нам пакеты, происходит то самое волшебное связывание. Замечу, однако, что невозможно

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



3. Когда это не сработает



А ведь это может и не сработать, да-да. Почему же? Бывают такие подлые NATы, которые меняют номер порта источника у исходящего UDP-соединения, тогда NAT второй стороны не признает эти пакеты за ответные к тому, что кидала нам сама вторая сторона. Однако, такой NAT большая редкость — ни провайдерские, ни роутерные, ни линуксовые вообще, ни NAT виндового шаринга инета не творят такой подлости, если только специально их не настроить на это. Подлость же эта бывает двух уровней — среднего и мастдайного. При средней подлости у UDP соединений номер порта источника хоть и меняется, но для последующих соединений используются последовательные номера портов. То есть, общаясь с некой третьей точкой, которая помогает проанализировать ситуацию, можно выяснить, какой будет номер порта у нашего следующего UDP-соединения, так же это выясняется и для второй стороны, а потом обе стороны идут «навстречу вам» на предсказанные следующие номера портов друг друга. Эта хитрость реализована и в Hamachi, и в TeamV, и в Скайпе, но не в торрентах, и не в sip. При мастдайной же подлости NATа номер порта источника всегда меняется на абсолютно рандомное число, тут никакой «навстречу вам» невозможен. Кроме того бывают такие непобедимые случаи, когда один или оба желающих подключены не через NAT, а через прокси. Как же наши сетевые титаны, монстры пирига побеждают такие случаи? Hamachi в таких случаях для связи выделяет свои сервера, но скорость

релея через них ограничена 4 кб/cек в бесплатном режиме, TeamV тоже,

про лимит скорости не скажу, не прощупывал, но удалённое управление работает хорошо, а вот Скайп… да-да, эта легенда о Скайпе оказывается правдой — он использует других абонентов с белыми адресами для релея трафика забарикадированных. Но а насколько проблема серьёзна? Где вообще встечаются такие подлые NATы? Ха-ха, вспомните «Дер Гроссе тройке!? Дер Скайп верботен!? Едритунг...», дальше неприлично, поняли о чём я? На 3G модемах он и встречается. Если не запретить Скайп, то сделать его работу максимально сложной!

Вот сидят два человека, и у того, и у другого 3G модем от одного оператора, даются серые адреса, но меж ними связи нету, traversal тоже не схватывается, и как же им связаться !??! См. пункт 5. И ещё замечу, что тип своего NATа можно проверить, для этого есть протокол STUN. Берём любой STUN-клиент и проверяем через общедоступный сервер, вроде stun.sipnet.ru, если скажет, что preserving ports — гуд, а если random ports — значит «верботен».



4. Приступаем к экспериментам



А зачем же нам самодельный «рандеву», чем плохи те же Hamachi или TeamV?

Во-первых, это просто интересно. Во-вторых, некоторые люди и может даже не безосновательно не доверяют свой трафик этим буржуйским сервисам, которые могут его просто снифить. Кроме того, эти сервисы могут быть в оффлайне, а так же, что наверное самое важное, они могут не предоставлять всех тех возможностей, которые нас интересуют, так у Хамача через его виртуальный VPN не ходят мультикасты, а также невозможно его виртуальные сетевые карты объединить в мосты с локальными сетями для Ethernet-связывания двух удалённых локалок, а вот это наверное самое интересное применение технологии, ну не считая банальных случаев, когда два кореша из разных городов хотят поиграть в Контерстрайк меж собой, но не знают как.

И вот… на арене цирка… тррррррр… встречайте… OpenVPN!

Как OpenVPN? Почему OpenVPN? Зачем OpenVPN? Это же что-то такое

сложное-непонятное-заумное с какими-то ключами, сертификатами, настройками, в которых не смог разобраться ещё ни один смертный! Да-да, он самый. Простой, понятный, изящный, ультраконфигурабельный и гибкий OpenVPN!… Начнём с того, как его запускать. Я привык его запускать как простой процесс (не демон/служба), под виндой — через OpenVPN-GUI, а если хочется автозапуска, то пишется простенький батник такого содержания:

cd «C:Program FilesOpenVPNbin»

start openvpn-gui-1.0.3.exe --connect config1.ovpn

Конфиг имеет расширение .ovpn и кладётся в Program FilesOpenVPNconfig,

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

под Дебианом в /etc/rc.local, просто пишу туда строку запуска

/usr/sbin/openvpn --daemon --config /root/config1.ovpn

отсюда сразу видно различие в конфигах — под линуксом к конфигах

пишется полный путь, так для ключа пишется secret /root/123.key,

а под виндой secret 123.key, сам ключ должен лежать в той же папке config.

И ещё одно отличие — под виндой пишется dev tap, а под линухом dev tap1, то есть, название конкретной сетевой карты. Но о ключах позже. Итак, Петя и Вася, подключенные совсем к разным провайдерам и не имеющие белых адресов, поднимают OpenVPN навстречу друг другу.

Петя использует конфиг:



dev tap

ifconfig 10.0.0.1 255.255.255.0

lport 6001

rport 6002

remote ВАСИН_ВНЕШНИЙ_АДРЕС



Вася использует конфиг:



dev tap

ifconfig 10.0.0.2 255.255.255.0

lport 6002

rport 6001

remote ПЕТИН_ВНЕШНИЙ_АДРЕС



так, оба нажали connect, немного подождали, о, чудо! значки в трее стали зелёные! адреса 10.0.0.1 и 10.0.0.2 пингуются межс обой!

Петя запускает сервер Контерстрайка, Вася автоматом находит его в себя в Servers/Lan безо всяких настроек! Пиу-пиу, пыщ-пыщ, го-го-го!..

Ну что же, для начала неплохо. Что тут нужно ещё дополнить: если внешние адреса у наших друзей постоянны, то их надо согласовать один раз. Если они всё время меняются, то вместо того, чтобы постоянно узнавать свой адрес через yoip.ru и сообщать той стороне проще зарегаться на любом DDNS вроде no-ip.com, поставить от него клиентик и уже друг друга в конфигах называть по именам вроде petya.no-ip.info и vasya.no-ip.info

Опция ifconfig служит для настройки сетевой карты, если её убрать, то карту можно настроить руками. Если одна из сторон имеет белый адрес, то технология разумеется тоже сработает, этой стороне даже можно не писать rport и remote. Кроме того, для стабильной работы в конфиги надо добавить опции

no-replay // для игнорирования потерянных пакетов

float // для нормальной реакции на ситуацию, когда у пира на ходу сменился адрес

ping 60 // для поддержки соединения, если нет данных

secret 123.key // для шифрования, если оно вам таки надо

Ключ шифрования генерится с помощью openvpn --genkey --secret 123.key

и кладётся на обе стороны. Вместо разных портов можно использовать один и тот же, тогда вместо lport и rport просто пишем port номер (один и тот же номер на обеих сторонах). Теперь о связывании локалок. Допустим, «Петя Консалтинг» и «Вася Корпорейшн» хотят связать свои локалки, да так, как будто меж их свичами возник прямой провод, тогда на любом из компов этой и той конторы ставим OpenVPN, его сетевую карту объединяем в виндовый мост с картой локальной сети, мост настраиваем как была настроена карта локалки, никаких 10.0.0.1 уже не надо, и ifconfig тоже выкидываем, разумеется, эта пара компов должна ходить в инет через локалку, чтобы снюхаться друг с другом. Предупреждаю — эффект действительно как от прямого провода, если есть одинаковые адреса в сетях, будет конфликт, если и в той и другой есть DHCP, то возможно получения адресов с той стороны через наш туннель, так что думайте сами, это — Ethernet-связывание.

Менее радикальное связывание — это IP-маршрутизация, допустим в одной конторе

лок.сеть 192.168.10.х и шлюз у всех смотрит на шлюзовой комп 192.168.10.1, в другой — лок.сеть 192.168.20.х и шлюз у всех смотрит на шлюзовой комп 192.168.20.1. Тогда на шлюзовых компах ставим OpenVPN, моста не делаем, но включаем роутинг пактов в винде, или форвардинг в линухе,

конфиги — обратите внимание — не tap, и другой вид ifconfig:



dev tun

ifconfig 10.0.0.1 10.0.0.2

lport… и т.д.…

route-gateway 10.0.0.2

route 192.168.20.0 255.255.255.0



dev tun

ifconfig 10.0.0.2 10.0.0.1

lport… и т.д.…

route-gateway 10.0.0.1

route 192.168.10.0 255.255.255.0



в таком случае обращение к другой сети будет происходить через шлюз и затем в vpn, бродкасты так не ходят, на компы чужой сети в Винде можно будет попасть по его адресу, но не по имени. И ещё по вопросу межсетевого связывания. Если OpenVPN связать никак не удаётся, но Hamachi прекрасно поднимается в «зелёном» режиме (победа над NATом), значит можно оставить его, а OpenVPN поднять через него, то есть между хамачевыми адресами 5.х.х.х, так мы и трафик свой защитим и мост если надо сделаем.

Видите — OpenVPN очень простое решение, которое позволяет пробросить

всё что угодно (виртуальную сеть) через UDP-соединение, также он может использовать TCP, как альтернативу, но уже без рандеву.

Простой пример. Петя имеет белый адрес и поднимает свой сервер на TCP:



proto tcp-server

dev tap

ifconfig 10.0.0.1 255.255.255.0

port 6001



Вася находится за прокси и коннектится к Пете:



proto tcp-client

dev tap

ifconfig 10.0.0.2 255.255.255.0

port 6001

remote ПЕТИН_БЕЛЫЙ_АДРЕС

http-proxy… //настройки Васиного http-proxy,

//no-replay, float, ping не нужны в случае TCP



Можно очень много говорить о всевозможных режимах работы,

приводить примеры, но этого для начала будет достаточно,

читайте мануалы, там описаны все опции.

Я не буду касаться мультиклиентного режима, когда к одной точке

соединяются множество клиентов, он-то как раз описан

во всех факах и документации.



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



И вот, мы обнаруживаем худший случай, никакие способы прямого соединения не срабатывают, даже великий и могучий Hamachi показывает нам голубенький значок, намекая на то… что трафик ходит через его промежуточный релей, который стоит то ли в Европе, то ли в Америке и на очень маленькой скорости. Превед «Дер гроссе тройке»… А хочется связаться быстро и качественно! Что же делать !? Арендовать свой собственный сервер! Это дорого ?! Вовсе нет, даже за 100-150 руб. в мес можно арендовать отличный сервер в крупных ДЦ Москвы или Питера. Величина вашего пинга меж собой будет равна сумме пингов от вас до сервера. В случае двух 3G модемов это будет самый минимум ~240, ну да, в CS не поиграешь… Сервер будет конечно на линухе, но если вам позволяет бюджет, можете взять и на винде. Продолжение следует.

Original source: habrahabr.ru (comments, light).

Читать дальше