Привет всем, помоему нашел решение этому, положу здесь, наверное будет кому нибудь тоже интересно. Нашел недавно вот что https://github.com/samyk/pwnat
Это чтоб пробиться сквозь NAT, и оттуда же :
##
Шаг 1: Полный перевод текстаНиже приведён полный перевод статьи "Autonomous NAT Traversal" на русский язык. Вы можете скопировать этот текст и вставить его в текстовый редактор (например, Microsoft Word, Google Docs, LibreOffice и т. д.), а затем экспортировать как PDF.
---
# Автономное преодоление NAT
Андреас Мюллер, Натан Эванс, Кристиан Гротхофф
Сетевые архитектуры и сервисы, Технический университет Мюнхена
Email: {mueller,evans,grothoff}@net.in.tum.de
Сэм Камкар
Email: samy@samy.pl
Аннотация — Традиционные методы преодоления NAT требуют помощи третьей стороны для сигнализации. В этой статье исследуется новый автономный метод установления соединений с пиринговыми узлами, находящимися за NAT. Предложенный метод автономного преодоления NAT использует поддельные ICMP-сообщения для первоначального контакта с узлом, находящимся за NAT.
В работе описывается теоретическое обоснование работы метода, рассматриваются возможные вариации, представлены конкретные реализации предложенного подхода и проводится оценка эмпирических результатов измерительного исследования, предназначенного для оценки эффективности идеи на практике.
## I. Введение
Большая доля хостов в типичной одноранговой сети находится в домашних сетях. Большинство домашних сетей используют трансляцию сетевых адресов (NAT) [1], чтобы позволить нескольким компьютерам совместно использовать один глобальный публичный IP-адрес, повысить безопасность или просто потому, что оборудование поставщика обычно настроено именно так. Недавние исследования показали, что до 70% пользователей получают доступ к P2P-сетям через NAT [2].
Это создаёт хорошо известную проблему для одноранговых сетей, поскольку не всегда возможно инициировать соединение с узлом, находящимся за NAT. Для этой статьи мы будем использовать термин «сервер» для обозначения узла за NAT и «клиент» для любого другого узла, пытающегося установить соединение с сервером.
Если NAT не настроен вручную (протоколы, такие как Internet Gateway Device Protocol [3], считаются настройкой в данном контексте), почти все реализации NAT отклоняют входящий трафик, который не соответствует недавнему исходящему запросу. Это не столько проблема реализации: если в частной сети несколько хостов, NAT, вероятно, не может определить, какой из них является целевым получателем. Настройка NAT не всегда возможна; проблемы варьируются от удобства конечных пользователей и возможностей конкретной реализации NAT до административных политик, которые могут запрещать изменения в конфигурации NAT (например, из соображений безопасности).
Поскольку системы NAT блокируют входящие запросы, не соответствующие предыдущему исходящему запросу, все существующие техники преодоления NAT (за исключением тех, которые изменяют его конфигурацию), о которых нам известно, требуют некоторой степени активного участия третьей стороны [4],[5]. Основной подход в большинстве таких случаев заключается в том, что сервер в частной сети за NAT уведомляется третьей стороной о том, что клиент хочет установить соединение. Затем сервер инициирует соединение с клиентом. Это требует, чтобы сервер поддерживал соединение с третьей стороной, клиент мог найти ответственную третью сторону, и эта третья сторона действовала согласно определённому протоколу.
Целью этой статьи является автономное преодоление NAT, то есть преодоление NAT без использования третьей стороны. Использование третьих сторон увеличивает сложность программного обеспечения и потенциально вводит новые уязвимости. Например, если анонимные одноранговые сети (такие как GNUnet [6] или Tor [7]) использовали бы третьи стороны для преодоления NAT, злоумышленник мог бы отслеживать соединения или даже объёмы трафика узлов за NAT, что, в свою очередь, могло бы позволить атаки деанонимизации [8], [9]. Другая проблема заключается в том, что уменьшение количества доступных глобально маршрутизируемых IPv4-адресов [10] в ближайшем будущем резко снизит долю хостов, способных помочь в преодолении NAT.
## II. Технический подход
Предложенный метод предполагает, что клиент каким-то образом узнал текущий внешний (глобально маршрутизируемый) IP-адрес NAT-устройства сервера. Это может быть связано с предыдущим соединением между двумя системами или тем, что третья сторона предоставила IP-адрес ранее. Отметим, что мы специально предполагаем, что третья сторона недоступна в момент, когда клиент пытается подключиться к серверу за NAT.
Первая цель представленного метода преодоления NAT — сообщить серверу, находящемуся за NAT, публичный IP-адрес клиента, который хочет установить соединение. После того как сервер узнает IP-адрес клиента, он сам устанавливает соединение с клиентом (похоже на методы преодоления NAT, включающие третью сторону).
Ключевая идея для того, чтобы сервер смог узнать IP-адрес клиента, состоит в том, чтобы сервер периодически отправлял сообщение на фиксированный, известный IP-адрес. Самый простой подход — использовать ICMP ECHO REQUEST на нераспределённый IP-адрес, например 1.2.3.4. Поскольку 1.2.3.4 не выделен, ICMP-запрос не будет маршрутизироваться маршрутизаторами без маршрута по умолчанию; созданные этими маршрутизаторами сообщения ICMP DESTINATION UNREACHABLE можно просто игнорировать сервером.
В результате отправки сообщений на 1.2.3.4, NAT разрешит маршрутизацию ответов в ответ на этот запрос.
Подключающийся клиент затем подделывает такой ответ. Конкретно, клиент передаёт ICMP-сообщение с TTL_EXPIRED (рисунок 1). Такое сообщение может легитимно передаваться любым интернет-маршрутизатором, и адрес отправителя не должен совпадать с целевым IP-адресом сервера.
Сервер прослушивает (поддельные) ICMP-ответы и при получении инициирует соединение с IP-адресом, указанным в ICMP-ответе. Если клиент использует глобально маршрутизируемый IP-адрес, это не представляет никакой проблемы, и для установления двустороннего соединения можно использовать TCP или UDP, если клиент прослушивает заранее согласованный порт. В случаях, когда нет заранее согласованного порта, номер порта можно в большинстве случаев передать в виде полезной нагрузки ICMP ECHO RESPONSE, которую реализации NAT обычно не проверяют против полезной нагрузки соответствующего ICMP ECHO REQUEST.
### A. Связь между NAT-устройствами
Дополнительные сложности возникают, если и клиент, и сервер находятся за NAT. В этом случае клиент часто не может передать поддельный ICMP-ответ серверу из-за ограничений, накладываемых реализацией NAT клиента. Одной из возможных идей для обхода этой проблемы является отправка клиентом того же сообщения, что и сервер, но с TTL = 1 своему NAT. Если NAT принимает пакет, несмотря на поддельный IP-адрес отправителя, он теоретически может сгенерировать нужный ICMP-ответ и передать его во внешнюю сеть.
Однако на практике мы не нашли NAT, где генерация необходимого ICMP-сообщения с TTL = 1 работает.
Даже если клиент может передать поддельный ICMP-ответ, следующий этап — когда и клиент, и сервер знают IP-адреса друг друга и теперь хотят установить TCP- или UDP-соединение — может быть сложным. Причина в том, что NAT может менять номера исходных портов исходящих сообщений. Без третьей стороны клиент и сервер должны угадывать совпадающие номера исходных и целевых портов, выбранных (возможно случайно) их соответствующими реализациями NAT. В зависимости от типа реализации NAT (Full cone, restricted cone, port-restricted, symmetric), поиск правильного порта может занять несколько сообщений. Клиент и сервер могут сократить общее количество требуемых сообщений, передавая и прослушивая на нескольких портах на этом этапе.
### B. Использование UDP вместо ICMP ECHO REQUEST
Возможной альтернативой тому, чтобы отправитель передавал ICMP ECHO REQUEST на фиксированный, известный IP-адрес, является использование UDP-пакетов на фиксированный, известный IP-адрес и порт. В этом случае клиент снова подделывает ICMP TTL EXPIRED, только теперь в формате UDP. Основным недостатком этого варианта является то, что отправителю нужно угадать внешний номер UDP-порта отправителя при подделке ICMP-ответа. Поскольку некоторые реализации NAT случайным образом меняют эти номера портов, серверу может понадобиться отправлять UDP-пакеты с нескольких портов, чтобы дать клиенту достаточный шанс правильно угадать.
Основным преимуществом этого метода является то, что сервер больше не обязан использовать RAW-сокеты, что может снизить уровень привилегий, необходимый для сервера. Обратите внимание, что сервер всё ещё должен иметь возможность прослушивать ICMP-ответ, что требует RAW-сокетов в Linux. В случае full-cone NAT использование UDP вместо ICMP ECHO REQUEST также имеет преимущество в виде создания маппинга порта, который затем можно использовать как альтернативный метод связи с пиринговым узлом.
Ещё одно различие между двумя подходами — возможная полезная нагрузка, которая может быть внедрена в ответ. С ICMP ECHO REQUEST размер полезной нагрузки может быть таким же большим, как позволяет размер пакета, и ограничен только MTU соответствующей физической сети. Хорошо сформированные ICMP UDP TTL exceeded ответы, напротив, могут содержать только 32 бита полезной нагрузки: ответ ICMP TTL EXCEEDED содержит первые 64 бит полезной нагрузки оригинального IP-пакета. В этих 64 битах 16-битное поле контрольной суммы UDP и 16-битное поле длины UDP не проверяются (для NAT, которые не отслеживают подробную информацию о исходящих UDP-пакетах) и, следовательно, могут использоваться для передачи 32 бит информации серверу (в дополнение к IP-адресу отправителя). С нашим подходом любой из этих размеров полезной нагрузки достаточно велик, поскольку мы передаём только номер порта вместе с IP-адресом.
## III. РЕАЛИЗАЦИИ
Этот раздел суммирует три реализации предложенного метода, которые мы разработали на данный момент. Все представленные реализации свободно доступны на сайтах соответствующих проектов.
### A. Реализация в рамках NAT-Tester Framework
Наша реализация в рамках NAT-Tester Framework использовалась для сбора данных для этой статьи. Она передаёт различные типы пакетов (с полезной нагрузкой или без) с использованием RAW-сокетов и использует библиотеку libpcap для определения, какие сообщения были пропущены через NAT. Клиент сейчас доступен для Windows и Linux и должен запускаться с правами администратора. Эта реализация будет полезна исследователям, заинтересованным в изучении различных вариаций этого и других методов преодоления NAT.
### B. Реализация в инструменте pwnat
Инструмент pwnat — это автономная реализация преодоления NAT, предназначенная только для GNU/Linux. После установления связи с сервером за NAT, устанавливается канал с TCP-подобным поведением, используя UDP-пакеты. Поддерживает ситуацию, когда и клиент, и сервер находятся за NAT (если один из NAT позволяет отправлять поддельные ICMP-сообщения). Эта реализация ориентирована на конечных пользователей.
### C. Реализация в GNUnet Framework
В заключение, мы создали переиспользуемую реализацию рассмотренного метода преодоления NAT на основе ICMP в GNUnet — фреймворке GNU для безопасных одноранговых сетей.
Поскольку использование ICMP требует вызова нестандартных и часто привилегированных системных функций, реализация была разделена на три основные части:
#### ICMP-сервер
Эта часть представляет собой небольшую программу, которая обеспечивает базовые ICMP-функции для сервера. Программа периодически генерирует ICMP ECHO REQUEST и прослушивает входящие ICMP TTL EXCEEDED ответы. При получении такого ответа программа просто выводит IP-адрес отправителя в stdout. Если ICMP-сообщение содержит 16-байтовую полезную нагрузку, она интерпретируется как номер порта и также выводится.
#### ICMP-клиент
Это небольшая исполняемая программа, которая просто отправляет одно (поддельное) ICMP-сообщение на IP-адрес, указанный в командной строке. Также можно указать дополнительный аргумент, который будет интерпретироваться как номер порта для передачи в полезной нагрузке поддельного ICMP-ответа.
#### Плагин транспортного уровня
Эта часть реализует плагин транспорта GNUnet и, таким образом, специфична для одноранговой сети GNUnet. В зависимости от конфигурации узла, он управляет ICMP-сервером или клиентом и в конечном итоге устанавливает соединение между узлами.
Разделение реализации на эти три компонента имеет ряд преимуществ:
- Минимизируется объём кода, который должен выполняться с правами суперпользователя в системах POSIX (ICMP-сервер и клиент могут быть установлены с установленным битом SUID).
- Упрощается управление платформенно-зависимой частью кода.
- Облегчается повторное использование кода, связанного с ICMP, но не зависящего от конкретной одноранговой сети, что позволяет использовать его в других P2P-приложениях.
---
## IV. ЭКСПЕРИМЕНТАЛЬНЫЕ РЕЗУЛЬТАТЫ
Мы протестировали предложенные методы автономного преодоления NAT на большом количестве реализаций NAT с помощью нашего NAT-Tester Framework. Фреймворк состоит из публичного клиента, который добровольцы скачивают и запускают.
Клиент проводит различные тесты с локальной реализацией NAT и отправляет результаты обратно на сервер NAT-Tester. Это позволило нам проверить эффективность методов преодоления NAT на широком спектре реализаций NAT. Детальные результаты публикуются на сайте NAT-Tester.
В этом разделе мы обобщаем результаты на основе уже собранных данных.
Таблица I показывает, какая доля тестируемых реализаций NAT поддерживает предложенный метод автономного преодоления NAT. Мы различаем поведение, важное с точки зрения использования автономного преодоления NAT как клиентами, так и серверами за NAT. Мы рассматриваем два случая: когда сервер использует ICMP ECHO REQUEST и когда он использует UDP-пакеты.
Мы также анализируем степень случайности UDP-портов, что влияет на эффективность второго этапа при коммуникации NAT-to-NAT. Реализации NAT классифицируются по четырём типам: full cone, restricted cone, port-restricted и symmetric, если NAT-Tester смог определить тип. Реализации, не попадающие ни в одну из этих категорий, учитываются только в общем итоге.
Данные показывают, что практически все NAT пропускают поддельные ICMP-сообщения для UDP (UDP-Server), но только примерно в половине случаев — для ICMP ECHO REQUEST (Echo-Server). Кроме того, большинство NAT сохраняет исходный порт (если возможно), поэтому необходимость угадывания порта при подделке ICMP-ответа для UDP-сообщений не сильно влияет на общую стоимость подхода. Наконец, NAT почти всегда блокируют возможность клиентов передавать поддельные ICMP-сообщения, используемые нашими клиентами (Echo-Client, ICMP-UDP-Client). Причину мы видим в том, что правила NAT обычно допускают только ICMP-пакеты со статусами «NEW» и «ESTABLISHED», а поддельные ответы не попадают ни в одну из этих категорий.
---
## V. ОБСУЖДЕНИЕ
Предложенный метод автономного преодоления NAT хорошо работает в случае, когда клиент без ограничений пытается установить соединение с сервером за NAT. В таких ситуациях достаточно одного ICMP-сообщения от клиента, после чего происходит стандартное обращение соединения, которое надёжно создаёт UDP или TCP-соединение. Другими словами, в этом случае нет необходимости во внешней стороне для помощи в установлении соединения с сервером за NAT.
Однако, если оба устройства находятся за NAT, предложенный метод редко работает, и требуется помощь третьей стороны.
Если предположить, что 70% узлов в сети находятся за NAT, это означает, что около 50% всех возможных соединений можно установить с помощью автономного преодоления NAT. Однако даже в случае, когда оба устройства находятся за NAT, у предложенного метода остаётся потенциальное преимущество: легко создать простое, универсальное и полностью stateless-сервис, принимающий запросы от узлов за NAT и генерирующий поддельные ICMP-ответы для уведомления сервера. В этом случае полезная нагрузка ICMP-ответа должна содержать оригинальный IP-адрес (и, вероятно, исходный порт) клиента, поскольку заголовок поддельного ICMP-ответа теперь будет содержать IP-адрес сервиса.
---
## VI. ЗАКЛЮЧЕНИЕ
Поддельные ICMP-ответы позволяют осуществлять автономное преодоление NAT во многих случаях. Как и у большинства методов преодоления NAT, этот подход не работает во всех случаях. Необычной особенностью предложенного метода является то, что он работает очень хорошо, если только один из узлов находится за NAT, и практически никогда — если оба узла находятся за NAT. Системы, которым требуется высокий уровень успешного преодоления NAT, обычно используют несколько техник. Представленный метод расширяет набор доступных методов ещё одним, который, если применим, проще и дешевле большинства существующих решений.
---
## БЛАГОДАРНОСТИ
Авторы благодарят многочисленных добровольцев, которые скачали и запустили NAT-Tester, помогая собрать данные для оценки метода. Эта работа частично финансировалась Deutsche Forschungsgemeinschaft (DFG) в рамках проекта ENP GR 3688/1-1.
---
## ЛИТЕРАТУРА
[1] K. Egevang и P. Francis, «RFC 1631: The IP Network Address Translator (NAT)», 1994.
[2] M. Casado и M. J. Freedman, «Illuminating the shadows: Opportunistic network and web measurement», декабрь 2006.
[3] P. Iyer и U. Warrier, «Internet Gateway Device:1 Device Template Version 1.01», UPnP Forum, ноябрь 2001.
[4] J. Rosenberg и R. Mahy и др., «Session Traversal Utilities for NAT (STUN)», RFC 5389, IETF, октябрь 2008.
[5] J. Rosenberg, R. Mahy и P. Matthews, «Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)», RFC 5766, IETF, февраль 2010.
[6] K. Bennett и C. Grothoff, «GAP – Practical Anonymous Networking», Springer-Verlag, 2003.
[7] R. Dingledine, N. Mathewson и P. Syverson, «Tor: The second-generation onion router», в материалах 13-го USENIX Security Symposium, август 2004.
[8] S. J. Murdoch и G. Danezis, «Low-cost traffic analysis of Tor», SP ’05, IEEE Computer Society, май 2005.
[9] N. S. Evans, R. Dingledine и C. Grothoff, «A practical congestion attack on Tor using long paths», 18th USENIX Security Symposium, 2009.
[10] G. Huston, «IPv4 Address Report», март 2010.
[11] R. A. Ferreira, C. Grothoff и P. Ruth, «A Transport Layer Abstraction for Peer-to-Peer Networks», в материалах 3-го Международного симпозиума по кластерным вычислениям и технологиям Grid (GRID 2003), IEEE Computer Society, 2003.
[12] A. Müller, A. Klenk и G. Carle, «On the Applicability of knowledge-based NAT-Traversal for future Home Networks», IFIP Networking 2008, Springer, Сингапур, май 2008.
[13] A. Müller и A. Klenk и G. Carle, «Behavior and Classification of NAT devices and implications for NAT-Traversal», IEEE Special issue on Middleboxes, сентябрь 2008.
[14] G. N. Purdy, «Linux iptables Pocket Reference», O’Reilly Media, Inc., 2004.
[15] P. Srisuresh, B. Ford и D. Kegel, «RFC 5128: State of peer-to-peer (P2P) communication across network address translators (NATs)», 2008.
