RFC: 3027
Оригинал: Protocol Complications with the IP Network Address Translator
Категория: Информационный
Дата публикации:
Авторы: ,
Перевод: Мельников Дмитрий Анатольевич

RFC 3027, Страница 2 из 19

2.2. Прикладные службы, использующие взаимозависимые сеансы связи

Прикладные процессы (службы), реализующие такие протоколы как FTP, H.323, SIP и RTSP, используют два (или более) взаимозависимых сеанса связи, один из которых управляющий и предназначен для формирования другого информационного сеанса связи. Такие прикладные службы также не могут функционировать, если на пути следования IP-пакетов, содержащих их сообщения, используются NAT-модули. Это объясняется следующим образом. Такие прикладные процессы изменяют значения IP-адреса и порта транспортного уровня в период управляющего сеанса связи с целью построения информационных сеансов связи и корректировки параметров сеансов связи. NAT-модуль «не может распознать» являются ли сеансы связи взаимозависимыми и поэтому он рассматривает каждый сеанс связи, как несвязанный с каким-либо другим сеансом связи. Прикладные процессы в таких ситуациях могут прерваться по различным причинам, но две наиболее вероятные причины следующие:

  1. адресная информация, содержащаяся в поле полезной нагрузки IP-пакета в период проведения управляющего сеанса связи формируется на основе RSIP-адресации и является недоступной, так как IP-пакет «пересекает» адресную зоны, являющуюся источником этого пакета;

  2. управляющий сеанс связи разрешает проведение информационного(ых) сеанса(ов) связи от источника до получателя, который(е) NAT-модуль может запретить.

Когда в поле полезной нагрузки IP-пакета в период проведения управляющего сеанса связи содержаться DNS-имена, то тогда NAT-модуль, функционирующий совместно с DNS-ALG-субмодулем, способен обеспечить необходимую прозрачность виртуального соединения в интересах прикладного уровня, если, конечно, NAT-модуль не вступает в противоречие с направлением информационного сеанса связи. Однако, использование DNS-имен вместо RSIP-адресов может быть неприемлемо для многих прикладных служб (например, FTP-протокол). Если в поле полезной нагрузки имеет место RSIP-адресация, а само поле не зашифровывается, то тогда ALG-субмодуль, в некоторых случаях, может обеспечить необходимую прозрачность виртуального соединения, проходящего через несколько адресных зон, в интересах соответствующих прикладных служб. Сложность самого программного ALG-субмодуля будет зависеть от степени информативности прикладного уровня, которая необходима для обработки поля полезной нагрузки и обслуживания сеанса связи.

2.3. Прикладные службы с равноправным соединением IP-узлов

Прикладные службы с равноправным соединением IP-узлов (peer-to-peer application), которые отличаются от прикладных служб со структурой «клиент-сервер» (client-server based application), также не могут функционировать, если на пути следования IP-пакетов, содержащих их сообщения, используются NAT-модули. В отличие от прикладных служб со структурой «клиент-сервер», прикладные службы с равноправным соединением IP-узлов допускают инициирование сеанса связи любым из взаимодействующих IP-узлов. Когда взаимодействующие IP-узлы размещены в различных адресных зонах (корпоративной и общего пользования), то тогда сеанс связи, инициированный из внешней сети, имеет такую же вероятность, как и сеанс связи, инициированный IP-узлом корпоративной сети. Внешние IP-узлы могут соединиться с корпоративными IP-узлами только тогда, когда они заранее знают дополнительно выделенный внешний IP-адрес этих корпоративных IP-узлов или полное DNS-имя (Fully Qualified Domain Name — FQDN). Полное DNS-имя, отображаемое в соответствующий IP-адрес, может иметь только такую длину, которая определена в DNS-ALG-субмодуле в составе NAT-модуля, расположенного на пути следования IP-пакетов с DNS-сообщениями. Примерами прикладных служб с равноправным соединением IP-узлов являются интерактивные игры, Internet-телефония и так называемые событийные или протоколы спорадического информационного обмена (Event-Based Protocols), к которым относятся протоколы мгновенного обмена сообщениями (Instant-Messaging).

Примечание. Event-Based Protocols — Событийные/поточные протоколы: В основе событийных протоколов (или протоколов спорадического информационного обмена) лежит внутреннее содержание конкретных сообщений, которыми обмениваются между собой отправитель и получатель. В целом, конкрентое сообщение (событие) никак не связано и не зависит от информации, содержащейся в других сообщениях (предшествующих и последующих). Действительно, все последующие сообщения могут быть направлены и другим получателям. Напротив, поточные протоколы обеспечивают непрерывный информационный обмен: сообщения формирующие поток трафика жестко зависят от предшествующих сообщений и сильно влияют на последующие сообщения. Все последующие сообщения, передаваемые в общем потоке трафика направляются одному и тому же получателю. Выбор того или иного протокола полностью зависит от природы (вида) связи: непрерывные формы обмена сообщениями используют поточные протоколы, а стохастические (спорадические) формы обмена сообщениями используют событийные протоколы.

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

Страница 2 из 19

2007 - 2022 © Русские переводы RFC, IETF, ISOC.