March 30th, 2010

404

UDP tunnel over dual side NAT

Построение туннеля между двумя узлами, каждый из которых за ортодоксальным NAT'ом без каких-либо манипуляций с натом. Полагается, что пропускается наружу всё (как в обычной домонетке).

http://samy.pl/pwnat/

via habrahabr.

Что-то серьёзное и интересное.


Как оно работает? Сервер (с серым адресом за NAT'ом) пингует узел 3.3.3.3 (хз почему этот адрес) с увеличивающимся TTL, т.е., грубо говоря, делает trace. увеличение TTL прекращается, как только мы вышли за пределы NAT'а (т.е. нам начали отвечать с белых адресов).

stateful nat открывает пересылку ICMP о происходящем серверу.

Далее, клиент притворяется "маршрутизатором" и отсылает "серверу" сообщение ICMP о недоступности 3.3.3.3 на его белый адрес. Наружу клиента выпустят, а NAT сервера считает, что присланный ICMP - ответ от маршрутизатора и пропускает его. Таким образом, мы имеем возможность обратиться к серверу ЗА натом от клиента, который тоже ЗА NAT'ом. Т.к. мы перестали увеличивать TTL, мы знаем, что все приходящие ICMP, кроме как с ближайшего хопа за NAT'ом - это сообщения от клиента. Эта техника используется только для получения белого адреса NAT'а клиента.

Теперь про передачу трафика. Она организуется очень просто: Если клиент отправляет UDP-пакет на указанный адрес и порт [dst address+port], а потом на NAT приходит пакет c dst=src, то это полагается ответом на UDP-запрос, и ответ отдаётся отправителю. Если обе стороны проделают этот трюк, с использованием согласованных номеров портов и зная IP друг друга (см выше), то UDP-датаграммы будут ходить между ними СКВОЗЬ NAT.

Всё дальнейшее, надеюсь, понятно из рисунка (если у кого-то рисунок показывается не целиком, http://desunote.ru/pub/pwnat_udp_tun.png).



PS Дайте инвайт на хабр!
404

о CP, IP и TCP

О чём могут говорить борцы с CP, если главный транспортный протокол интернета так и расшифровывается: tCP (t - от transporting).