4. Протоколы, способные функционировать совместно с NAT-модулем при помощи ALG-субмодуля
Основное внимание в данном разделе будет уделено проболемам, связанным с использованием классического NAT-модуля и, в частности, NAPT-модуля.
4.1. Протокол FTP
Протокол FTP (File Transfer Protocol) основан на использовании ТСР-протокола и применяется для доставки файлов между двумя IP-узлами. Для реализации своей основной функции FTP-протокол использует групповой сеанс связи, состоящий из двух субсеансов связи (управляющий и информационный сеансы связи). Инициализация FTP-протокола осуществляется пользователем (клиентом FTP-сервера), который посылает сообщение-запрос на «хорошо известный» ТСР-порт с номером «21» — эта процедура называется «управляющим сеансом связи». Далее, управляющий сеанс связи сопровождается информационным сеансом связи. По умолчанию, для информационного сеанса связи используются «20» ТСР-порт на FTP-сервере и ТСР-порт клиента, который использовался для инициализации управляющего сеанса связи. Однако, номера TCP-портов информационного сеанса связи могут быть изменены с помощью управляющего сенса связи, который использует ASCII-код для кодирования командных сообщений «PORT» и «PASV» и ответов на них.
Предположим, что FTP-клиент находится внутри корпоративной сети, обслуживаемой NAT-модулем. В таком случае потребуется применение FTP-ALG-субмодуля, который будет контролировать управляющий FTP-сеанс связи (в обоих режимах функционирования: «PORT» и «PASV») с целью определения номеров ТСР-портов в интересах информационного сеанса связи и последующего пробразования корпоративных IP-адреса и номера ТСР-порта во внешние разрешенные IP-адрес и номер ТСР-порта. Кроме этого, модификации подлежат последовательные номера ТСР-блоков (в запросах и в ответах), поле проверочной суммы ТСР-заголовка, размер IP-пакета и поле проверочной суммы в IP-заголовке. Соответственно, во всех последующих IP-пакетах (включая ответные сообщения) должны быть скорректированы последовательные номера и поля проверочных сумм.
В отдельных случаях, увеличение размера IP-пакета может привести к тому, что будет превышен максимально допустимый размер IP-пакета, установленный для конкретного соединения. В такой ситуации, IP-пакет подлежит процедуре фрагментации, которая может замедлять скорость доставки файлов. В противном случае, если бит «DF» в IP-заголовке имеет значение «1» (Don't Fragment — отсутствие фрагментации), то тогда ICMP-протокол будет удалять такие IP-пакеты (превышающие максимально допустимый размер), а IP-узел (источник таких длинных IP-пакетов) должен будет скорректировать свое значение максимально допустимого размера IP-пакета. А это, в свою очередь, также может отрицательно сказаться на скорости доставки файлов.
Замечание. Если виртуальное соединение, обслуживающее управляющий сенса связи, защищено с помощью процедуры шифрования данных, то тогда FTP-ALG-субмодуль не сможет модифицировать IP-адреса, передаваемые во время управляющего сеанса связи.
Если FTP-протокол защищен с помощью процедуры аутентификации на основе протоколов «Kerberos 4» и «Kerberos 5» или TLS-протокола, то тогда при функционировании FTP-протокола могут возникнуть аналогичные проблемы, которые имели место при рассмотрении функционирования рабочей станции «X-term» по протоколу удаленного доступа «TELNET».
И последнее, особый интерес представляет стандарт RFC 2428 («FTP extensions for IPv6 and NATs» — Дополнительный функции FTP-протокола в интересах IPv6-адресации и NAT-модулей). Указанный стандарт вводит новую FTP-команду[?] («EPSV ALL») для указания TCP-порта, которая может быть использована в интересах NAT-модулей, то есть позволит им быстро устаналивать FTP-соединение, исключая в дальнейшем обработку данных с помощью FTP-ALG-субмодуля, если конечно удаленный FTP-сервер способен выполнить команду «EPSV ALL».