Full cone nat что это такое

Соединение «серых» компьютеров при симметричном nat Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Гриценко Алексей Викторович

Представлен обзор механизма преобразования сетевых адресов NAT (Network Address Translation) по способу преобразования. Приведены данные о том, с какой частотой разные способы используются на практике. Рассмотрены различные схемы обхода NAT .

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Гриценко Алексей Викторович

Обеспечение передачи потоковых данных из локальных сетей с использованием Nat

Межпротокольный шлюз nat-pt с функциями dns-alg и ftp-alg для обеспечения взаимодействия между сетями IPv4 и IPv6

Обзор способов достоверной идентификации сетевых устройств
Проект компьютерной сети на основе технологии content Delivery Network
On data transfer between mobile web clients
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

CONNECTION OF PRIVATE IP ADDRESS COMPUTERS WITH SYMMETRIC NAT

The paper presents the review of NAT on the way of address translation. It provides the date on how often different methods are used in practice. Different NAT bypass schemes are considered.

Текст научной работы на тему «Соединение «серых» компьютеров при симметричном nat»

СОЕДИНЕНИЕ «СЕРЫХ» КОМПЬЮТЕРОВ ПРИ СИММЕТРИЧНОМ NAT

Донской государственный технический университет, Ростов-на-Дону, Российская Федерация

Представлен обзор механизма преобразования сетевых адресов NAT (Network Address Translation) по способу преобразования. Приведены данные о том, с какой частотой разные способы используются на практике. Рассмотрены различные схемы обхода NAT.

Ключевые слова: NAT, P2P, публичный адрес, UDP, hole punching.

CONNECTION OF PRIVATE IP ADDRESS COMPUTERS WITH SYMMETRIC NAT

Don State Technical University, Rostov-on-Don, Russian Federation

The paper presents the review of NAT on the way of address translation. It provides the date on how often different methods are used in practice. Different NAT bypass schemes are considered.

Keywords: NAT, P2P, public address, UDP, hole punching.

Введение. Пиринговые соединения (от узла к узлу) в последнее время все чаще и чаще используются в приложениях и сервисах. Такой подход небезоснователен, так как для дистрибьюторов услуги позволяет экономить ресурсы и повышать отказоустойчивость системы, лишая ее узкого места — сервера. Для конечных клиентов появляется дополнительная гарантия, исключающая прослушку и логгирование трафика третей стороной. На подготовительных стадиях работы по организации распределенных высокопроизводительных вычислений была выявлена проблема создания подобных прямых соединений между клиентами за NAT, в частности, наибольшие сложности вызывают симметричные NAT. Зачастую клиент находится в локальной подсети, имеющей свою адресацию («серые» ip-адреса), которая имеет лишь транслируемый выход во «вне». Клиент может быть как за домашним NAT, т.е. роутером/маршрутизатором, так и за NAT провайдера, а также за двумя и более NAT. Ключевым шагом организации прямых соединений является преодоление NAT.

Виды NAT по способу преобразования адресов.

1) Full Cone (полный конус).

Однозначная (взаимная) трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любой внешний хост может инициировать соединение с внутренним хостом.

2) Restricted Cone (ограниченный конус).

Постоянная трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любое соединение, инициированное с внутреннего адреса, позволяет в дальнейшем получать ему пакеты с любого порта того публичного хоста, к которому он отправлял пакет(ы) ранее. Отличие от Full Cone в том, что на узел будут маршрутизироваться только пакеты с того же IP, хотя порты источника могут различаться.

3) Port Restricted Cone (порт ограниченного конуса).

Постоянная трансляция между парой «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт», при которой входящие пакеты проходят на внутренний хост только с одного порта публичного хоста — того, на который внутренний хост уже посылал пакет. Отличие от Full Cone в том, что на узел будут маршрутизироваться пакеты с любого IP, но порт источника должен совпасть с портом назначения первой отправки.

4) Symmetric (симметричный).

Трансляция, при которой каждое соединение, инициируемое парой «внутренний адрес: внутренний порт» преобразуется в свободную уникальную случайно выбранную пару «публичный адрес: публичный порт». При этом инициация соединения из публичной сети невозможна.

По данным сервиса тестирования маршрутизаторов nattest.ne, разработанного Оливером Гассером (Технический университет Мюнхена), в процентном эквиваленте преобладают Port Restricted 50,9%, за ними Symmetric 15,5%, Full Cone: 13%, Restricted Cone 3,3%. Всего выборка содержит 12 182 протестированных узлов.

Currentiy we have 12177 data sets in our database NAT Types determined using the STUN Algorithm

Full Cone Address Port Symmetrie SymmetricFW Other

Рис. 2. Статистика существования NAT по типам

Обход NAT. Существующие механизмы позволяют обходить все конусные NAT, например, специально разработанный для этого высокоуровневый протокол STUN, подробно описан и закреплен в рекомендации RFC 5389. Рабочее предложение RFC (Request for Comments) — документ из серии пронумерованных информационных документов Интернета, содержащих технические спецификации и стандарты, широко применяемые во всемирной сети. Однако, наибольшие трудности вызывает обход Symmetric (симметричного) NAT. У данного типа трансляции внешний порт меняется при каждом соединении, либо по истечении некоторого времени (обычно 20-60 секунд). Симметричный NAT принимает пакеты с ip:port только от узла с которым самостоятельно установил соединение. До отправки во вне какого-либо пакета, сопоставления «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт» не существует в таблице маршрутизации NAT.

Способы обхода NAT:

1) Ретрансляция подключения через сторонний публичный сервер. Способ позволяет добиться 100% обхода любого NAT, однако переносит накладные расходы на сервер и снижает отказоустойчивость. Готовая реализация подобной ретрансляции — это протокол TURN.

2) Supernode — это ретрансляция через других клиентов сети, имеющих публичный адрес или конусный NAT [1 ].

3) STUN — это высокоуровневый сетевой протокол, который позволяет клиенту, находящемуся за сервером трансляции адресов (или за несколькими такими серверами),

определить свой внешний IP-адрес, способ трансляции адреса и порта во внешней сети, связанный с определённым внутренним номером порта [2].

4) ICE — это STUN + TURN. Пытается напрямую соединить клиентов по STUN, в случае неудачи начинает ретрансляцию посредством TURN.

5) Universal Plug and Play (UPnP) — набор сетевых протоколов, публикуемых форумом UPnP. Цель UPnP — универсальная автоматическая настройка сетевых устройств, как дома, так и в корпоративной среде. Состоит из набора сопутствующих протоколов, построенных на открытых интернет-стандартах. Позволяет открыть и перенаправить внешние порты, в том числе конфигурация передается NAT автоматически программным способом (внутри локальной сети) без физического доступа к NAT или его панели администратирования.

6) DMZ (англ. Demilitarized Zone — демилитаризованная зона, ДМЗ) — сегмент сети, содержащий общедоступные сервисы и отделяющий их от частных. Позволяет открыть и перенаправить внешние порты. Настройка осуществляется вручную при непосредственном доступе к маршрутизатору.

7) Port triggering/forwarding где статическое перенаправление портов это Port Forwarding, а динамическое перенаправление портов Port Triggering. Обе функции позволяют открыть и перенаправить внешние порты. Настройка осуществляется вручную при непосредственном доступе к маршрутизатору.

8) UDP hole punching — метод установления прямого соединения между двумя клиентами спрятанными за NAT [3]. Для инициации соединения требуется третья сторона — сервер, который виден обоим клиентам. Он позволяет определить клиентам свои внешние адреса и порты, по которым в дальнейшем будет инициировано соединение.

9) ICMP hole punching — метод установления прямого соединения между двумя клиентами спрятанными за NAT [4]. В отличии от обычного UDP hole punching, метод не требует третьего сервера для определения внешних адресов. Алгоритм отправляет ICMP ECHO REQUEST запросы в UDP виде, с низким значением TTL (Time to live — предельный период времени или число итераций или переходов, за который набор данных (пакет) может существовать до своего исчезновения) инкрементируя TTL от 1 в надежде, что, где-то посередине между NAT клиента и другими промежуточными сетями (или близко к клиенту) TTL истечет. Тогда произойдет возврат сообщения TTL_EXPIRED. Но так как был использован UDP-протокол, источник спалит свой внешний порт, по которому, собственно, в дальнейшем можно установить общение. ICMP UDP поддерживается не всеми маршрутизаторами.

10) Подмена источника — в случае с симметричным NAT, входящие пакеты могут быть доставлены только от ip:port источника, которому клиент отправлял запрос самостоятельно. Подмена источника пакета другим клиентом позволит соответствовать этому требованию. Однако существуют механизмы распознавания фальсификации данных, некоторые сети, файерволы, провайдеры, которые блокируют подобные пакеты.

Заключение. Способы обхода NAT имеют каждый свои особенности. Ни один способ (кроме ретрансляции) не дает 100% гарантии преодоления симметричных NAT, однако их совокупное использование позволяет максимизировать успех.

1. IT Administrators Guide [электронный ресурс] / Skype Limited 2010. — Режим доступа : https://download.skype.com/share/business/guides/skype-it-administrators-guide.pdf (дата обращения: 12.05.2017).

2. RFC 3489 — STUN — Simple Traversal of User Datagram Protocol (UDP). Network Address Translators (NATs). J. Rosenberg, J. Weinberger, dynamicsoft, C. Huitema, Microsoft, R. Mahy, Cisco, March 2003. 47 с.

3. A New Method for Symmetric NAT Traversal in UDP and TCP (Yuan Wei, Daisuke Yamada, Suguru Yoshida, Shigeki Goto) — Режим доступа :

https://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf (дата обращения: 10.05.2017).

4. Extended UDP Multiple Hole Punching Method to Traverse Large Scale NATs (Kazuhiro Tobe, Akihiro Shimoda, and Shigeki Goto) APAN Network Research Workshop 2010 at the 30th APAN Meeting August 9, 2010 Hanoi, Vietnam. 23 с.

Вопрос про Роутеру и его настройкам. Что такое Full cone nat и NAPT ?

Cone NAT, Full Cone NAT — Однозначная (взаимная) трансляция между парами «внутренний адрес: внутренний порт» и «публичный адрес: публичный порт». Любой внешний хост может инициировать соединение с внутренним хостом (если это разрешено в правилах межсетевого экрана).

Перегруженный NAT (NAPT, NAT Overload, PAT, маскарадинг) — форма динамического NAT, который отображает несколько незарегистрированных адресов в единственный зарегистрированный IP-адрес, используя различные порты. Известен также как PAT (Port Address Translation). При перегрузке каждый компьютер в частной сети транслируется в тот же самый адрес, но с различным номером порта.

Остальные ответы

Похожие вопросы

Малоизвестные подробности работы NAT

Используя терминологию Cisco, в контексте NAT есть четыре основных определения для IP-адресов. Рассмотрим их на примере, показанном на рисунке ниже. На обоих маршрутизаторах делается NAT (network address translation).

• Inside Local (IL) . Это адрес, присвоенный хосту, находящемуся в локальной сети. В данном случае адреса 10.0.0.100 и 172.16.0.100 — адреса IL.
• Inside Global (IG). Это внешний адрес, при отправлении пакетов на который они будут доставлены на хост с адресом IL. В данном случае для хоста 10.0.0.100 адресом IG является 111.222.0.1.
• Outside Global (OG) . Внешний адрес хоста, доступ к которому мы хотим получить из нашей локальной сети. В данном случае, если мы отправляем пакет от 10.0.0.100 для 172.16.0.100, адресом OG будет 111.222.0.2.
• Outside Local (OL) . Это адрес, под которым адреса внешних хостов видны внутри локальной сети. В данном случае, если мы отправляем пакет от 10.0.0.100 для 172.16.0.100, для хоста 172.16.0.100 это будет выглядеть так, будто пакет пришёл от 172.16.0.1 (адрес OL).

• в исходящих пакетах адрес источника IL заменяется на IG, и пакет отправляется дальше по роутингу к хосту с адресом OG;
• во входящих пакетах адрес приемника IG заменяется на IL и отправляется в локальную сеть для хоста с адресом IL.

Таким образом, в таблице сопоставлений NAT каждая запись состоит из двух значений — IL и IG.

Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.

• транспортный протокол;
• локальный адрес (IL);
• локальный порт;
• глобальный адрес (IG);
• глобальный порт.

Это позволяет использовать единственный публичный адрес для предоставления доступа в Интернет компьютерам, находящимся в локальной сети. В документации Cisco такая схема обычно называется «NAT with port overload» или короче — «NAT overload» .

Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «NAT», и о нём мы и будем говорить в дальнейшем, ввиду его распространённости.

До сих пор речь шла о вещах общеизвестных. Однако, если посмотреть на NAT поближе, возникают новые вопросы. Возьмём простейшую сеть, с одним компьютером и одним маршрутизатором, выполняющим NAT. Модель маршрутизатора в данном случае не слишком важна — допустим, что это давно устаревшая, но все еще популярная Cisco 1601R.

В конфигурации маршрутизатора указано, что он должен выполнять NAT для всех пакетов, с адресами источника 192.168.0.0/24, пришедших через интерфейс Ethernet0 и отправляемых далее через интерфейс Serial0, а также для ответных пакетов, пришедших через Serial0, для которых есть соответствующая запись в таблице трансляций:

interface Serial0
ip address 11.22.33.44 255.255.255.252
ip nat outside

interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside

ip nat inside source list MyNetwork interface Serial0 overload
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any

Предположим, компьютер с адресом IL 192.168.0.141 отправляет DNS-запрос на внешний хост 1.2.3.4 (порт 53, протокол UDP). Как следует из конфигурации, наш внешний адрес IG — 11.22.33.44.

В результате этого в таблице NAT появится примерно такая запись:

Proto Inside global Inside local Outside local Outside global

UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

Допустим, после появления такой записи в таблице, другой хост, 1.2.3.5, отправляет пакет UDP с адресом назначения 11.22.33.44 и портом назначения 1053. Вопрос — получит ли наш хост 192.168.0.141 этот пакет?

Здравый смысл подсказывает, что вроде бы не должен. С другой стороны, налицо факт: в нашей таблице NAT черным по белому записано, что пакет с адресом назначения 11.22.33.44 и портом назначения 1053 нужно принять и транслировать в локальную сеть для хоста 192.168.0.141 (который его примет и молча уничтожит, поскольку на этом компьютере не запущено сетевого приложения, которому был бы предназначен этот пакет.)

Кстати говоря — ну хорошо, допустим такого приложения нет, а если бы оно было? Как хорошо известно пользователям таких программ, как eMule и eDonkey, они требуют, чтобы им была предоставлена возможность беспрепятственно получать UDP пакеты с портом назначения 4661, или 4242, или 4321 — точный номер порта зависит от настроек. И, что также хорошо известно их пользователям, эти программы плохо работают, будучи запущены из локальной сети, находящейся за NAT. Так вот, это может происходить, в том числе и потому, что несмотря на успешное установление локальным клиентом соединения с сервером, из-за специфики данной конкретной реализации NAT другие клиенты, находящиеся во внешнем мире, не могут устанавливать соединение с локальным клиентом.

По этой же причине может не работать DCC chat в клиентах IRC, передача файлов в ICQ и тому подобные вещи, для которых требуется обеспечение беспрепятственного прохождения пакетов непосредственно между пользовательскими компьютерами.

Итак, отвечая на вопрос, «получит ли наш хост 192.168.0.141 пакет, направленный на 11.22.33.44 от постороннего хоста», — может быть, получит, а может быть, и нет; ответ на этот вопрос зависит от реализации NAT на пограничном маршрутизаторе.

• Symmetric NAT . До недавнего времени это была наиболее распространённая реализация. Его характерная особенность — в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 — ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже.
• Full Cone NAT . Эта реализация NAT — полная противоположность предыдущей. При Full Cone NAT входящие пакеты от любого внешнего хоста будут оттранслированы и переправлены соответствующему хосту в локальной сети, если в таблице NAT присутствует соответствующая запись. Более того, номер порта источника в этом случае тоже не имеет значения — он может быть и 53, и 54, и вообще каким угодно. Например, если некое приложение, запущенное на компьютере в локальной сети, инициировало получение пакетов UDP от внешнего хоста 1.2.3.4 на локальный порт 4444, то пакеты UDP для этого приложения смогут слать также и 1.2.3.5, и 1.2.3.6, и вообще все до тех пор, пока запись в таблице NAT не будет по какой-либо причине удалена. Ещё раз: в этой реализации NAT во входящих пакетах проверяется только транспортный протокол, адрес назначения и порт назначения, адрес и порт источника значения не имеют.
• Address Restricted Cone NAT (он же Restricted NAT). Эта реализация занимает промежуточное положение между Symmetric и Full Cone реализациями NAT — маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае 1.2.3.4), но номер порта источника при этом может быть любым.
• Port Restricted Cone NAT (или Port Restricted NAT). То же, что и Address Restricted Cone NAT, но в этом случае маршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.

Как видим, реализации NAT — это настоящий зоопарк, в котором каждой твари по паре. Положение смягчается тем, что для большинства сетевых приложений подробности реализации NAT большого значения не имеют (в особенности для приложений, использующих транспорт TCP, как известно, это протокол, использующий сессии, поэтому сказанное выше для TCP неактуально. Тем не менее с развитием приложений Peer-to-Peer (eDonkey, eMule, Skype), IPтелефонии и разнообразной сетевой мультимедии (зачастую использующих транспорт на основе UDP) различия в реализациях NAT постепенно начинают играть заметную роль. Поэтому для разработчиков таких приложений пришла пора задуматься над тем, как их детище будет работать, находясь в локальной сети за NATом. Одним из плодов таких раздумий стал протокол STUN (Simple Traversal of UDP through NAT), описанный в RFC 3489.

Некоторым приложениям, особенно предназначенным для IP-телефонии (поскольку там это наиболее актуально), важно знать, находится ли компьютер, на котором они запущены, в локальной сети за NAT или на компьютере с публичным IP адресом, и в случае NAT — определить, какого он типа. Для этого в настоящее время широко используется протокол STUN, который позволяет также определить наличие блокирующего firewall на пограничном маршрутизаторе или самом компьютере.

Протокол STUN

Идея STUN несложна — клиент отправляет на находящийся снаружи сервер зондирующие сообщения, используя транспорт UDP. В теле этих сообщений содержатся IP адреса и номера портов источника и приемника. Непременным условием работы сервера является использование им двух IP-адресов — дальше станет понятно, для чего.

• Клиент отправляет запрос на основной адрес сервера (11.22.33.1), при этом в теле отправленного запроса указаны адреса и порты: 192.168.0.111:1055 -> 11.22.33.1:3478. Эти же адреса и порты фигурируют в заголовке IP-пакета, содержащего запрос, но после прохождения NAT адрес источника изменится на 1.2.3.4, а номер порта в зависимости от реализации NAT может измениться или остаться неизменным. Если клиент не получает никакого ответа в течение тайм-аута, он делает вывод, что находится за блокирующим firewall, и завершает работу.
• Сервер отвечает клиенту со своего адреса 11.22.33.1 сообщением, в теле которого также указаны адреса и порты: 11.22.33.1:3478 -> 1.2.3.4:1055. Если бы адрес, с которого клиент отправлял своё первое сообщение (192.168.0.111), и адрес в полученном от сервера сообщении (1.2.3.4) совпали, клиент сделал бы вывод, что на пути пакетов NAT отсутствует. В этом случае клиент и сервер обменялись бы еще парой запросов-ответов, на основании которых можно было бы определить, не находится ли по пути между ними firewall, блокирующий входящие пакеты UDP. Поскольку они не совпадают, очевидно, что на пути между клиентом и сервером находится NAT. В этом же сообщении сервер информирует клиента о своем альтернативном IP-адресе (11.22.33.2) и номере порта (3478).
• После этого клиент отправляет второе зондирующее сообщение, в котором установлен специальный флажок, указывающий серверу, что клиент ожидает ответа с альтернативного IP-адреса сервера (11.22.33.2), и с другим номером порта источника. Если клиент получает ответ на этот запрос, делается вывод, что находящийся по пути между ними NAT относится к Full Cone типу.
• Если ответ на предыдущий запрос не был получен, клиент повторяет свое первое зондирующее сообщение на альтернативный адрес STUN сервера. Если в полученном ответе адрес и номер порта отличаются от указанных в первом ответе, это означает, что этот запрос инициировал появление в таблице NAT новой записи. Такое поведение характерно исключительно для Symmetric NAT.
• Если адрес и номер порта в полученном ответе остались такими же, какими они были в первом ответе, то NAT относится к типу Restricted Cone. Осталось установить, является ли он Address Restricted или Port Restricted. Для этого клиент отсылает четвертое сообщение, в котором установлен флажок, указывающий серверу, что он должен ответить, используя порт источника с другим номером. Если ответ был получен, NAT относится к Address Restricted Cone, если нет — то к Port Restricted Cone.

Для иллюстрации работы STUN рассмотрим следующий рисунок(взят из статьи «Anatomy: A Look Inside Network Address Translators» в «The IP Journal» Vol.7 Num. 2 за сентябрь 2004 г.).

Клиент STUN встроен в некоторые приложения IP-телефонии, например, X-Pro и X-Lite от компании CounterPath, и в некоторые другие. Консольный клиент STUN под ОС Windows может быть загружен отсюда: http://prdownloads.sourceforge.net/stun/client.exe?download.

Запустив его и указав в качестве параметра командной строки один из публичных STUN-серверов, вы узнаете тип вашего NAT:

C:\>client.exe stun.xten.com

STUN client version 0.94
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9

Приведённый выше результат получен на компьютере, находящемся за маршрутизатором ZyXEL Prestige 645R.

Результат для маршрутизатора Cisco 1721 с IOS версии 12.2 в свою очередь выглядит так:

C:\>client.exe stun.xten.net

STUN client version 0.94
.
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b

Такой же результат получен для маршрутизатора, построенного на основе FreeBSD, на которой NAT выполнялась демоном natd.

А вот как выглядит результат для PIX (прим. HunSolo)

C:\>client.exe stun.xten.net

STUN client version 0.94
.
Primary: Port Restricted Nat, rundom port, no hairpin
Return value is 0xb

Осталось объяснить, что такое «random port», «preserves ports» и «no hairpin» в приведенных выше результатах.

Посмотрим еще раз на строчку из таблицы NAT в нашем примере:

Proto Inside global Inside local Outside local Outside global

UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

Random port означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника. Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.

Как видно из примера, наш маршрутизатор старается сохранять номер порта неизменным (11.22.33.44:1053 и 192.168.0.141:1053), из чего следует, что запущенный в его локальной сети STUN-клиент сообщил бы о нем preserves ports . К слову, на FreeBSD этот результат достигается ключом «-same_ports» или «-s» в строчке запуска или конфигурационном файле демона natd.

Hairpin же означает следующее. Допустим, при наличии в таблице NAT приведенной выше строчки другой хост нашей локальной сети (например, 192.168.0.241) отправляет UDP-пакет с адресом назначения 11.22.33.44, портом назначения 1053 и портом источника 53. Что произойдет в результате?

Ответ на этот вопрос зависит от того, поддерживает маршрутизатор функцию «hairpin» или не поддерживает. Если он ее поддерживает, пакет будет обычным образом обработан и (если на маршрутизаторе используется реализация NAT Full Cone или Port Restricted) попадет по назначению — на хост 192.168.0.141. Если же нет («no hairpin»), пакет будет уничтожен маршрутизатором. Название функции «hairpin» (шпилька для волос) произошло от того, что, если изобразить прохождение такого пакета на рисунке, форма его траектории будет похожа на U-образную шпильку. Другое объяснение — слово «hairpin» переводится так же, как «разворот на 180 градусов». При поддержке маршрутизатором функции «hairpin» подпадающие под ее действие пакеты, действительно, будут развернуты на 180 градусов и отправлены обратно в локальную сеть.

NAT и шлюзы приложений

К сожалению, не у всех сетевых протоколов взаимодействие с NAT протекает безболезненно. Наиболее часто встречающийся пример — это FTP. Здесь возможны два случая.

Первый случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу с публичным IP-адресом

Проблема здесь возникает, когда клиент пытается использовать активный режим FTP. Сессия протекает при этом следующим образом. В некоторый момент по управляющему соединению серверу передается команда FTP-клиента: PORT 192,16,0,101,4,211.

Дальнейший диалог выглядит примерно так:

Server: 200 PORT command successful. Consider using PASV.
Client: RETR file.zip
Server: 150 Opening BINARY mode data connection for file.zip (1334109 bytes).

Наибольший интерес здесь представляет первая команда от клиента, которая информирует сервер о том, что хост с адресом 192.168.0.101 открыл для приема соединения данных порт номер (4*256) + 211 = 1235. В ответ на это сервер должен установить соединение данных со своего порта номер 20 на указанный порт хоста 192.168.0.101. Поскольку этот адрес является приватным, такое соединение не может быть установлено. В результате наблюдается знакомый многим системным администраторам эффект, когда клиент вроде бы успешно подключается к FTP-серверу, но не может скачивать с него файлы или даже просматривать содержимое текущего каталога (это происходит потому, что передача листинга файлов с сервера на клиент также осуществляется по соединению данных).

ля борьбы с описанной проблемой может использоваться переключение сервера в так называемый пассивный режим. Поскольку в этом режиме инициатором соединения данных выступает клиент, проблема исчезает. Именно поэтому в Microsoft Internet Explorer, как и консольный FTP-клиент, встроенный в Windows, используют по умолчанию пассивный режим (они автоматически вставляют перед командами RETR и NLST команду PASV, переключающую сервер в пассивный режим).

Второй случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу, который также находится за NAT. В этом случае, очевидно, не поможет и пассивный режим, так как в команде PORT независимо от того, клиент или сервер ее отдает, всегда будет указан приватный IP-адрес, и соединение данных никогда не будет установлено.

Для разрешения этой проблемы в некоторых реализациях NAT существует специальная функция — трансляция адресов на уровне приложений, называемая также NAT ALG (Application Level Gateways). При задействованной функции ALG маршрутизатор отслеживает и модифицирует данные уровня приложений некоторых сетевых протоколов.

Так, в приведенном выше примере, если предположить, что публичный IP-адрес маршрутизатора с NAT 1.2.3.4 и что он сохраняет номер порта источника неизменным, команда PORT 192,16,0,101,4,211 была бы изменена маршрутизатором на PORT 1,2,3,4,4,211. Благодаря этому в обоих указанных выше случаях соединение данных будет успешно установлено.

Функция ALG в маршрутизаторах Cisco позволяет осуществлять трансляцию адресов уровня приложений не только для протокола FTP, но также и для протоколов SIP, H.323, Skinny и некоторых других (благодаря этому можно, например, размещать в локальной сети серверы DNS). Для большего удобства функция ALG в маршрутизаторах Cisco включена по умолчанию.

Аналогичную ALG функциональность в маршрутизаторах на основе ОС Linux обеспечивают дополнительные загружаемые модули и патчи к ядру (такие, как ip_masq_ftp, ip_masq_irc и т. п.).

Заключение

Понимание принципов работы различных реализаций NAT может оказаться полезным при поиске причины неудовлетворительной работы некоторых приложений, использующих транспортный протокол UDP. Так, например, сочетание ALG и Symmetric или Port Restricted NAT и IP-телефонов, использующих протокол установки соедиенения SIP, может порой давать самые причудливые результаты (спорадические отказы в регистрации на сервере, односторонняя слышимость между абонентами и т. п.), причем это зависит не только от настроек IP-телефона, но и от настроек сервера. Другой пример: компания Microsoft сообщает в своей статье KB817778, что их реализация туннеля IPv6 over UDP не будет работать через Symmetric NAT (адрес статьи в Интернете: http://support.microsoft.com/kb/817778/EN-US). Таких примеров можно найти ещё много, и во всех случаях понимание различий в реализациях NAT если и не поможет немедленно устранить проблему, то хотя бы укажет на возможные пути решения (например, заменить firmware маршрутизатора на такое, где NAT реализован в виде Full Cone, если, конечно, оно существует, или заменить сам маршрутизатор).

Ссылки по теме

• Купить продукты «Лаборатории Касперского» в интернет-магазине itshop.ru
• Купить продукты «Доктор Веб» в интернет-магазине itshop.ru
• Купить продукты ESET Software в интернет-магазине itshop.ru
• Подписаться на рассылку «Безопасность компьютерных сетей и защита информации»

Так ли страшен Symmetric NAT

Задача прямого соединения машин, находящихся за NAT’ом стара как мир и я думаю, что многие слышали про UDP Hole Punching. Когда я только начинал интересоваться вопросом, я утвердился во мнении, что symmetric nat пробить невозможно и пытаться даже не стоит. Однако совсем недавно мне попалась статья в которой утверждалось, что симметричный нат — это не приговор.

Типы NAT

• Full-cone NAT;
• Address-restricted cone NAT;
• Port-restricted cone NAT;
• Symmetric NAT

1) фильтр входящих пакетов;
2) правило маппинга портов.

Первая характеристика как раз описана в большинстве статей и означает, какие входящие пакеты передавать машине за NAT’ом: все (no filter – Full cone), с конкретного адреса (address-restricted) или с конкретного адреса и порта (port-restricted).

Вторая характеристика же присуще только симметричному НАТ’у, так как первые три типа пытаются сделать отражение один в один. Например, если клиент посылает пакет с внутреннего адреса 192.168.10.24:62145, то от роутера пакет пойдет с адреса 1.2.3.4:62145. Причем вне зависимости от адреса получателя.

Symmetric NAT

А теперь детальнее про симметричный NAT. Сразу оговорюсь, что фильтры входящих пакетов тоже могут быть любые (no filter, address-restricted или port-restricted). И единственное отличие этого типа NAT’a от предыдущих как раз в выборе исходящего порта на роутере, он почти наверняка будет отличаться от исходного порта на клиенте. Вернувшись к предыдущему примеру отражение может быть таким: 192.168.10.24:62145 -> 1.2.3.4:1274.

Выбирается тот самый порт случайно (ну или не случайно, а по очереди, но это не важно, так как повлиять на его выбор извне мы не можем). Но есть определенные правила, они похожи на фильтр входящих пакетов:

• Порт может оставаться всегда одним и тем же, в не зависимости от получателя (cone);
• Порт может оставаться одним и тем же для конкретного адреса получателя (address);
• Порт может оставаться одним и тем же лишь для конкретного адреса и порта получателя (port);

При этом есть еще и правила для выбора следующего порта:
Это может быть какая-то дельта (+1/-1 или +10/-10) или вообще каждый раз случайно.
Кроме того видел один NAT у которого каждый последующий порт отстоял от предыдущего на случайное число, но всегда кратное 4096.

Вместо заключения

Итак, понятного, что зная правило распределения портов и дельту можно угадать, с какого порта пойдет исходящий пакет, соответственно пробить тот самый симметричный NAT. Разумеется, в случае выбора порта совсем случайно, этот фокус не пройдет.

Ну что же мы подобрались к сути и цели статьи. Ответу на вопрос

«Можно ли определить правило распределения портов и дельту, находясь за NAT’ом?»

Поможет нам в этом STUN, конечно. Наша задача сделать четыре запроса к разным адресам и портами используя один сокет (один локальный порт) и оценить результаты:
Мы сможем понять каким образом распределяются исходящие порты (адрес или порт) и попробовать рассчитать ту самую дельту.

И тут я призываю хабрасообщество мне помочь со статистикой. На просторах Интернета был найден простенький stun клиент, немножко допилен кувалдой и вот что получилось:

Пользователи Линукса прекрасно знают как это скомпилировать.

Вот так
gcc -lpthread -o stun stun.c

Под винду отлично компилится студией, вот тут бинарник, если студии под рукой нет.

Да простит меня stun.counterpath.net за хабра эффект 🙂

Вот мои результаты, но у меня не симметричный НАТ и не интересно:

Results
tests: 1010
NAT present: 1
first preserved port: 1
preserves port: 0
type: Port restricted NAT
mapped ports: 55907 55907 55907 55907

Всем спасибо за помощь!

udp: Оставляйте, пожалуйста, ваши результаты в комментариях, даже если НАТ не симметричный. Ведь в любом случаю важно знать распиновку по типам.

• NAT Traversal
• Symmetric NAT