Соединение двух "серых" компьютеров

Рассказывая про IP-адреса, я писал, что невозможно установить прямое соединение между двумя серыми IP-адресами, так как ни к одному из них нельзя обратиться напрямую. Теперь мне приходится признать, что я был неправ - существует малораспространенный трюк под названием UDP hole punching, позволяющий соединить два компьютера с серыми адресами. Конечно, без посредника не обойтись, но этот посредник нужен лишь на стадии установки соединения, дальше данные будут идти исключительно напрямую.

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

Эта статья будет исключительно теоретической, если же вам нужны конкретные примеры использования UDP hole punching, то далеко идти не нужно - эту технологию использует Skype, сервисы типа Hamachi и TeamView, а также механизм туннелирования IPv6 трафика через IPv4 сети под названием Teredo. Обо всем этом я еще буду писать (и, соответственно, научу, как подобным способом повысить скорость раздачи в торрентах), но пока нужно привести теоретические обоснования...

Проблема

Проблема заключается в том, что к серому IP адресу невозможно просто так отправить запрос - он принадлежит зарезервированному диапазону типа 192.168.*.*, и запрос на такой адрес не пройдет ближайший маршрутизатор или фаервол. Допустим, теперь у нас есть пользователь A с подобным адресом, и он выходит в интернет через сетевое устройство N c реальным адресом. Что будет, если мы отправим запрос на устройство N? А ничего хорошего не будет - этот запрос до пользователя А не дойдет, если, конечно, на устройстве N не настроена "переброска портов" (подобное можно проделать, если сетевое устройство находится в вашем распоряжении, но мы сейчас рассматриваем более сложный случай).

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

Работаем над решением

А теперь задумаемся. Данные-то до пользователя A доходить могут. Если пользователь A отправил запрос к серверу S, то ответ от сервера S все-таки вернется пользователю A, а не застрянет на сетевом устройстве N. Почему такое происходит? Устройство N запоминает исходящий порт P1 пользователя A и составляет временную запись в своих таблицах, что пакеты от A:P1 будут отправляться как пакеты N:P2 (какой-то другой порт), но и пакеты, приходящие на порт P2, нужно переправлять на устройство A и порт P1.

Вот этим устройством временных таблиц мы и попытаемся воспользоваться.

Решение

Пользователь А отправляет пакет с порта P1 на M, и неважно, какой порт. Пакет игнорируется устройством М, но на устройстве N появляется временная таблица соответствия A:P1 с P2. Аналогично, B отправляет пакет с порта P3 на M. Пакет игнорируется устройством N, но на устройстве M появляется временная таблица соответствия B:P3 с P4. A и B отправляют аналогичные пакеты на S, и S узнает порты P2 и P4. A и B связываются с S и сообщают ему порты P1 и P2, а он им сообщает все, что знает. Подготовка проведена.

Теперь A может отправлять пакет с A:P1 на M:P4 - и он будет переправлен на B. Аналогично, пакет с B:P3 на N:P2 может быть переправлен на A.

Это - UDP пакеты, гарантии доставки нет; с TCP подобный трюк провести не удастся. Но, например, в случае Скайпа и не требуется гарантия доставки. Другие же программы на основе UDP реализуют свой механизм проверки доставки и прекрасно работают. Если эта тема интересна, я к ней еще обязательно вернусь. Например, чтобы рассказыть, как использование IPv6 позволит улучшить работу вашего торрента даже если у вас лишь серый IPv4 адрес.

Дата: 2 июня 2010 г., категория: основы интернета.

Загружается, подождите...

← Скорость мобильного интернета

Платежные системы →

Тематика очень интересна и актуальна. Сейчас коллективом бьёмся над программированием подобной системы с определением типа NAT и соединением двух "серых" пользователей. Пока безрезультатно.
Если у Вас появятся ссылки на примеры программного кода, реализующие обход за счёт третьей стороны - были бы очень благодарны! :-)

Было проверено, что VPN-трафик идёт через сервер. Тобишь - настроив на белом IP VPN-сервер, серые пользователи переливают поток полностью через сервер.
Возможно кто-либо встречался с настройками VPN, которые бы позволили соединять пользователей напрямую. Мы пока не встречали.

Спасибо за статью.

Sander
8 февраля 2011 г. 18:15:08

Открытых примеров кода я не знаю.
Но этой технологией пользуются Skype, Teamviewer, Hamachi, а также протокол ipv6

MagTux
23 августа 2011 г. 16:17:45

Не знаю по поводу VPN, но такая полезная программка как UltraVNC с открытыми исходниками умеет устанавливать VNC соединение между двумя серыми IP через посредник (repeater) с белым IP. Сам пользуюсь.

AleX007
28 октября 2011 г. 10:55:31

MagTux
Канешно ты соединишься по VNC, если твои пк в одной сети, а если разные? тут твой VNC не поможет.

Marie
18 ноября 2011 г. 18:36:15

Спасибо большое, помогло многое понять:)

Подписаться на: комментарии к статье (rss), комментарии к статье (e-mail)

Авторизоваться при помощи профиля Google (и не только)

Самые активные участники сайта:

Хотите разместить здесь свою аватарку? Авторизуйтесь, загружайте картинку и комментируйте!

Имя:

E-mail (если хотите подписаться на комментарии):

Сайт (не обязательно):

Я - робот! (снимите галочку, если это не так)
Для блоггеров: если вы хотите чтобы ваша ссылка индексировалась поисковыми системами, вам нужно авторизоваться при помощи Google Friend Connect и написать осмысленный комментарий по теме. В таком случае я переведу ваш аккаунт в разряд "trusted". Комментарии пользователей с проверенным аккаунтом не попадают на модерацию, ссылки индексируются, а рядом с ником стоит значок с зеленой галочкой. Да, модерацию могут пройти только ссылки IT-тематики! Внимание: если вы не авторизуетесь, я не смогу сделать вашу ссылку активной даже если мне понравятся ресурс и комментарий!
Комментарий:

Подписаться на комментарии к статье (rss), комментарии к статье (e-mail)