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

Оглавление

1. Введение

Если кратко, то NAT-модуль обеспечивает прозрачную маршрутизацию для оконечных IP-узлов, которым необходимо соединение с различными адресными зонами. NAT-модуль преобразует IP-адреса оконечных IP-узлов (внутри IP-заголовка IP-пакета) на пути следования IP-пакетов и контролирует поток такого модифицированного трафика, что обеспечивает прозрачный маршрут доставки для всех IP-пакетов, принадлежащих одному сеансу связи, до необходимого конечного IP-узла в соответствующей адресной зоне. Там, где это возможно, совместно с NAT-модулем может использоваться ALG-субмодуль (Application Level Gateway — програмный шлюз/интерфейс прикладного уровня), обеспечивающий прозрачность доставки на прикладном уровне. В отличие от NAT-модуля, главное функциональное предназначение ALG-субмодуля заключается в том, чтобы прикладной процесс (прикладная служба, в интересах которой функционирует ALG-субмодуль) мог запросить проверку и провести необходимую модификацию поля полезной нагрузки IP-пакета.

2. Протоколы, на которые NAT-модуль накладывает определенные ограничения

В стандартах RFC 2663 и RFC 3022 расскрывается «природа» специфических проблем и ограничений, связанных с использованием NAT-модулей.

2.1. NAT-модуль на основе RSIP-адресации

Широкий круг прикладных служб не способны самостоятельно функционировать, когда на пути следования IP-пакетов, содержащих их сообщения, встречается NAT-маршрутизатор, который основан RSIP-адресации. В таких случаях NAT-маршрутизатор должен использоваться совместно с ALG-субмодулем. Но если поле полезной нагрузки IP-пакетов защищено с помощью IPsec-протоколами (или с помощью средств защиты транспортного или прикладного уровня), то тогда прикладная служба функционировать не сможет.

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.4. Трансляция IP-пакетов, содержащих фрагменты TCP/UDP-блоков, через NAT-модуль

При передаче IP-пакетов (например, корпоративными IP-узлами), содержащих фрагменты TCP/UDP-блоков, использование NAPT-модуля может привести к преждевременному прерыванию сеанса связи. Причина этого в следующем. Только IP-пакет с первым фрагментом TCP/UDP-блока, будет содержать TCP/UDP-заголовок, который будет необходим для привязки каждого IP-пакета к конкретному сеансу связи. Последующие IP-пакеты будут содержать фрагменты TCP/UDP-блока без TCP/UDP-заголовка, но они будут содержать один и тот же идентификатор разбиения блока, который был указан в первом фрагменте. Предположим, два корпоративных IP-узла передают IP-пакетов, содержащие фрагменты TCP/UDP-блоков, одному и тому же IP-узлу-получателю. И может случиться так, что оба IP-узла используют одинаковый идентификатор разбиения блока. Когда IP-узел-получатель принимает два не связанных между собой фрагмента TCP/UDP-блоков, но имеющих одинаковый идентификатор разбиения блоков, и причем с одинаковым IP-адресом IP-узла-отправителя, то тогда просто невозможно определить к каким сеансам связи принадлежат принятые фрагменты блоков. Соответственно, оба сеанса связи будут скомпрометированы и досрочно завершены.

2.5. Прикладные службы, требующие постоянной (неизменяемой) «привязки» отображаемых адресов

NAT-модуль будет нарушать функционирование тех прикладных служб, которые требуют сохранения одной и той же «привязки» транслируемых адресов (корпоративного и внешнего) на протяжении всех последующих сеансов связи. Такие прикладные службы требуют, чтобы отображение корпоративного адреса во внешний и наоборот («привязка адресов») не изменялось между сеансами связи, так как один и тот же внешний адрес может понадобиться для повторного использования в течении последующих сеансов связи. И действительно, NAT-модуль не может знать этого требования и может переназначить внешний IP-адрес для других IP-узлов между сеансами связи. Чтобы блокировать процеуду NAT-модуля по удалению «привязки» транслируемых адресов, может понадобиться дополнительный программный модуль, который бы по требованию прикладного процесса информировал NAT-модуль о сохранении имеющегося взаимооднозначного соответствия адресов. В противном случае, такую функцию может выполнять ALG-субмодуль, то есть будет информировать NAT-модуль о сохранении «привязки» адресов.

2.6. Прикладные службы, требующие большего числа внешних адресов, чем их есть в действительности

Данная проблема возникает тогда, когда число корпоративных IP-узлов больше, чем число имеющихся внешних IP-адресов, в которые отображаются корпоративные IP-адреса. Возьмем, к примеру, прикладную службу удаленного доступа «rlogin», сеанс связи которой инициирован IP-узлом корпоративного сетевого сегмента, обслуживаемого NAPT-модулем. Пользователи службы «rlogin» используют «хорошо известный» номер ТСР-порта «512», зарегистрированный для «rlogin», в качестве идентификатора транспортного уровня. Не более, чем один IP-узел в корпоративной сети может инициировать сеанс связи этой службы. В данном случае требуется большое количество внешних адресов, чем их есть на самом деле. NAT-модули могут только резервировать адреса, но не могут формировать новые номера.

3. Протоколы, которые не могут функционировать с NAT-модулем

3.1. Протоколы IPsec-архитектуры и обмена ключевой информацией (IKE)

Функциональное предназначение NAT-модуля зключается в модификации IP-адресов конечных IP-узлов (в пределах IP-заголовка) на маршруте доставки IP-пакета. С другой стороны, стандарт АН-протокола[?] (IPsec-архитектура[?] ) разработан специально для выявления (обнаружения) любых изменений в заголовке IP-пакета. Поэтому когда на пути следования IP-пакета встречается NAT-модуль, который вносит изменения в IP-заголовок этого пакета, IP-узел получатель этого модифицированного IP-пакета будет удалять его, так как содержание заголовка было изменено. Поэтому в результате, IP-пакет, защищенный с помощью АН-протокола (IPsec-архитектура) и прошедший обработку в NAT-модуле, просто не дойдет до прикладного процесса, сообщение которого доставлял этот IP-пакет.

IP-пакеты, зашифрованные с помощью ESP-протокола[?] (IPsec-архитектура), могут быть изменены NAT-модулем, расположеным на пути их следования, только в нескольких случаях. Если IP-пакет содержит TCP/UDP-блок, то тогда NAT-модулю может понадобиться скорректировать проверочную сумму в TCP/UDP-заголовке, так как он преобразует IP-адрес в IP-заголовке. Однако, в связи с тем, что TCP/UDP-заголовок зашифрован с помощью ESP-протокола, NAT-модуль не сможет пересчитать проверочную сумму. И в результате, IP-пакет, содержащий TCP/UDP-блок, не дойдет до прикладного процесса, сообщение которого доставлял этот IP-пакет.

Протокол обмена ключевой информацией в Internet (Internet Key Exchange Protocol — IKE, RFC-2409) может передавать IP-адреса в качестве идентификаторов IP-узлов, используя для этого, либо «Базовый режим», либо «Жесткий режим», либо «Ускоренный режим». В целях корректного проведения IKE-процедуры согласования параметров IP-пакеты будут передаваться через NAT-модуль, а это может потребовать модификации полей полезной нагрузки IP-пакетов. Однако, поля полезной нагрузки IP-пакетов очень часто бывают защищены с помощью хэш-функции (ЭЦП) или просто зашифрованы. Даже в случае, когда в поле полезной нагрузки IP-пакета IKE-протокола IP-адреса не используются, а IKE-процедура согласования параметров не была прервана, все равно чрезвычайно трудно обеспечить отображение корпоративного адреса во внешний адрес (и наоборот) с помощью NAT-модуля после завершения IKE-процедуры согласования параметров и до того, как IPsec-протоколы начнут использовать прикладной криптоключ. И в заключении, в любом случае одновременное применение сквозной («end-to-end») IPsec-защиты и NAT-модулей не возможно.

3.2. Протокол «Kerberos 4»

Все билеты протокола «Kerberos 4» (К4-билеты) шифруются. Более того, не допускается совместное использование протокола «Kerberos 4» и ALG-субмодуля. Когда центр распределения ключей (ЦРК) получает запрос на получение К4-билета, то тогда ЦРК в ответное сообщение включает требуемый К4-билет, содержащий IP-адрес источника. Однако не все прикладные службы «Kerberos 4» обязательно проверяют IP-адреса источников. AFS-система (Andrew File System) является хорошим примером, когда прикладные службы «Kerberos 4» не проверяют IP-адреса источников. Прикладные службы, которые не выполняют такую проверку, «не очень требовательны» к NAT-модулям, которые встречаются на пути следования их сообщений. К4-билеты привязаны к IP-адресу, который принадлежит объекту, запрашивающему К4-билет, и прикладным службам, которые используют данный К4-билет.

К4-билет (в ответном сообщении) содержит одиночный IP-адрес, определяющий интерфейс, используемый Kerberos-клиентом для получения билета-разрешения для доступа в сеть на основе «билета, запрашивающего билет-разрешение», полученного ранее из ЦРК. Такая система работает безукоризненно только тогда, когда ЦРК-сообщения и сообщения всех других Kerberos-служб пересекают один и тот же NAT-шлюз в течении одного и того же периода времени. При этом у конечного пользователя не будет возникать каких-либо проблем. Однако, существует предостережение, заключающееся в том, что NAT-модуль использует один и тот же адрес для корпоративного IP-узла, когда осуществляет модификацию адреса в период виртуального соединеня между клиентом и ЦРК и когда осуществляет модификацию адреса в период виртуального соединеня между клиентом и прикладным сервером. Поиск решения данной проблемы продолжается, и в частности, можно воспользоваться дополнительным произвольным виртуальным соединением, доступным для удаленного сервера в течении всего «времени жизни» билета, и одновременно с этим, запретить NAT-модулю устанавливать для этого соединения какую-либо адресную «привязку», используемую при преобразовании адресов. С другой стороны, может понадобиться применение ALG-субмодуля, который будет гарантировать, что NAT-модуль не изменит «привязки» IP-адресов в течении «времени жизни» билета, а также в период времени, с момента выдачи билета корпоративному IP-узлу и до момента начала использования билета корпоративным IP-узлом. Но билет будет действителен только тогда, когда он поступил из любого корпоративного IP-узла в рамках корпоративного сетевого сегмента, обслуживаемого NAPT-модулем. При отсутствии NAPT-модуля нарушитель может провести атаку типа «маскарад», используя для этого IP-адреса виртуального соединения, которое контролировалось им для кражи билета, передаваемого одному из взаимодействующих IP-узлов. В случае использования NAPT-модуля, нарушителю необходимо только лишь «получить» (перехватить) билет из корпоративного сетевого сегмента, обслуживаемого NAPT-модулем. Конечно, все сказанное выше подразумевает, что корпоративный сегмент, обслуживаемый NAPT-модулем, не является доверенной сетью — что весьма не удивительно, так как большинство атак проводится как раз изнутри корпоративной сети организации.

3.3. Протокол «Kerberos 5»

Как и в случае применения протокола «Kerberos 4», все билеты протокола «Kerberos 5» (К5-билеты) шифруются. Более того, не допускается совместное использование протокола «Kerberos 5» и ALG-субмодуля. В случае использования протокола «Kerberos 5», клиент определяет перечень IP-адресов для которых билет является действительным, или он может запросить билет, действительный для всех IP-адресов. Путем запроса билета для всех IP-адресов или билета с одним IP-адресом, принадлежащим NAPT-модулю, можно получить билет-разрешение для работы с NAPT-модулем, несмотря на то, что такое соединение не является полностью прозрачным (в этом случае от клиентов требуется другой алгоритм проведения процедуры, то есть отличный от того, который мог быть в противоположном случае).

К5-билет, полученный в ответном сообщении (так как запрашивался с клиентского IP-узла), содержит IP-адреса сетевых объектов, которые имеют право использовать этот билет. Если службы «Kerberos 5», обеспечивающие процедуру аутентификации, расположены с внешней стороны NAT-модуля (то есть со стороны сети общего пользования), то тогда процедура аутентификации в соответствии с протоколом «Kerberos 5» невозможна, так как IP-адрес, используемый NAT-модулем (базовым или NAPT), не включен в перечень доступных адресов.

В принципе существуют два способа совместного использования NAT-модуля системы аутентификации «Kerberos 5», однако, оба они снижают уровень защищености К5-билетов:

  1. первый способ, когда клиенты в корпоративной сетевой зоне, обслуживаемой NAPT-модулем, определяют внешний IP-адрес (IP-адрес в сети общего пользования) NAPT-модуля в перечне IP-адресов, содержащихся в К5-билетах. Однако, это создает такую же проблему при обеспечении безопасности, как и в системе «Kerberos 4». И кроме этого, совсем не очевидно, что клиент в корпоративной сетевой зоне узнает внешний IP-адрес NAPT-модуля. Этот IP-адрес мог быть изменен прикладным процессом в конечном IP-узле;

  2. второй способ, когда из К5-билетов удаляются все IP-адреса. Но это сразу может привести к краже К5-билета, что является еще более худшим сценарием, так как билетами могут воспользоваться любые сетевые субъекты, а не только клиенты внутри корпоративной сети.

3.4. Программный интерфейс «X Window System» и удаленный доступ «TELNET» с рабочей станции «X-term»

Программный многооконный интерфейс «X Window System» (ПМИ-Х) основан на ТСР-протоколе. Однако, организация соединения «клиент-сервер» при использовании этого ПМИ-Х полностью отличается от большинства других прикладных программных продуктов. Х-сервер (или «Open-windows»-сервер) представляет собой терминал, включающий монитор, «мышь» и клавиатуру (то есть терминал, который управляет ПМИ-Х). Клиентами выступают прикладные программы, которые активизируют ПМИ. Некоторые компьютеры могут обеспечивать функционирование сразу нескольких Х-серверов. Первый активизированный Х-сервер имеет ТСР-порт с номером 6000. Первый активизированный «Open-windows»-сервер может иметь ТСР-порт с номером 6000 или с номером 2000. Рабочая станция «X-term» (РС) передает IP-адреса для соединений от клиента к серверу с целью установки многооконного режима («DISPLAY variable») функционирования. Многооконный режим используется для последующих соединений между Х-клиентами, размещенными в IP-узле, и Х-сервером, размещенным в РС. Команда для установки многооконного режима («DISPLAY variable») передается в период согласования соединения с помощью протокола удаленного доступа «TELNET» в следующем виде:

DISPLAY=<local-ip-addr>:<server>.<display>

где «<local-ip-addr>» — содержит локальный IP-адрес, связанный с ТСР-портом, номер которого указан в субполе «<server>»; «<server>» — в этом субполе содержится номер ТСР-порта, который необходимо использовать для установления соединения; «<display>» — используется для нумерации окна на дисплее, которое использует Х-сервер.

В субполе «<local-ip-addr>» не указывается DNS-имя по следующим причинам:

  • Локальный (корпоративный) компьтер не имеет возможности определить свое DNS-имя без наличия специальной функции обратного отображения DNS-имен в локальный IP-адрес («<local-ip-addr>»).

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

  • И последнее, если не используется DNSSEC-система обеспечения безопасности, то тогда нельзя говорить о безопасном использовании DNS-адресов, так как они могут быть просто украдены и использованы для атак типа «маскарад». NAT-модуль и DNS-ALG-субмодуль не могут функционировать при использовании DNSSEC-протоколов обеспечения безопасности.

Организация соединения «клиент-сервер» при использовании ПМИ-Х заключается в следующем. Пользователи обращаются в корпоративные офисы (сети) со своих домашних РС «X-term». Предположим, Х-клиент функционирует в IP-узле, расположенном в сети общего пользования, то есть с внешней стороны NAT-модуля, а Х-сервер функционирует в IP-узле, расположенном в корпоративной сети, то есть с внутренней стороны NAT-модуля. Команда для установки многооконного режима («DISPLAY variable») передается в канал связи на IP-узел, в котором Х-клиент функционирует в нектором режиме. Процесс, который передает команду «DISPLAY variable» не знает IP-адреса NAT-модуля.

Если канал передачи команди «DISPLAY variable» не защищен с помощью шифрования данных, то тогда NAT-модуль может «обратиться за помощью» к ALG-субмодулю, чтобы последний установил необходимый номер ТСР-порта (в разрешенном диапазоне, «6000» или больше), и в дальнейшем NAT-модуль может выступать в роли шлюза. В противном случае, NAT-модуль может быть настроен для контроля (мониторинга) всех входящих соединений для обеспечения доступа к Х-серверу(ам), без обращения к ALG-субмодулю. Но, такой вариант использования NAT-модуля снижает уровень сетевой безопасности вследствие появления доступа к Х-серверу, хотя в противном случае, такой доступ был бы не возможен. Вследствие того, что ALG-субмодуль «вмешивается» в процесс трансляции IP-адресов, то невозможно провести надежные процедуры авторизации (аутентификации) Х-серверов и Х-клиентов, за исключением способа «MIT-MAGIC-COOKIE-1». Способ авторизации «MIT-MAGIC-COOKIE-1» является единственным из всех известных специфицированных (стандартизированных) способов авторизации для UNIX-подобных операционных систем.

При использовании TLS-протокола обеспечения безопасности (Transport Level Security — обеспечение безопасности на транспортном (четвертом) уровне Internet-архитектуры), также могут возникнуть проблемы с подтверждением электронных сертификатов, так как NAT-модуль может изменить информацию, содержащуюся в сертификате.

3.5. Интерпритатор удаленных команд RSH и протокол удаленного доступа «rlogin»

Интерпритатор удаленных команд (прикладной интерфейс для UNIX-подобных операционных систем) RSH[?] (Remote Shell) использует несколько сеансов связи для обслуживания раздельных потоков данных «stdout» и «stderr». Клиент передает на сервер случайный номер порта, который в дальнейшем используется для потока данных «stderr». Этот поток данных «stderr» представляет собой обратное соединение от сервера к клиенту. В отличие от FTP-протокола, функционирование RSH не предусматривает «пассивного режима» или ему подобного. При использовании классического NAT-модуля может возникнуть проблема функционирования RSH, так как NAT-модуль может запрепить проведение входящих сеансов связи.

Протокол удаленного доступа «rlogin» не предусматривает проведения нескольких одновременных сеансов связи. Но, в настоящее время в сетях активно используются программные версии RSH и «rlogin», которые защищены с помощью Kerberos-протокола. Эти версии также не могут функционировать совместно с NAT-модулем, так как возникают проблемы с Kerberos-билетами и использованием нескольких одновременных сеансов связи.

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».

4.2. Протокол RSVP (Resource Reservation Protocol)

Протокол резервирования ресурса (RSVP-протокол) является технологическим Internet-протоколом, расположенным на транспортном уровне Internet-архитектуры (над протоколом IPv4 или IPv6). Поэтому, в отличии от других протоколов транспортного уровня, RSVP-протокол не транспортирует данные прикладной службы (процесса), а функционирует как другие протоколы управления (например, ICMP, IGMP и протоколы маршрутизации), обеспечивая тем самым нормальное функционирование всей Internet-сети. RSVP-сообщения передаются в форме не обрабатываемых IP-пакетов (используя номер протокола «46») через ретрансляционные участки, которые обслуживаются маршрутизаторами, имеющими в своем составе программные RSVP-модули. Это означает, что не обрабатываемые IP-пакеты должны использоваться между оконечными системами и маршрутизатором, находящимся на первом (или последнем) ретрансляционном участке. Однако, это не всегда возможно, так как не все системы могут формировать не обрабатываемые двунаправленные сетевые потоки данных (Raw Network I/O — InputStream/OutputStream). В таком случае, существует возможность применения оконечными системами процедуры повторного обрамления RSVP-сообщении с помощью UDP-блоков, из которых формируются пакеты. Такие RSVP/UDP/IP-пакеты передаются, либо оконечными IP-узлми на UDP-порт 1698, либо маршрутизаторами с программными RSVP-модулями на UDP-порт 1699.

RSVP-сеанс связи представляет собой поток данных (сообщений), в которых указаны:

  • IP-адрес назначения (во всех информационных IP-пакетах). Это могут быть одно- и много адресные сообщения.

  • Идентификатор протокола транспортного уровня (например, UDP- или TCP-протокол).

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

При совместном использовании RSVP-протокола и NAT-модулей возможны две следующие проблемы:

  1. RSVP-сообщения могут содержать IP-адреса. В таком случае необходим RSVP-ALG-субмодуль, который должен изменять IP-адреса в зависимости от направления маршрута доставки и типа сообщения. Например, если бы внешний субъект передал RSVP-сообщение о маршруте субъекту корпоративной сети, то тогда бы RSVP-сообщение (в период RSVP-сеанса связи) содержало IP-адрес, который по предположению внешнего субъекта является IP-адресом субъекта корпоративной сети. Однако, когда RSVP-сообщение о маршруте будет принято NAT-модулем, последний должен изменить парамеры RSVP-сеанса связи, то есть модифицировать IP-адрес, чтобы RSVP-сообщение было принято субъектом корпоративной сети. Подобная процедура должна осуществлять со всеми, без исключения, сообщениями субъектов, содержащими IP-адреса.

  2. RSVP-протокол имеет собственные средства, которые обеспечивают целостность RSVP-сообщений. Но это является источником еще одной проблемы. С одной стороны, NAT-модуль должен иметь возможность модифицировать IP-адреса внутри RSVP-сообщений. Однако, с другой стороны, когда выполнение такой функции обеспечено, то тогда не возможно реализовать функцию защиты целостности RSVP-сообщений, так как RSVP-сообщение уже было изменено. Более того, при реализации функции защиты целостности RSVP-сообщений RSVP-ALG-субмодуль не работает.

4.3. Протокол DNS

В основе DNS-протокола (DNS-системы) лежит UDP/ТСР-протокол. DNS-имена присваиваются IP-узлам и используются локальными DNS-серверами, размещенными в корпоративных сетевых зонах, обслуживаемых NAT-модулями. DNS-имя, отображаемое в IP-адрес в интересах IP-узлов, расположенных в корпоративном сетевом сегменте, должно быть присвоено авторизованному DNS-серверу внутри корпоративной сети. В период проведения DNS-процедур информационного обмена (DNS-ПИНО) такой сервер может быть доступен в одинаковой степени и для внешних, и для корпоративных IP-узлов. В таком случае необходим DNS-ALG-субмодуль (RFC 2694), который бы преобразовывал IP-адреса в DNS-имена в DNS-запросах и ответах на них. Если IP-пакет, содержащие в поле полезной нагрузки DNS-сообщение, подвергается процедуре аутентификации/шифрования на основе DNSSEC-протоколов, то тогда DNS-ALG-субмодуль не сможет осуществлять процедуру преобразования IP-адресов в DNS-имена.

Прикладные службы (процессы), которые используют специализированные программные DNS-модули, так называемые DNS-клиенты, для отображения DNS-имени в IP-адрес, предполагают наличие специально выделенного IP-адреса для многократного использования в период прикладного сеанса связи. И поэтому потребуется DNS-ALG-субмодуль, который будет хранить специально выделенный IP-адрес (между корпоративной и внешней зоной, адресными пространствами), который можно будет использовать в период проведения предварительной процедуры настройки и после передачи DNS-запроса.

В противном случае, если нет необходимости в размещении DNS-сервера внутри корпоративного сетевого сегмента, то тогда бы корпоративные IP-узлы могли бы напрямую обращаться к внешним DNS-серверам для поиска внешнего DNS-имени. И если DNS-сервер размещен во внешней сети, то тогда нет необходимости использовать DNS-ALG-субмодуль.

4.4. Протокол SMTP

Проткол доставки сообщений электронной почты (Simple Mail Transfer Protocol — SMTP, RFC 821) основывается на ТСР-протоколе (номер ТСР-порта «25») и использует известную программу доставки электронной почты «sendmail». Почтовый сервер может быть расположен внутри или за пределами корпоратиной сети. Но серверу должно быть присвоено зарегистрированное глобальное имя и адрес и он должен быть доступен для все внешних IP-узлов. Когда почтовый сервер расположен внутри корпоративной сети, то тогда все входящие SMTP-сеансы связи должны быть перенаправлены на корпоративный IP-узел, в соответствии с его внешним IP-адресом. Если постовый сервер расположен во внешней сети, то тогда специализированного отображения не требуется.

Как правило, системы электронной почты настроены таким образом, чтобы все пользователи указывали один централизованный почтовый адрес (например, «[email protected] »), вместо использования адресов конкретных IP-узлов (например, «[email protected] »). Централизованный почтовый адрес должен быть представлен в форме DNS-записи «MX-RR» в DNS-БД, размещенной в DNS-сервере, доступном внешним IP-узлам.

В большинстве случаев, почтовые сообщения (в поле данных) не содержат ссылки на корпоративные IP-адреса или на виртуальные соединения, обозначенные DNS-именами, которые не должны быть доступны для объектов внешней сети. Однако, некоторые передаваемые почтовые сообщения содержат IP-адреса взаимодействующих прикладных процессов, отвечающих за доставку этих почтовых сообщений (Mail Transfer Agent — МТА). Эти IP-адреса размещены в поле «Received:» почтового сообщения. Некоторые почтовые сообщения содержат IP-адреса в поле «FQDN» (Fully Qualified Domain Name), которое используется в целях устранения неисправностей, или в поле «Mail From:» вследствие отсутствия DNS-записи (Resource Record — RR).

Если один или несколько МТА были размещены за NAT-модулем, то есть в корпоративной сети и все почтовые сообщения не защищаются с помощью процедуры аутентифкации или шифрования, то тогда можно использовать SMTP-ALG-субмодуль для преобразования информации об IP-адресе, зарегистрированным для МТА. Если МТА имеет статическое отображение адресов, то тогда доставка почтовых сообщений через различные адресные зоны может осуществляться в течении длительного периода времени.

Если использовать только один NAT-модуль без SMTP-ALG-субмодуль, то тогда процедура выбора маршрута доставки почтовых сообщений может быть затруднена или вообще не возможна. При чина этого в том, что могут возникнуть проблемы, связанные с устранение неисправностей и сбоев или противоправными действиями криминальными пользователями.

4.5. Протокол SIP

Протокол инициирования сеанса связи (Session Initiation Protocol — SIP, RFC-2543) способен функционировать и с ТСР- и с UDP-протоколом и, по умолчанию, использует ТСР/UDP-порт с номером «5060».

Когда SIP-протокол функционирует совместно с UDP-протоколом, то тогда ответ на SIP-запрос не поступает на UDP-порт источника запроса, то есть откуда был передан SIP-запрос. Было бы правильнее, если бы SIP-сообщение содержало номер порта транспортного уровня, на который должен быть отправлен ответ. В SIP-протоколе используется номер ICMP-порта для ответного сообщения об ошибке, связанной с невозможностью достичь IP-узла, на который было передан запрос. Сообщения-запросы обычно передаются на уже используемый порт. Если ответы передаются на порт источника запроса, указанный в этом запросе, то тогда прикладной процесс, передавший запрос, должен «слушать» (контролировать) тот порт, через который передал свой запрос. Однако, если разрешить передавать ответы на одиночный порт транспортного уровня, то тогда вместо «прослушивания» порта можно использовать только один прикладной процесс.

Сервер может размещать в сообщении номер каждого активного порта источника сообщения. Затем каждый прикладной процесс может раздельно контролировать активные порты на предмет поступления на них ответных сообщений. Так как номер порта для ответного сообщения может не совпадать с номер порта источника запроса, а SIP-протокол, как правило, не взаимодействует с NAT-модулем, то в такой ситуации будет необходим SIP-ALG-субмодуль.

SIP-сообщения доставляют в поле полезной нагрузки самые различные данные, которые определяются своим MIME-типом (Multipurpose Internet Mail Extensions, RFC 2045). В период проведения многопротокольных (multimedia) сеансов связи, обычно, используется протокол определения сеанса связи (Session Description Protocol — SDP, RFC-2327). SDP-протокол может определять IP-адреса или номера портов транспортного уровня, которые используются для информационного обмена в период многопротокольных сеансов связи. Эти IP-адреса или номера портов могут терять смысл, если multimedia-сообщения транслируются через NAT-модуль. Следовательно, в такой ситуации может понадобиться SIP-ALG-субмодуль, который будет распределять и транслировать данные по соответствующим виртуальным соединениям.

SIP-сообщения доставляют в полях «Contact», «To» и «From» URL-идентификаторы, которые определяют адреса сигнализации/синхронизации процедур. Такие URL-идентификаторы могут содержать IP-адреса или DNS-имена (как часть идентификационного блока, определяющего порт IP-узла). Эти IP-адреса или DNS-имена могут потерять свой смысл, так как будут преобразованы, если SIP-сообщения транслируются через NAT-модуль.

Как альтернатива SIP-ALG-субмодулю, SIP-протокол может назначить уполномоченный сервер (proxy server), который может быть «совмещен» с NAT-модулем и функционировать с таким же глобальным IP-адресом (транспортнымпортом), как и у NAT-модуля. Такой proxy-сервер может иметь собственную специфическую настройку.

4.6. Прикладная служба звукового вещания (RealAudio)

В режиме по умолчанию, для иницирования процедуры информационного обмена с сервером прикладной службы звукового вещания (предположим, что он расположен в сети общего пользования) пользователи RealAudio-службы (предположим, что они находятся в корпоративном сетевом сегменте) используют ТСР-порт с номером «7070». В период звукового вещания, этот же ТСР-порт используется для обмена управляющими сообщениями (например, прерывание (пауза) или остановка (прекращение) цифрового вещательного потока). Параметры вещательного сеанса связи передаются с помощью управляющего ТСР-сеанса связи в форме последовательности байтов.

Реальный вещательный трафик транслируется в обратном направлении (от RealAudio-сервера) в форме IP-пакетов, содержащих UDP-блоки, поступающих на UDP-порты с номерами в диапазоне «6970…7170».

Если на пути передачи вещательного трафика имеет место NAT-модуль, то тогда последний будет его прерывать. Для предотвращения такой ситуации понадобиться применение ALG-субмодуля, который будет контролировать ТСР-трафик и обнаруживать параметры вещательного сеанса связи, а также выборочно предоставлять (указывать) UDP-порты для входных UPD-сеансов связи в соответствии с информацией управляющего ТСР-сеанса связи. В противном случае, ALG-субмодуль мог бы просто перенаправлять все входные UPD-сеансы связи, UDP-блоки которых поступают на UDP-порты с номерами в диапазоне «6970…7170», на IP-адрес пользователя в корпоративной сети.

Если используется двунаправленный NAT-модуль, то тогда вообще нет необходимости использовать ALG-субмодуль. Двунаправленный NAT-модуль может просто обслуживать в отдельности каждый ТСР- и UDP-сеанс связи, как не связанные между собой, и осуществлять процедуру трансляции IP-адресов и номеров портов транспортного уровня в IP- и ТСР/UDP-заголовках.

4.7. Рекомендация ITU-T H.323

Рекомендация ITU-T H.323 определяет протокол (и интерфейс) для непрерывного информационного обмена, относящийся к классу поточных протоколов: сообщения формирующие поток трафика жестко зависят от предшествующих сообщений и сильно влияют на последующие сообщения.

Протокол Н.323 является сложным протоколом, использующим динамические порты транспортного уровня, и организует несколько потоков UDP-трафика. В общем, при функционировании Н.323-протокола имеют место две следующие проблемы.

Процедура инициализации Н.323-протокола формирует несколько одновременных различных виртальных соединений. По меньшей мере два из этих соединений обслуживают ТСР-сеансы связи. В период проведения только аудио-конференцсвязи, может быть организовано четыре разичных соединения для обслуживания UDP-сеансов связи.

Все виртуальные соединения (за исключением одного) обслуживают кратковременные (динамические) порты транспортного уровня.

Процедуры инициализации (вызова/запроса) Н.323-протокола могут осуществляться как из корпоративных сетей, так из сетей общего пользования. В период проведения сеансов конференцсвязи было бы полезно, чтобы внешние пользователи имели способность осуществлять прямые вызовы корпоративных пользователей и устанавливать с ними непосредственные соединения (с корпоративными терминалами).

Сетевые адреса и номера портов транспортного уровня, содержащиеся в следующих друг за другом сообщениях трафика, изменяются от сеанса к сеансу связи, которые обслуживаются конкретными виртуальными соединениями. Например, номер транспортного порта для Н.245-соединения (Рекомендация ITU-T H.245 определяет протокол управления многопротокольными (multimedia) сеансами связи) устанавливается в период проведения Q.931-сеанса связи (Рекомендация ITU-T H.245 определяет цифровую абонентскую систему сигнализации для ISDN-сетей, Digital subscriber Signalling System №.1 — DSS1). (Очевидно, что в такой ситуации может потребоваться ALG-субмодуль для преобразования IP-адресов в сообщениях Q.931-сеанса связи, однако, с практической точки зрения, это реализовать чрезвычайно трудно.) Ситуация еще более ухудшается, если в период проведения Q.931-сеанса связи, например, будет обнаружено, что все сообщения Н.245-соединения должны быть защищены (зашифрованы). Если все-таки все сообщения Н.245-соединения должны быть зашифрованы, то тогда использование ALG-субмодуля будет невозможно до тех пор, пока ему не будет известен криптоключ.

Почти вся управляющая информация кодируется с помощью ASN.1-кода (только абонентская информация в блоках данных (Protocol Data Unit — PDU) Q.931-проткола сигнализации кодируется ASN.1-кодом (Abstract Syntax Notation), а другие поля PDU-блоков просто не кодируются).

На рис.1 представлена временная диаграмма типовой процедуры установления Н.323-соединения между двумя пользователями («А» и «В»). Пользователь «А» имеет IP-адрес «88.88.88.88», а пользователь «В» — «99.99.99.99».

Замечание. Q.931- и Н.245-сообщения, размещенные в поле полезной нагрузки IP(RTP)-пакетов для RTP-протокола (Real Time Protocol, RFC 1889 — протокол доставки данных в масштабе реального времени, например, видео- и аудиосообщения), кодируется ASN.1-кодом.

Если соединение осуществляется через NAT-модуль, то тогда может потребоваться H.323-ALG-субмодуль для проверки IP(RPT)-пакетов, декодирования ASN.1-кода и преобразования нескольких IP-адресов, используемых виртуальными соединениями, которые контролируются и управляются Н.323-протоколом.

Диаграмма типовой процедуры установления Н.323-соединения

Рис.1. Диаграмма типовой процедуры установления Н.323-соединения

Замечание. Если Н.323-сервер (сетевой шлюз) расположен за пределами границы, обслуживаемой NAT-модулем (то есть внутри корпоративной сети), то тогда H.323-ALG-субмодуль должен быть «осведомлен» о различных схемах обнаружения сетевого шлюза и функционально адаптирован к таким схемам. Или, если за пределами границы, обслуживаемой NAT-модулем, расположен только H.323-терминал(IP-узел) и он был зарегистрирован на Н.323-сервер/шлюзе, то тогда информация об IP-адресах, содержащаяся в регистрационных сообщениях, должна была быть преобразована NAT-модулем.

4.8. Протокол SNMP

Протокол сетевого управления (Simple Network Management Protocol — SNMP, RFC 1157) функционирует на основе UDP-протокола. Поле полезной нагрузки IP-пакета с SNMP-сообщением может содержать IP-адреса или может ссылаться на IP-адреса, используя для этого индекс из MIB-таблицы (Management Information Base). Следовательно, когда сетевые элементы, расположенные внутри корпоративного сегмента, управляются IP-узлом, расположенном в сети общего пользования, то тогда IP(SNMP)-пакеты, передаваемые через NAT-модуль, могут содержать информацию, которая не имеет отношения ко внешней сети. В таких случаях, может быть использован SNMP-ALG-субмодуль (RFC 2962), который будет прозрачно преобразовывать корпоративные IP-адреса в глобальные зарегистрированные IP-адреса. Такой SNMP-ALG-субмодуль предполагает применение статического отображения адресов и двунаправленного NAT-модуля. Такая схема может функционировать только при определенном наборе типов данных, «понимаемых» SNMP-ALG-субмодулем, и с конкретным набором MIB-модулей. Более того, замена IP-адресов в поле полезной нагрузки IP-пакета с SNMP-сообщением может повлечь сбои при функционировании виртуального соединения, так как может измениться размер сообщения или его лексикографический порядок.

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

В противном случае, необходимо использование уполномоченных SNMP-серверов (proxy SNMP-server), которые будут функционировать совместно с NAT-модулями для отправки SNMP-сообщений SNMP-объектам, расположенным в сети общего пользования (и наоборот). Уполномоченные SNMP-серверы специально приспособлены к условиям корпоративного сетевого сегмента и, следовательно, способны функционировать не зависимо от специфики управляемых сетевых объектов, к которым обеспечивают доступ. Такая схема (с применением SNMP-уполномоченных) требует использования внешнего управляющего модуля, который был бы «проинформирован» о наличии уполномоченного SNMP-сервера, а управляемые SNMP-объекты должны быть настроены так, чтобы они направляли свой SNMP-трафик (запросы и ответы) на этот уполномоченный SNMP-сервер.

5. Протоколы, разработанные специально для функционирования с NAT-модулем

5.1. Компьтерные игры компании «Activision»

Компьтерные игры американской компании «Activision» разработаны специально для совместного функционирования с NAT-модулями, и поэтому они не требуют использования специализированного ALG-субмодуля, который бы обеспечивал прозрачную доставку игрового трафика через классический NAT-модуль. Участники игры, расположенные внутри корпоративной сети, могут играть с другими пользователями, расположенными в этой же сети и во внешеней сети общего. Игровой протокол компании «Activision» запатентован и основан UDP-протоколе. Игровой IP-сервер использует UDP-порт с номером «21157» и предполагается, что он расположен в глобальной адресной зоне.

В начале, участники игры устанавливают соединение с игровым IP-сервером, то есть передают в первом сообщении свой корпоративный IP-адрес и корпоративный номер UDP-порта (корпоративную адресную информацию). Этот сервер регистрирует корпоративную адресную информацию (из текста сообщения), а также внешюю адресную информацию (из IP- и UDP-заголовков). Затем, игровой сервер передает корпоративную и внешнюю адресную информацию одного игрока всем другим активным участникам игры. С этого момента, каждый активный игрок знает корпоративную и внешнюю адресную информацию каждого другого участника игры. После этого, каждый клиент устанавливает прямое дуплексное соединение с каждым другим (по принципу «каждый с каждым») и использует какой угодно адрес (корпоративный или внешний), который «сыграет» первым.

Теперь, клиенты могут устанавливать прямые соединения с другими клиентами, либо они могут устанавливать соединения с другими клиентами через игровой сервер. Сущность игрового протокола заключается в том, что он позволяет повторно использовать ту же самую адресную информацию (глобальный IP-адрес с назначенным UDP-портом), которая использовалась при установлении первичного соединения с игровым сервером, при всех последующих соединениях с клиентом. Активный игрок определяется либо одним (корпоративный IP-адрес и корпоративный номер UDP-порта) или всеми (глобальный IP-адрес с назначенным UDP-портом) другими активными игроками. Таким образом, привязка адресных блоков (адрес/порт), хранящаяся в NAT-модуле, должна оставаться неизменной, причем на протяжении всего сеанса связи между участником игры и одним другим игроком или несколькими другими игроками.

Процедура установления соединения с корпоративного IP-узла с игровым сервером не вызывает проблем. Все NAT-модули, которые могут быть использованы, должны обеспечивать прозрачную маршрутизацию и хранить одну и ту же привязку адресных блоков (адрес/порт) для отображения корпоративного блока в глобальный (и наоброт) в течении, как минимум, одного игрового сеанса связи с внешним IP-узлом. Но NAPT-модуль должен быть настроен для обслуживания нескольких одновременных UDP-сеансов связи с использованием одного и того же глобального IP-адрес с назначенным UDP-портом.

Однако, такая система применения NAT-модулей может столкнуться с несколькими проблемами. Например, клиент мог попытаться установить соединение с другим клиентом с помощью корпоративного IP-адреса, но такой корпоративный IP-адрес мог использоваться локально и в другой корпоративной сетевой зоне, то есть один и тот же корпоративный IP-адрес используется локально в нескольких корпоративных сетях. Если IP-узел, с которым было установлено ошибочное соединение, относится к системе другой прикладной службы или UDP-порт его службы является не зарегистрированным, то тогда все сообщения протокола компании «Activision», предназначенные для установления соединения, будут просто уничтожаться. И если все-таки, что мало вероятно, прикладной процесс зарегистрированной прикладной службы примет на обработку сообщение протокола компании «Activision», то тогда результаты такой обработки будут просто не предсказуемые.

6. Благодарности

Авторы хотели бы выразить искреннюю благодарность Bernard Aboba, Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine, Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver и другим, кто внёс ценный вклад в подготовку этого документа. Отдельное спасибо Dan Kegel за то, что поделился методологией проектирования Activision games.

7. Вопросы безопасности

Соображения безопасности, изложенные в [NAT-TERM], актуальны для всех NAT устройств. Этот документ не поднимает дополнительных вопросов безопасности.

8. Литература

[NAT-ARCH] Hain, T. «NAT с точки зрения Internet-архитектуры», RFC 2993, Ноябрь 2000.
[SMTP] Postel, J., «Simple Mail Transfer Protocol», STDl 10, RFC 821, Август 1982.
[FTP] Postel, J. и J. Reynolds, «File Transfer Protocol (FTP)», STD 9, RFC 959, Октябрь 1985.
[SIP] Handley, M., Schulzrinne, H., Schooler, E. и J. Rosenberg, «SIP: Session Initiation Protocol», RFC 2543, Март 1999.
[X Windows] Scheifler, B., «FYI on the X Window System», FYI 6, RFC 1198, Январь 1991.
[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. и S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, Сентябрь 1997.
[DNS-TERMS] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, Ноябрь 1987.
[DNS-IMPL] Mockapetris, P., «Domain Names — Implementation and Specification», STD 13, RFC 1035, Ноябрь 1987.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. и A. Heffernan, «DNS extensions to Network Address Translators (DNS_ALG)», RFC 2694, Сентябрь 1999.
[IPsec] Kent, S. и R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, Ноябрь 1998.
[IPsec-ESP] Kent, S. и R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, Ноябрь 1998.
[IPsec-AH] Kent, S. и R. Atkinson, «IP Authentication Header», RFC 2402, Ноябрь 1998.
[IPsec-DOCS] Thayer, R., Doraswamy, N. и R. Glenn, «IP Security Document Roadmap», RFC 2411, Ноябрь 1998.
[NAT-SEC] Srisuresh, P., «Security Model with Tunnel-mode IPsec for NAT Domains», RFC 2709, Октябрь 1999.
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, и E. Lear, «Распределение адресов в частных IP-сетях», RFC 1918, BCP 5, Февраль 1996.
[NAT-TERM] Srisuresh, P. и M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, Август 1999.
[NAT-TRAD] Srisuresh, P. и K. Egevang, «Традиционная трансляция сетевых адресов IP (NAT)», RFC 3022, Январь 2001.
[H.323] ITU-T SG16 H.323, Intel white paper, «H.323 and Firewalls», Dave Chouinard, John Richardson, Milind Khare (with further assistance from Jamie Jason).
[SNMP-ALG] Raz, D., Schoenwaelder, J. и B. Sugla, «An SNMP Application Level Gateway for Payload Address Translation», RFC 2962, Октябрь 2000.
[SNMP-APPL] Levi, D., Meyer, P. и B. Stewart, «SNMP Applications», RFC 2573, Апрель 1999.
2007 - 2022 © Русские переводы RFC, IETF, ISOC.