NAT позволяет скрыть адреса внутренней сети.

Bо многих случаях для продвижения пакетов во внутренней сети используются одни адреса сетевого уровня, а во внешней — другие. С подобной ситуацией приходится сталкиваться, в частности, при туннелировании, когда пакет передается через транзитную сеть, причем применяемая в ней технология отличается от технологии сетей отправителя и получателя. Например, во внутренних сетях транспортной технологией является IPX, а в соединяющей их внешней транзитной — IP. При передаче во внешнюю сеть «внутренний» пакет снабжается дополнительным заголовком, где в качестве адресов отправителя и получателя указываются адреса пограничных устройств. Туннели могут создаваться и для защиты передаваемой информации, когда пакет шифруется вместе со своим заголовком, включая адресную информацию. Таким способом организуются защищенные каналы в одной из самых популярных технологий безопасности IPSec.

«Маскарад» сетевых адресов применяется также в широко распространенной технологии трансляции сетевых адресов, Network Address Translation (NAT). Так же, как и при туннелировании, во внешней сети пакеты перемещаются на основании адресов, отличных от тех, которые используются в сети внутренней. Механизм NAT применяется к пакету во время прохождения им пограничного устройства, соединяющего внутреннюю сеть с внешней. Однако, в отличие от туннелирования, внутренние адреса не дополняются, а заменяются внешними, т. е. происходит прозрачное для пользователя отображение внутреннего адресного пространства на внешнее.

ЗАЧЕМ НУЖЕН NAT

Одной из причин популярности технологии NAT можно назвать дефицит IP-адресов. Если сеть предприятия автономна, то в ней могут быть использованы любые IP-адреса, лишь бы они были синтаксически правильными. Совпадение адресов в не связанных между собой сетях не вызовет никаких отрицательных последствий. Однако для всех сетей, подключенных к Internet, необходимы глобальные IP-адреса, т. е. позволяющие однозначно определить сетевые интерфейсы в пределах всей составной сети. Их уникальность гарантируется централизованной, иерархически организованной системой их распределения. Главным органом регистрации глобальных адресов в 1998 г. стал Internet Corporation for Assigned Names and Numbers (ICANN) — неправительственная некоммерческая организация, управляемая Советом директоров. Она координирует работу региональных отделов, чья деятельность охватывает большие географические зоны: ARIN — Америка, RIPE — Европа, APNIC — Азия и Тихоокеанский регион. Региональные отделы выделяют блоки глобальных адресов крупным провайдерам, те в свою очередь присваивают их клиентам, среди которых могут быть и более мелкие провайдеры.

Если по каким-либо причинам предприятию не удается получить у провайдера нужное количество глобальных IP-адресов, оно может прибегнуть к технологии NAT. В этом случае для адресации внутренних узлов применяются специально зарезервированные для подобных целей так называемые частные (private) адреса:

10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255

Приведенные выше диапазоны адресов составляют огромное адресное пространство, достаточное для нумерации узлов сетей практически любых размеров. Эти адреса исключены из множества централизованно распределяемых, а значит, пакеты с такими адресами назначения будут проигнорированы маршрутизаторами на магистралях Internet. Для того чтобы узлы с частными адресами могли связываться друг с другом через Internet или с любыми другими узлами, необходимо использовать технологию NAT.

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

Технология трансляции сетевых адресов имеет несколько разновидностей, наиболее популярная из которых — традиционный NAT (Traditional NAT) — позволяет узлам из частной сети прозрачным для пользователей образом получать доступ к узлам во внешних сетях. Подчеркнем, что сеансы традиционного NAT однонаправленные и инициируются изнутри частной сети. (Направление сеанса определяется положением инициатора: если обмен данными инициируется приложением, работающим на узле внутренней сети, такой сеанс называется исходящим, несмотря на то что в рамках указанного сеанса в сеть могут поступать данные извне.) В виде исключения традиционный NAT допускает сеансы обратного направления, посредством статического отображения адресов для некоторого ограниченного, заранее заданного набора узлов, для которых устанавливается взаимно однозначное соответствие между внутренними и внешними адресами.

Традиционный NAT подразделяется на Basic Network Address Translation (Basic NAT) — метод, использующий для отображения только IP-адреса, и Network Address Port Translation (NAPT) — когда для отображения привлекаются еще и так называемые транспортные идентификаторы, в качестве которых чаще всего выступают порты TCP/UDP.

БАЗОВЫЙ NAT

Этот вариант NAT работает следующим образом (см. Рисунок 1). Сеть предприятия образует тупиковый домен, узлы которого описываются набором частных адресов. Программное обеспечение NAT, установленное на пограничном устройстве, связывающем сеть предприятия с внешней сетью, динамически отображает набор частных адресов {IP*} на набор глобальных адресов {IP}, полученных предприятием от провайдера и привязанных к внешнему интерфейсу.

Рисунок 1. Общая схема NAT.

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

В каждый момент времени взаимодействовать с внешней сетью может столько внутренних узлов, сколько адресов имеется в глобальном наборе. Внутренние адреса некоторых узлов можно статически отображать на определенные глобальные адреса; в этом случае к ним организуется доступ извне с помощью фиксированного адреса. Соответствие внутренних адресов внешним задается таблицей, поддерживаемой устройством NAT.

В нескольких тупиковых доменах могут встречаться совпадающие частные адреса. Например, сети А и В (см. Рисунок 2) осуществляют внутреннюю адресацию с помощью одного и того же блока адресов 10.0.0.0/8. Причем внешние адреса обеих сетей (181.230.25.1/24, 181.230.25.2/24 и 181.230.25.3/24 в сети A и 185.127.125.2/24, 185.127.125.3/24 и 185.127.125.4/24 в сети B) уникальны глобально, так что никакие другие узлы в составной сети или устройства NAT их не используют.

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

Когда узел 10.0.1.4 сети А хочет послать пакет хосту 10.0.12.2 сети В, то для этого он указывает глобальный адрес 185.127.125.4/24 в качестве адреса назначения. Узел-отправитель направляет пакет своему маршрутизатору по умолчанию; тот знает маршрут к сети 185.127.125.0/24, так что пакет переправляется им на внешний интерфейс. Однако перед отправкой пакета устройство NAT, применяя таблицу отображения внутренних адресов во внешние, транслирует частный адрес отправителя 10.0.1.4 в соответствующий ему глобальный адрес 181.230.25.1/24. После путешествия по составной сети пакет поступает на внешний интерфейс устройства NAT сети B, а глобальный адрес назначения 185.127.125.4/24 преобразуется в частный адрес 10.0.12.2. Пакеты, передаваемые в обратном направлении, проходят аналогичную процедуру трансляции адресов.

Заметим, что в описанной операции участия узла отправителя и получателя не требуется, т. е. она прозрачна для пользователей.

NAPT

Допустим, что некоторая организация имеет частную сеть IP и соединение с провайдером Internet. Внешнему интерфейсу пограничного маршрутизатора назначен глобальный адрес, а остальным узлам сети — частные адреса. NAPT позволяет всем узлам внутренней сети одновременно взаимодействовать с внешними сетями с помощью одного-единственного зарегистрированного IP-адреса. Каким же образом внешние пакеты, поступающие в ответ на запросы из сети, находят узел-отправитель, ведь в поле адреса источника всех пакетов, отправляющихся во внешнюю сеть, помещается один и тот же адрес внешнего интерфейса? Для идентификации узла отправителя можно привлечь дополнительную информацию — номер порта UDP или TCP. Но и это не вносит полной ясности, поскольку из внутренней сети может исходить несколько запросов с совпадающими номерами портов отправителя, и опять возникает вопрос об однозначности отображения единственного глобального адреса на набор внутренних адресов. Решение состоит в том, что при прохождении пакета из внутренней во внешнюю сеть каждой паре {внутренний частный адрес; номер порта TCP/IP отправителя} ставится в соответствие другая пара {глобальный IP-адрес внешнего интерфейса; назначенный номер порта TCP/IP}. Назначенный номер порта выбирается произвольно, но он должен быть уникальным в пределах всех узлов, получающих выход во внешнюю сеть. Соответствие фиксируется в таблице.

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

На Рисунке 3 приведен пример, когда тупиковая сеть А использует внутренние адреса из блока 10.0.0.0/8. Внешнему интерфейсу маршрутизатора этой сети провайдером назначен адрес 181.230.25.1

Рисунок 3. Трансляция адресов и номеров портов для исходящих сессий TCP/UDP в случае NAPT.

Когда хост 10.0.1.4 сети А посылает пакет сервиса telnet хосту 136.56.28.8 во внешней сети, то он в качестве адреса назначения указывает глобальный адрес 136.56.28.8 и направляет пакет маршрутизатору. Маршрутизатор знает путь к сети 136.56.0.0/16, поэтому передает пакет на внешний интерфейс. Но при этом NAPT маршрутизатора транслирует адрес отправителя 10.0.1.4 и его порт TCP 1245 в глобально уникальный адрес 181.230.25.1 и уникально назначенный порт TCP, например 3451. Генерирующий ответное сообщение получатель в качестве адреса назначения указывает единственный зарегистрированный глобальный адрес сети А (адрес внешнего интерфейса устройства NAPT), а также назначенный номер порта TCP/UDP, который он берет из поля порта отправителя пришедшего пакета. При поступлении ответного пакета на устройство NAPT сети А именно по номеру порта в таблице трансляции выбирается нужная строка. Из нее определяется внутренний IP-адрес соответствующего узла и действительный номер порта. Эта процедура трансляции полностью прозрачна для конечных узлов.

В варианте NAPT разрешаются только исходящие из частной сети сеансы TCP/UDP. Однако нередки ситуации, когда нужно обеспечить доступ извне к некоторому узлу внутренней сети. В простейшем случае, если сервис зарегистрирован, т. е. ему присвоен «хорошо известный» номер порта (например, Web или DNS) и, кроме того, этот сервис представлен во внутренней сети в единственном экземпляре, задача решается достаточно просто. Сервис и узел, на котором он работает, однозначно определяются на основании «хорошо известного» зарегистрированного номера порта сервиса.

NAT И ICMP

Для некоторых протоколов стека TCP/IP работа NAT не является прозрачной. Это относится, например, к протоколу управляющих сообщений ICMP. Он обеспечивает обратную связь для передачи сообщений об ошибках от промежуточных маршрутизаторов сети источнику пакета, вызвавшему ошибку. Диагностическое сообщение, содержащееся в поле данных протокола, включает IP-адреса и порты отправителя и получателя. При использовании NAT в качестве таких адресов и портов будут выступать не оригинальные адреса, а отображенные. При поступлении пакета ICMP на пограничное устройство протоколу NAT недостаточно выполнить только стандартную процедуру отображения адресов, необходимо скорректировать и содержимое поля данных, заменив и в нем IP-адрес и номер порта.

Еще одной особенностью NAT при обработке сообщений ICMP является невозможность применения портов TCP/UDP для отображения адресов, поскольку эти сообщения переносятся по сети, упакованными непосредственно в пакеты IP без использования транспортных протоколов TCP или UDP. Роль номеров портов в этом случае выполняют идентификаторы запросов ICMP.

Ситуация, требующая нестандартной обработки внутреннего содержания поля данных пакета, возникает не только в случае протокола ICMP, но и ftp, DNS и ряда других. Специфический алгоритм, добавляемый к стандартному NAT, в таком случае носит название прикладного шлюза (Application Level Gateway, ALG): например, FTP ALG, DNS ALG и т. п.

ДВОЙНОЙ NAT

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

Двойной NAT работает следующим образом. Когда хост А хочет инициировать сеанс с хостом Х, он генерирует запрос DNS для хоста Х. Шлюз DNS ALG перехватывает этот запрос и в ответе, который он возвращает хосту А, заменяет адрес для хоста Х адресом, способным правильно маршрутизироваться в локальном домене (например, Host-XPRIME). Хост А затем инициирует взаимодействие с хостом Host-XPRIME. После того как пакеты подвергнутся преобразованию NAT, адрес источника транслируется как и в традиционном NAT, а адрес назначения преобразуется в Host-X. На обратном пути выполняется аналогичное преобразование.

ОГРАНИЧЕНИЯ NAT

На использование метода трансляции адресов налагаются определенные ограничения. Так, все запросы и ответы, относящиеся к одному сеансу, должны проходить через один и тот же маршрутизатор NAT. Этого можно добиться, реализовав NAT на пограничном маршрутизаторе, который является единственным для тупикового домена. Впрочем, такое возможно и при наличии нескольких точек подключения внутренней сети к внешней. Но для того, чтобы сеансы не обрывались при переходе с отказавшего устройства NAT на другое, все маршрутизаторы должны разделять одну и ту же конфигурацию NAT и оперативно обмениваться информацией о состоянии сеансов.

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

Особого внимания требует совместное применение NAT и технологии защищенного канала IPSec. В частности, для обеспечения целостности передаваемых данных в семействе IPSec предусматривается использование протоколов AH и ESP. И тот и другой перед отправлением пакета подсчитывают дайджест (хэш-функцию) содержимого пакета и помещают его в заголовок. Принимающая сторона, получив пакет, заново вычисляет дайджест, и, если локально вычисленное и полученное из сети значения дайджеста совпадают, делает вывод об отсутствии искажений в переданной информации. Разница состоит в том, что протокол AH вычисляет дайджест на основании всех неизменяемых полей исходного IP-пакета, включая адреса источника и назначения из заголовка пакета, а протокол ESP — только на основании поля данных. Поскольку за время прохождения пакетом устройства NAT адреса отправителя или получателя изменяются, при использовании протокола AH нужно пересчитывать дайджест, для чего требуется знание секретного ключа. В то же время протокол ESP позволяет обеспечивать целостность стандартным образом и при работе с NAT.

Наталья Олифер — обозреватель «Журнала сетевых решений/LAN». С ней можно связаться по адресу: olifer@lanmag.ru.