Малоизвестные подробности работы NAT - NAT и шлюзы приложений

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

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

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


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

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


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