По умолчанию
NAT транслирует IP-адреса и TCP/UDP-порты. Если IP-адрес и информация о порте
содержатся только в заголовках IP и TCP/UDP, то прикладной протокол также будет
правильно транслироваться nat!
Пример — протокол
HTTP (Hypertext Transfer Protocol, протокол передачи гипертекста), используемый
в WWW (World Wide Web).
Однако имеются приложения
и протоколы, которые содержат IP-адрес или информацию о порте TCP/UDP в теле
сообщений, а не в заголовках TCP/UDP. Пример — протокол FTP, который для
команды ftp port передает десятичное представление IP-адреса в теле команды. Если
NAT неправильно транслирует IP-адрес внутри команды FTP, то могут возникнуть проблемы
установления соединения.
Также имеются протоколы,
которые не используют для передачи данных ни TCP, ни UDP (большинство
протоколов использует для доставки пакетов транспортные протоколы TCP или UDP).
Например, транспортный протокол РРТР не использует для доставки данных TCP/UDP.
Вместо заголовков TCP или UDP используется специальный заголовок общей инкапсуляции
маршрутизации (ORE, Generic Routing Encapsulation) и специальное поле Tunnel
ID для идентификации потока данных. Если бы NAT не транслировал это поле, то передача
данных при помощи протокола РРТР через NAT была бы невозможна.
Если компонент NAT должен дополнительно транслировать и корректировать
не только заголовки IP, TCP и UDP, но и служебную информацию в теле пакетов, требуется
редактор NAT. Редактор NAT — устанавливаемый компонент, который может
корректно изменять не транслируемую иным способом информацию — так, чтобы она
могла быть передана через NAT. В составе Windows 2000 имеются NAT-редакторы для
протоколов FTP, ICMP, РРТР. Возможно появление NAT-редакторов для трансляции протоколов
SNMP, LDAP, Microsoft COM, RPC.
Примечание
Трансляция трафика, передаваемого
по протоколам IPSec и Н.323, невозможна даже при использовании специального редактора
NAT.
Серверы DHCP, DNS и WINS Windows Server 2003
Схемы запросов
Рассмотрим процесс разрешения доменных имен в IP-адреса, определенный в рамках
спецификации службы DNS (RFC 1034 и RFC 1035). Процесс разрешения доменного
имени предполагает строго регламентированное взаимодействие DNS-клиента и цепочки
DNS-серверов. Взаимодействие начинается с момента, когда пользователь или приложение
используют доменное имя для ссылки на некоторый хост. Соединение с любым хостом
осуществляется только на уровне IP-адресов. Поэтому DNS-клиент должен выполнить
разрешение доменного имени.
Всю работу по разрешению доменного имени выполняет DNS-сервер. В зависимости
от обстоятельств, в процесс разрешения имени может быть вовлечен один сервер
или несколько DNS-серверов.
Изначально для разрешения доменных имен использовался специальный
текстовый файл, в котором перечислялись IP-адреса и соответствующие им имена
компьютеров. Этот файл, получивший название HOSTS (хосты), помещается на сервере.
Каждый клиент копировал этот файл и использовал его для разрешения имен. При
необходимости разрешения имени клиент просматривает файл HOSTS с целью обнаружения
интересующего имени. Подобная схема разрешения имен подходит для небольших статичных
сетей. В большой динамичной сети поддержание файла HOSTS в актуальном состоянии
на всех клиентах представляет собой трудно решаемую проблему. Служба DNS явилась
альтернативой механизму разрешения имен посредством файла HOSTS.
