«Random port» означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника. Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.

Как видно из примера, наш маршрутизатор старается сохранять номер порта неизменным (11.22.33.44:1053 и 192.168.0.141:1053), из чего следует, что запущенный в его локальной сети STUN-клиент сообщил бы о нем «preserves ports». К слову, на FreeBSD этот результат достигается ключом «-same_ports» или «-s» в строчке запуска или конфигурационном файле демона natd.

«Hairpin» же означает следующее. Допустим, при наличии в таблице NAT приведенной выше строчки другой хост нашей локальной сети (например, 192.168.0.241) отправляет UDP-пакет с адресом назначения 11.22.33.44, портом назначения 1053 и портом источника 53. Что произойдет в результате?

Ответ на этот вопрос зависит от того, поддерживает маршрутизатор функцию «hairpin» или не поддерживает. Если он ее поддерживает, пакет будет обычным образом обработан и (если на маршрутизаторе используется реализация NAT Full Cone или Port Restricted) попадет по назначению – на хост 192.168.0.141. Если же нет («no hairpin»), пакет будет уничтожен маршрутизатором. Название функции «hairpin» (шпилька для волос) произошло от того, что, если изобразить прохождение такого пакета на рисунке, форма его траектории будет похожа на U-образную шпильку. Другое объяснение – слово «hairpin» переводится так же, как «разворот на 180 градусов». При поддержке маршрутизатором функции «hairpin» подпадающие под ее действие пакеты, действительно, будут развернуты на 180 градусов и отправлены обратно в локальную сеть.

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

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

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

Рисунок 4. Пример FTP-сессии

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

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

Server: 200 PORT command successful. Consider using PASV.