Трансляторы сетевых адресов
Итак, теперь мы знаем, что у каждого устройства, поддерживающего протокол IP, Должен быть IP-адрес. С распространением небольших и домашних офисов это бы означало, что каждый раз, когда в таком офисе возникает необходимость установить локальную сеть или соединить друг с другом несколько машин, поставщику услуг Интернета пришлось бы выделять блок адресов для всех машин маленького офиса. В случае роста сети (например, у детей в доме помимо настольных персональных компьютеров появились карманные компьютеры, телефоны с поддержкой протокола IP или сетевые игровые приставки) такому офису нужно было бы выделить блок адресов большего размера. А что, если Интернет-провайдер уже распределил все соседние участки адресного пространства? И что нужно знать об управлении IP-адресами типичному домовладельцу? К счастью, существует более простой метод выделения адресов, нашедший широкое применение в подобных ситуациях. Этим методом является (RFC 2663, RFC 3022) так называемая трансляция сетевых адресов (Network Address Translation, NAT).
Рисунок 4.27 иллюстрирует работу маршрутизатора, поддерживающего трансляцию сетевых адресов (NAT-маршрутизатора). У этого маршрутизатора есть интерфейс, представляющий собой часть домашней сети (на правой стороне рисунка). Адресация в пределах домашней сети полностью аналогична тому, что мы уже видели — у всех четырех интерфейсов домашней сети один и тот же сетевой адрес 10.0.0/24. От обсуждавшейся выше ситуации данный пример отличается взаимоотношением между домашним маршрутизатором и Интернет-провайдером. На NAT-маршрутизаторе не работает протокол внутренней маршрутизации для связи с маршрутизатором Интернет-провайдера. В самом деле, для внешнего мира NAT-маршрутизатор выглядит как единое устройство с одним IP-адресом — весь трафик, исходящий из домашнего маршрутизатора в Интернет, помечается IP-адресом отправителя 138.76.29.7, а весь прибывающий из Интернета трафик должен иметь IP-адрес получателя 138.76.29.7. Таким образом, NAT-маршрутизатор скрывает от внешнего мира детали домашней сети. (Обычно маршрутизатор получает свой адрес у DHCP-сервера Интернет-провайдера и сам выступает в роли DHCP-сервера для компьютеров своей домашней сети.)
Теперь вам, вероятно, непонятно, как маршрутизатор определяет, кому предназначается прибывшая из Интернета дейтаграмма, если все дейтаграммы маркируются одним и тем же IP-адресом получателя. Дело в том, что маршрутизатор различает прибывающие дейтаграммы по номерам портов, которые с помощью таблицы трансляции адресов (NAT-таблицы) преобразуются во внутренние адреса и номера портов.
Вернемся к примеру на рисунке. Предположим, пользователь, сидящий за хостом 10.0.0.1, запрашивает web-страницу с некоторого web-сервера (порт 80) с IP-адресом 128.119.40.186. Хост выбирает себе произвольный номер порта отправителя 3345 и отправляет дейтаграмму в локальную сеть. NAT-маршрутизатор получает дейтаграмму, генерирует новый номер порта 5001, которым заменяет оригинальный номер порта, а IP-адрес отправителя заменяет своим IP-адресом 138.76.29.7.
Генерируя новый номер порта, NAT-маршрутизатор может выбирать любое число, которого нет в NAT-таблице. (Обратите внимание, что поле номера порта состоит из 16 бит, поэтому протокол NAT может поддерживать более 60 000 одновременных соединений с единственным IP-адресом маршрутизатора!) Web-сервер, не имея представления о том, что полученная им дейтаграмма с HTTP-запросом была обработана NAT-маршрутизатором, отвечает дейтаграммой, в поле адреса получателя которой указан IP-адрес NAT-маршрутизатора, а в поле номера порта— порт 5001. Получив эту дейтаграмму, NAT-маршрутизатор по указанным в дейтаграмме IP-адресу получателя и номеру порта находит в NAT-таблице соответствующий IP-адрес (10.0.0.1) и номер порта (3345) браузера домашней сети. Затем маршрутизатор заменяет оба этих поля найденными в таблице и переправляет дейтаграмму в домашнюю сеть.
В последние годы трансляция сетевых адресов получила широкое распространение. Но мы должны сказать, что многие члены IETF громко возражают против этого метода. Во-первых, заявляют они, номера портов предназначались для адресации процессов, а не хостов. Это нарушение в самом деле может стать причиной проблем для серверов, обслуживающих домашние сети, так как (см. главу 2) сервер ждет входящие обращения к так называемым хорошо известным номерам портов.
Во-вторых, говорят они, маршрутизаторы должны обрабатывать пакеты только до уровня 3. В-третьих, протокол NAT противоречит так называемому «сквозному аргументу», заключающемся в том, что хосты должны взаимодействовать друг с другом напрямую, без вмешательства узлов, изменяющих IP-адреса и номера портов. И в-четвертых, для решения проблемы нехватки IP-адресов мы должны использовать протокол IPv6 (см. раздел «Протокол IPv6»), а не применять всяческие временные «жучки» и «затычки» вроде трансляции сетевых адресов. Тем не менее, нравится вам это или нет, трансляция сетевых адресов уже стала важной составляющей Интернета.
Наше обсуждение трансляции сетевых адресов было вынужденно кратким. У этого метода есть еще множество других важных аспектов, таких как статическая и динамическая NAT-трансляция, а также влияние NAT на протоколы более высокого уровня и на безопасность.