udp nat что это
Задачи [ править ]
1. NAT решает проблему ограниченного диапазона IP-адресов, она существенна до тех пор, пока не произойдёт окончательный переход на IPv6.
2. Позволяет ограничить общение снаружи ко внутренним хостам, при этом возможность общаться изнутри наружу остаётся.
3. Даёт возможность скрыть внутренние сервисы внутренних хостов/серверов. Можно подменить внутренний порт официально зарегистрированной службы (например, 80-й порт TCP (HTTP-сервер) на внешний 54055-й). Таким образом, снаружи можно будет попасть на сайт по адресу вида http://example.org:54055, но на внутреннем сервере, находящемся за NAT, работа HTTP-сервера будет происходить на обычном 80-м порту, то есть 80-й порт сервера не будет доступным из Интернета для прямого входящего соединения.
Принцип работы [ править ]
Компьютер может быть подключен к Интернету напрямую (белый IP-адрес, обычно при подключении непосредственно к модему), либо через NAT — тогда компьютер имеет локальный IP-адрес, из Интернета недоступный (частный, серый). К серым адресам относятся адреса из следующих диапазонов:
Преобразование адреса методом NAT может производиться почти любым маршрутизирующим устройством — маршрутизатором, сервером доступа, межсетевым экраном. Принимая пакет от локального компьютера, роутер смотрит на IP-адрес назначения. Если это локальный адрес, то пакет пересылается другому локальному компьютеру. Если нет, то пакет надо переслать наружу в интернет. Но ведь обратным адресом в пакете указан локальный адрес компьютера, который из интернета будет недоступен. Поэтому роутер «на лету» транслирует (подменяет) обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, роутер сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, роутер сотрет у себя в таблице запись о n-ом порте за сроком давности.
Пример [ править ]
Типы NAT [ править ]
Статический [ править ]
Один внутренний адрес преобразуется в один внешний, все запросы, приходящие на внешний адрес будут транслироваться на внутренний, как будто хост и является обладателем белого IP-адреса. Такой подход бывает полезным, когда внутри частной сети есть сервер, к которому необходим полный доступ извне. Минус подхода в том, что он никак не помогает сохранить белые адреса.
Динамический [ править ]
Есть пул белых адресов, например, провайдер выделил сеть 198.51.100.0/28 с 16-ю адресами. Два из них (первый и последний) — адрес сети и широковещательный, ещё два адреса назначаются на оборудование для обеспечения маршрутизации. Двенадцать оставшихся адресов можно использовать для NAT и выпускать через них своих пользователей.
Ситуация похожа на статический NAT — один приватный адрес транслируется на один внешний, — но теперь внешний не чётко зафиксирован, а будет выбираться динамически из заданного диапазона. Проблема подхода такая же, как и в случае со статическим NAT — не решается проблема ограниченности белых адресов.
Many-to-One [ править ]
Следующий тип имеет несколько названий: NAT Overload, Port Address Translation (PAT), IP Masquerading, Many-to-One NAT. Суть этого типа в том, что через один внешний адрес выходит наружу много приватных. Этот подход, в отличие от предыдущих, позволяет решить проблему с нехваткой внешних адресов.
Проблемы NAT [ править ]
Hole punching [ править ]
Hole punching — метод для прямого соединения двух хостов, которые находятся за NAT-ами. Для инициации соединения требуется третья сторона – сервер, который виден обоим компьютерам. Обычно используются публичные STUN-серверы.
STUN (сокр. от англ. Session Traversal Utilities for NAT, Утилиты прохождения сессий для NAT) — это сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами), определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта. Эта информация используется для установления соединения UDP между двумя хостами в случае, если они оба находятся за маршрутизатором NAT.
UDP hole punching [ править ]
Алгоритм установления UDP сессии между 2 хостами находящимися за NAT [ править ]
Если [math]A[/math] и [math]B[/math] находятся за одним и тем же NAT-ом, то они соединятся через приватные адреса, иначе через публичные. На картинке показан пример, когда [math]A[/math] и [math]B[/math] находятся за разными NAT-ами.
TCP hole punching [ править ]
Алгоритм установления TCP соединения между 2 хостами находящимися за NAT [ править ]
Веба нет, а инет есть! Часть вторая Протоколы IP, TCP, UDP и технология NAT
Конечно, все аспекты работы протоколов невозможно разобрать в одной статье, но если вам интересно более детально изучить тему, то почитайте документы RFC (Request For Comments). Публикуются они на английском языке, интересующимся — сюда: www.ietf.org.Но для того, чтобы в общих чертах понимать, как работает эта замечательная технология, необходимо разобраться, как функционируют протоколы IP, TCP и UDP. Поэтому сегодня мы поговорим о сетевом и транспортном уровнях модели OSI.
Протокол IP
Как я и говорил, протокол IP занимается межсетевой доставкой пакетов данных по каналам связи, причем его не волнует, какая среда между двумя маршрутизаторами. Это важно потому, что на своем пути пакет может преодолеть несколько разных сред. Например: от клиентского компьютера до маршрутизатора провайдера — ADSL, от маршрутизатора провайдера до вышестоящего провайдера — FDDI (оптика), далее — опять оптика, а от провайдера хостера до самого сервера — Ethernet. Причем ни данные, ни заголовок не должны изменяться. Ни на одном этапе. Исключения есть, но о них чуть позже. ОС сама заполняет все необходимые поля, исходя из полученных от приложения данных. (См. таблицу 1. Обращаю ваше внимание на то, что второе поле — это длина заголовка, а не пакета, и на то, что в этом заголовке указана контрольная сумма заголовка IP, а не всего пакета.)
Адрес подсети, маска подсети
Для того чтобы маршрутизация проходила правильно, весь интернет поделен на так называемые подсети. У подсети есть маска. Чтобы понять, что это такое и для чего оно служит, необходимо вспомнить, что IP-адрес состоит из четырех байтов. Маска подсети тоже состоит из четырех байтов, однако имеет две части: сначала идущие подряд единицы (n), затем идущие подряд нули (32 — n). Единицы — биты, адресующие сеть, а нули — биты, адресующие хост сети. Вообще, подсеть — это некое адресное пространство, выделенное нескольким хостам, которые представляют собой организованную структуру, например районную или корпоративную сеть. Каждая подсеть имеет два специфических адреса. Это адрес сети и адрес Broadcast. Если с адресом сети все более или менее понятно (идентификатор), то адрес Broadcast намного интереснее. По идее, пакет, посланный на него, будет принят и обработан всеми хостами сети, однако на практике маршрутизаторы давно блокируют такие пакеты. Еще подсеть характеризуется тем, что пакеты внутри нее доставляются напрямую, без маршрутизаторов. И даже если районная сеть сегментирована при помощи внутренних маршрутизаторов, то это уже не одна подсеть, а несколько подсетей, объединенных в одну (например, районную).
Основной шлюз
Он же маршрутизатор. Это специальный узел сети, который занимается передачей пакетов между разными сетями.
Интерфейс
Для каждого конкретного маршрута прописывается, с какой именно сетевой карты посылать пакеты, идущие по нему. Уважаемые читатели, открою вам два секрета, которые совсем не секреты. Во-первых, далеко не все интерфейсы являются физическими. То есть каждой сетевой карте соответствует один логический интерфейс, но не обязательно каждому логическому интерфейсу соответствует сетевая карта. Знакомый абонентам локальных сетей пример — VPN-соединение. Логический интерфейс есть, а отдельной сетевой карточки нет и быть не может. Еще бы: это же Virtual Private Network. А во-вторых, даже если компьютер не имеет ни одной сетевой карты, но на нем установлена поддерживающая работу в сети операционка — Windows, Linux, FreeBSD и т. д., — то у него есть как минимум один интерфейс, так называемый LoopBack, или «петля». В этом интерфейсе всегда прописан адрес 127.0.0.1 (самая середина адресного пространства).
Благодаря LoopBack машина доставляет данные сама себе. Вся информация, переданная через него, возвращается на отославший ее компьютер. Кроме того, любая ОС имеет в таблице маршрутизации записи о том, что на ее собственные адреса (прописанные на других интерфейсах вне зависимости от степени их виртуальности) данные необходимо доставлять именно через LoopBack. Это сделано в целях устранения ненужной нагрузки на сетевое оборудование. В таблице маршрутизации содержатся записи с маршрутами до всех подсетей, для которых их надо явно указывать, а для остальных действует так называемый дефолтный маршрут (default). Обычно он обозначается нулевым адресом сети и нулевой маской. Для него указывается адрес основного шлюза и интерфейс, и все пакеты, для которых не указан маршрут, направляются согласно этим правилам.
Чем же маршрутизатор отличается от обычного хоста сети? Во-первых, наличием двух и более сетевых интерфейсов, во-вторых, правом перераспределять пакеты между этими интерфейсами, а в-третьих, наличием соответствующих записей в таблице маршрутизации. То есть любое устройство, имеющее более одного сетевого интерфейса, способно стать маршрутизатором. Маршрутизатор, получив предназначенный не ему пакет, прогоняет его через свой файрволл и, если этот пакет разрешен к передаче, смотрит в свою таблицу маршрутизации, чтобы найти маршрут для него. Если маршрут прописан, отправляет пакет по нему, если нет, пересылает по дефолтному. Но до того производит еще одно важное действие.
Помните, я упоминал про исключения, касающиеся изменения заголовка IP на пути от одного узла к другому? Вот и настало время рассказать про одно из них. Взгляните еще раз на заголовок IP-пакета. Обратите внимание на поле «Время жизни». Оно занимает один байт и, как следствие, может принимать значения от 0 до 255. По-английски оно именуется Time To Live, или, сокращенно, TTL. Так вот, каждый маршрутизатор, через который проходит пакет, уменьшает значение этого параметра на единицу. Если маршрутизатор получит пакет, у которого TTL равно нулю, то пакет будет уничтожен, а его отправителю будет послано специальное сообщение. Так сделано для того, чтобы при неверной настройке маршрутизации и образовании петель (кольцевых цепей) пакеты рано или поздно были уничтожены. На этом основана работа программы Traceroute, о ней написано во врезке. Вот мы и рассмотрели протокол IP. Однако конкретную пользу приносят протоколы, функционирующие на его основе.
Протокол ICMP
Самый простой из протоколов на основе IP. Наиболее востребованная его функция — определять, жив ли конкретный хост сети и доходят ли до него IP-пакеты. Для этого используется популярная команда ping, отсылающая специальные ICMP-запросы, на которые удаленный хост должен дать ответ. Также замеряется время, за которое данные прошли весь путь туда и обратно.
Протоколы TCP и UDP
Как я писал в предыдущей части статьи, протокол IP отвечает только за доставку данных от одного хоста к другому, но не идентифицирует приложения, отправившие и принявшие их. А вот доставкой данных от одного приложения к другому, помимо прочих, занимаются именно TCP и UDP. При их изучении необходимо запомнить одно из основных понятий, которыми мы будем пользоваться, — порт. Это сугубо логический элемент, через который передаются данные. Пара портов на концах соединения однозначно идентифицирует это соединение.
В рамках пакета данных (от уровня MAC до прикладного) идентификатор порта (его номер) обычно фигурирует только в заголовке TCP или UDP. У каждой системы 65 535 портов для работы по TCP и столько же для работы по UDP. Порты делятся на привилегированные (от 1-го до 1023-го) и непривилегированные (от 1024-го до 65 535-го). Изначально считалось, что привилегированные предназначены для установки входящего соединения, непривилегированные — для установки исходящего, а для инициализации привилегированного необходимы административные права. Однако на практике соблюдаются только второе и третье правила. Ну, с портами разобрались, а те, кому непонятно, поймут по ходу чтения. Перейдем к рассмотрению самих протоколов.
Протокол UDP
Его заголовок приведен в таблице 2. (Краткость — сестра таланта. Однако контроль соединения отсутствует, что затрудняет диагностику и выявление проблем средствами транспортного уровня. Но контрольная сумма есть — и то хорошо.) UDP не предоставляет никаких возможностей, кроме фактической идентификации потока данных и проверки целостности доставки при помощи контрольной суммы. Но вместе с тем он не порождает лишнего трафика пакетами подтверждения, в отличие от TCP. В основном этот протокол используется для передачи данных некритичных либо тех, целостность которых контролируется протоколами более высокого уровня. Хорошие примеры сфер применения UDP — это запросы системы DNS, протокол TFTP (не путать с FTP!), а также всевозможные сетевые компьютерные игры. Однако поток важных данных или поток, для которого задержки некритичны, этому протоколу доверять не следует.
Так как UDP не поддерживает сессии, существуют только два начальных состояния порта: закрыт и открыт. Если порт закрыт, то все данные, приходящие на него (в качестве номера порта получателя указан номер закрытого порта), отвергаются, если открыт, то данные передаются приложению, открывшему порт. Если приложение отвечает (посылает данные в ответ), ОС отправляет UDP-пакет, в котором меняет местами номер порта отправителя и номер порта получателя. Благодаря этому приложение, инициировавшее соединение, понимает, в рамках какого соединения (на один хост может приходиться несколько соединений одновременно, да что там — даже на один порт, но порт отправителя для каждого соединения свой) были переданы данные.
Протокол TCP
Он работает значительно медленнее UDP, но зато обеспечивает контроль целостности данных и гарантирует их доставку до порта получателя (но не доставку до самого получателя). Почему-то TCP используется гораздо интенсивнее, чем UDP. (См. таблицу 3. Протокол поддерживает множество опций, однако некоторые из них не используются вообще.) Так уж исторически сложилось. Возможно, отчасти потому, что, несмотря на сложность самого протокола, реализовать приложения на его основе намного проще, чем на основе UDP. Нелегкая функция контроля целостности данных в этом случае ложится на ОС, а пользовательские приложения гоняют данные в обе стороны, как по трубе.
Возможна передача данных по протоколу TCP одновременно в двух направлениях, а для того, чтобы не запутаться, где какие данные, существует механизм контроля, представленный полями Sequence Number (SeqNum) и Acknowledgement Number (AckNum). SeqNum содержит номер первого передаваемого байта, AckNum — номер первого ожидаемого байта. Ориентируясь на эти номера, ни одна система не запутается, что делать с только что пришедшими данными — передать приложению или подождать пропавший кусок. Дело в том, что у глобальных сетей есть особенность, обусловленная динамической маршрутизацией: первый отправленный пакет может прийти позже второго. Для того и был введен вышеописанный механизм контроля.
Рассмотрим сам протокол и особенности его работы. Согласно спецификации, у порта есть несколько состояний. Для того чтобы соединение было установлено, порт должен находиться в состоянии Listen (ждать запроса на соединение), иначе любые данные, приходящие на него, будут отброшены. Соединение устанавливается, когда на открытый порт приходит пакет с флагом SYN и SeqNum = 100. На это система отвечает либо пакетом с флагами SYN и ACK, SeqNum = 300, AckNum = 101, если соединение можно установить, либо пакетом с флагом RST в ином случае. Если соединение возможно, то инициирующая его система отсылает пакет с битом ACK, SeqNum = 101, AckNum = 301, после чего разрешается передача, соединение установлено, порты переводятся в состояние Established (готовы к приему).
Завершение соединения чуть сложнее его установки. Сторона, решившая завершить соединение, отправляет пакет с битами FIN и ACK, SeqNum = 100, AckNum = 300 и переводит свой порт в состояние FIN-WAIT-1. Другая сторона должна ответить битом ACK, SeqNum = 300, AckNum = 101, что переведет порт первой в состояние FIN-WAIT-2, а порт второй — в состояние LAST-ACK. Для того чтобы перевести порт в изначальное состояние, требуется еще один пакет с битами FIN и ACK, SeqNum = 300, AckNum = 101. После получения пакета с битом ACK, SeqNum = 101, AckNum = 301 и небольшого тайм-аута оба порта переводятся в свои исходные состояния. Я бы с радостью привел схему состояний сокета TCP, да боюсь, что многоуважаемый Барсик мне этого не даст сделать. (Вам волю дай — ничего, кроме таблиц и графиков, не оставите! — Прим. ред.) Чтобы более подробно узнать про работу протокола TCP, а также увидеть много схем и рисунков по теме, прочтите RFC 793:
www.ibiblio.org/pub/docs/rfc/rfc793.txt.
Технология NAT
С IP, TCP, UDP и портами разобрались, пора поговорить о том, как экономится адресное пространство в Сети. Когда американцы, интернет изобретшие, поняли, что они не одни на свете (а они что, все-таки поняли?! — Прим. ред.), а адресов на всех не хватит, выяснилось, что далеко не каждая машина должна иметь возможность принимать входящие соединения, но каждая должна иметь возможность установить соединение с необходимым ей сервером. И была придумана технология, позволяющая локальной сети выглядеть для остального мира единым хостом. Специально для этого были выделены три адресные зоны: 10 / 8, 172.16 / 12 и 192.168 / 16. (Вы у меня умные, короткую запись понимаете, могу позволить себе такую вольность.) Вообще, зоны должны подбираться в зависимости от размера сети, а на деле все решают предпочтения системного администратора. Я вот, например, сетку 10 / 8 люблю.
Особенность этих адресов в том, что во «внешнем» интернете они не используются: любой маршрутизатор приняв через интерфейс, не обслуживающий такую сеть (то есть на нем не прописаны адреса этих зон), пакет, в котором адрес отправителя или получателя входит в вышеприведенные диапазоны, уничтожит его.
Продвинутый пользователь поинтересуется: «А вот у меня на машине адрес 10.0.0.200 — и ничего! Интернет работает! Как так?» Дело в том, что такой пользователь находится под юрисдикцией NAT (Network Address Translation), которая и позволяет ему безбоязненно ходить в Сеть. Как же это происходит?
Роутер получает TCP-пакет с флагом SYN и SeqNum = 100 (вспоминаем, что такой пакет инициирует начало нового соединения), отправленный, например, серверу http://www.livejournal.com/ (204.9.177.18) на порт 80 от хоста внутренней сети 10.9.8.7 с порта 3847 (соединение всегда устанавливается со случайно выбранного непривилегированного порта). После того как файрволл, а возможно, еще и антивирус проверил пакет на вшивость, маршрутизатор принимает решение пропустить его. Но он не передает пакет в изначальном виде дальше, а сам случайным образом выбирает непривилегированный порт и меняет в заголовке IP-адрес отправителя на свой внешний (или какой указан в конфигурации), например 87.215.125.14, а в заголовке TCP вместо порта отправителя ставит только что выбранный. Далее маршрутизатор вносит в таблицу преобразований следующую запись: «Внутренний адрес и порт — 10.9.8.7:3847.
Внешний адрес и порт — 87.215.125.14:33203. Адрес и порт соединения — 204.9.177.18:80. Протокол — TCP» — и отправляет пакет согласно своей таблице маршрутизации. Благодаря этой записи в тот момент, когда с 204.9.177.18:80 придет пакет для 87.215.125.14:33203, маршрутизатор заменит IP-адрес получателя (пакет-то входящий!) на 10.9.8.7, а порт получателя — на 3847, хост внутренней сети примет и обработает пакет как ни в чем не бывало. Эта схема замечательна тем, что таких преобразований на пути пакета может быть несколько. К примеру, вы абонент локальной сети с внутренней зоной адресов 10 / 8 и ставите у себя дома маршрутизатор (точку доступа Wi-Fi). На внешнем интерфейсе вы прописываете адрес 10.9.8.7, а на внутреннем — 192.168.0.1 / 24. Тогда пакет от вашего ноутбука с адресом 192.168.0.10 / 24 пройдет два преобразования: одно — в точке доступа, другое — в маршрутизаторе локальной сети.
Еще одна особенность системы NAT в том, что ни один хост из интернета не может установить прямое соединение с внутренним хостом локальной сети. С одной стороны, хорошо, так всяким хакерам сложнее добраться до машин, с другой — это правило распространяется и на сервера, которые, возможно, должны быть видны снаружи (например, почтовые или веб-сервера). Для этого была придумана схема «проброски» портов. Различными средствами создается, например, такая запись в таблице преобразования: «Внутренний адрес сети — 10.9.8.7:80.
Внешний адрес — 87.215.125.14:80. Соединение открыто. Протокол — TCP». В таком случае при получении TCP-пакета с SYN и SeqNum = 100 маршрутизатор отправит хосту 10.9.8.7 на 80-й порт пакет с обратным адресом и портом хоста, установившего соединение (конечно, только в случае, если такое соединение одобрено файрволлом). Далее данные будут преобразовываться по вышеприведенной схеме. Таким образом, и эта проблема решаема. Между прочим, на маршрутизаторе можно прописать даже такую строчку: «Внутренний адрес — 10.9.8.7. Внешний адрес — 87.215.125.16. Соединения открыты. Протоколы — TCP и UDP». Тогда, если маршрутизатор получит на внешний интерфейс пакет для 87.215.125.16, он заменит только IP-адрес и отправит внутреннему хосту. Конечно, в данном случае файрволл тоже работает.
Ну, вот мы и разобрали основные технологии транспортного и сетевого уровней. Если вам захотелось понять, как именно компонуются пакеты, где какие заголовки используются и как все это выглядит вместе, воспользуйтесь любым доступным сниффером. Пользователям ОС Windows рекомендую утилиту Iris Network Traffic Analyzer. Она наглядно показывает заголовки пакета и их поля. Пользователям Linux советую программу tcpdump, которая, несмотря на свое название, показывает не только TCP, но и UDP, а также просто Ethernet-пакеты. Очень полезно для понимания принципов работы сетей. Можно на «живых» пакетах посмотреть, как какие байты располагаются, и соотнести приведенные в статье рисунки с реальными данными. На сегодня все. Cоветую вам почитать и следующую часть статьи, посвященную протоколам прикладного уровня. Продолжение следует…
UDP hole punching для Symmetric NAT: немного теории и почти честный эксперимент
Доброго времени суток, коллеги.
Некоторое время назад заинтересовался сабжем. Поиск дал много материала, при изучении которого возник ряд вопросов и захотелось некоторые теоретические моменты проверить на практике. Кому интересно — прошу.
Для тех, кто не в теме коротко о том, что такое Symmetric NAT.
Рассмотрим простую схему, в которой
хост1, хост2 — пользовательские хосты за NAT-ами
NAT1, NAT2 — пограничные устройства, обеспечивающие NAT
Когда хост1 инициирует исходящее соединение (TCP или UDP) на некий реальный_IP, устройство NAT1 заменяет в исходящем пакете IP источника на свой (необязательно на свой, но примем это для простоты и наглядности), а так же в общем случае заменяет PORT_SRC на случайный PORT_SRC1.
Так вот, NAT будет симметричным, если от хоста реальный_IP ответный пакет будет пропущен устройством NAT1 тогда и только тогда, когда собственно IP источника в таком ответном пакете будет реальный_IP, порт источника будет PORT_DST, а порт назначения — PORT_SRC1. Т. е. реальный_IP ответит от своего адреса, с того же порта, на который был коннект, и на тот же порт, с которого был исходящий коннект с устройства NAT1. Не трудно заметить, что термин «симметрия» тут затесался не зря.
Что же мы имеем, когда стоит задача «пробить» симметричный NAT и дать возможность хостам за ним общаться напрямую?
В общем случае имеем следующую простую схемку.
yy.yy.yy.yy.45499: UDP, length 0
05:07:00.178149 IP xx.xx.xx.xx.21393 > yy.yy.yy.yy.45499: UDP, length 0
06:28:35.355623 IP xx.xx.xx.xx.21393 > yy.yy.yy.yy.45499: UDP, length 0
07:16:29.764069 IP xx.xx.xx.xx.21393 > yy.yy.yy.yy.45499: UDP, length 0
11:28:06.899109 IP xx.xx.xx.xx.21393 > yy.yy.yy.yy.45499: UDP, length 0
Вывод снифера на хосте1, в котором «засечен» пробой (время не синхронизировано, отсюда некоторое несоответствие временных меток распечатке из дампа трафика хоста2).
02:18:20.480468 IP xx.xx.xx.xx.21393 > 10.140.80.130.2429: UDP, length 0
05:06:15.496093 IP xx.xx.xx.xx.21393 > 10.140.80.130.2429: UDP, length 0
06:27:50.464843 IP xx.xx.xx.xx.21393 > 10.140.80.130.2429: UDP, length 0
07:15:44.839843 IP xx.xx.xx.xx.21393 > 10.140.80.130.2429: UDP, length 0
11:27:21.589843 IP xx.xx.xx.xx.21393 > 10.140.80.130.2429: UDP, length 0
Был еще результат дампа непосредственно на хосте2, в котором было видно, что поддерживающие неизменной трансляцию на NAT1 пакеты из пункта 4 до хост2 стали доходить, но я его посеял.
Вот такой не совсем честный эксперимент. Но он показал, что даже при относительно невысокой частоте перебора в пункте 7 нужного результата можно достичь за относительно разумное время. Оно может стать еще более разумным при более агрессивном переборе. Конечно, на «промышленное» применение не тянет, но… Но это возможно. Описанный алгоритм и эксперимент дает пищу для размышлений на тему ускорения-оптимизации-многопоточного_подхода и прочее подобное.
UPD: забыл упомянуть, что с хоста2 пакеты отправлялись со сменой порта источника, что бы за NAT2 порт источника тоже менялся, ждать, пока умрет трансляция на NAT2 — слишком накладно.