• Главная
• Новости
• Статьи
• Карта сайта
• Поиск
• Контакт
• Рекомендации

Малоизвестные подробности работы 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).
  

Простейший случай NAT - это трансляция адресов Inside Local в Inside Global и наоборот. При этом маршрутизатор, выполняющий NAT, модифицирует поле адреса в заголовке IP следующим образом:

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

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

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

Более распространённый случай - это NPAT, network and port address translation. При использовании NPAT в таблице сопоставлений каждая запись имеет не два (как в простом NAT), а пять значений:

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

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

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

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

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

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

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

Допустим, после появления такой записи в таблице, другой хост, 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-адресов - дальше станет понятно, для чего.

Процесс определения типа NAT с использованием STUN протекает следующим образом. Допустим, наш клиент находится за NAT, его локальный адрес 192.168.0.111, публичный адрес NAT - 1.2.3.4, адреса сервера STUN - 11.22.33.1 и 11.22.33.2, номера портов 3478. Происходит следующее:

• Клиент отправляет запрос на основной адрес сервера (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:

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

Источник: www.cyberguru.ru

Новостной блок