Транслятор сетевых ip-адресов с точки зрения internet-архитектуры (nat) (стр. 6 )

7.3. Нарушение функциональных режимов ТСР-протокола

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

Предположим, что IP-узел “А” завершает свои сеансы связи и закрывает W3-соединение (с W3-сервером) через ТСР-порт номер “80”, а RSIP-молуль освобождает внешний IP-адрес общего пользования, который временно принадлежал IP-узлу “А”. IP-узел “В” инициирует соединение с тем же самым W3-сервером, затем NAT/RSIP-модуль присваивает IP-узлу “В” внешний IP-адрес общего пользования, который ранее принадлежал IP-узлу “А”, но сейчас является свободным.

Правила выбора ТСР-порта источника, реализуемые IP-узлом “В”, могут привести к такому же выбору, который был осуществлен IP-узлом “А”. Соединение, инициированное IP-узлом “В”, не будет установлено, так как W3-сервер, выполняющий требования ТСР-протокола, перешел в режим ожидания “ТСР_TIME_WAIT” (в течении 4 минут) по отношению к IP-адресу, который использовался IP-узлом “А”. В дальнейшем, IP-узел “В” обратится к системе с жалобой по поводу отказа в соединении и за помощью, требуя повторить попытку соединиться с W3-сервером. Более того, эта конфликтная ситуация будет обозначена как разрешенная положительно, но, фактически, это спорадическая (возникающая от случая к случаю), но постоянная проблема.

Рис.4. Пример корпоративной сети компании, имеющей внутренние маршрутизаторы

7.4. Управление состоянием симметричного соединения

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

Рассмотрим следующий случай (рис.4), при котором связь “Х” (группа физических линий/каналов) прервана или заблокирована. Основываясь на общих принципах маршрутизации, полагаем, что лучшим маршрутом доставки IP-пакетов до Internet-сети, с точки зрения 1-го и 2-го маршрутизаторов, является маршрут через 1-ый NAT-модуль, при том, что затребованный в Internet-сети обратный маршрут до корпоративного сетевого сегмента, с группой IP-адресов, управляемых NAT-модулями, будет проходить через 1-ый NAT-модуль, так как будет лучшим среди возможных. Когда маршрут “Х1” не возможен, 2-ой маршрутизатор может попытаться связаться со 2-ым NAT-модулем, но обратный маршрут из внешней сети будет по-прежнему через 1-ый NAT-модуль. Это объясняется тем, что 1-ый NAT-модуль отвечает за предоставление IP-адресов из корпоративной адресной группы. Непосредственно связанные между собой маршрутизаторы (после восстановления связи между ними), в такой же ситуации, возможно нашли бы новые специфические маршруты доставки IP-пакетов. Но в данном случае избыточность бесполезна.

Рассмотрим второй случай, когда маршрут “Х1” возможен, то есть прямая связь между 1-м и 2-м маршрутизаторами восстановлена, а некоторый удаленный маршрут “Х2” не возможен (группа физических линий/каналов связи прервана или заблокирована). Также полагаем, что DNS-сервер (DNS-система) направляет ответные DNS-сообщения с IP-адресами обоих NAT-модулей, когда запрашиваются IP-адреса IP-узлов “А” и “В”. Когда IP-узел “D” пытается соединиться с IP-узлом “В”, запрос на соединение проходит через 2-ой NAT-модуль, но благодаря внутренней маршрутизации, ответ на запрос пройдет через 1-ый NAT-модуль. Так как информация о состоянии данного соединения будет храниться во 2-ом NAT-модуле, 1-ый NAT-модуль будет осуществлять новое отображение IP-адресов. Даже если удаленный маршрут будет восстановлен, все равно соединение не будет установлено, так как запросы были направлены по IP-адресу общего пользования, принадлежащему 2-ому NAT-модулю, несмотря на то, что ответы на них направлял 1-ый NAT-модуль, имеющий свой IP-адрес общего пользования.

В третьем случае, оба IP-узла “А” и “В” желают установить соединение с IP-узлом “D”, при этом удаленная связь “Х2” (группа физических линий/каналов) прервана или заблокирована. Опять полагаем, что маршрут “Х1” не возможен. Тогда, IP-узел “В” имеет возможность соединиться с IP-узлом “D”, а IP-узел “А” отрезан от IP-узла “D”. Без полной информации о топологии внешней (удаленной) сети (маловероятно, что Internet-провайдеры  склонны обмениваться такой весьма критичной собственной информацией), администратор IP-узлов “А” и “В” (корпоративной сети) не сможет понять почему один IP-узел работает, а другой нет. Со своей стороны, он может запросить дополнительные маршруты через NAT-модули, которые, в принципе возможны, но реально работает только одно соединение. С другой стороны, это есть следствие недостатка информации о топологии сети, которая в данном случае просто необходима, так как объект (система) с последействием информирует о наличии (доступности) группы IP-адресов (управляемых этим объектом с последействием) еще до того, как это сделают сети, соединенные с корпоративным сетевым сегментом, обслуживаемым эти объектом с последействием.

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

7.5. Необходимость глобального полного DNS-имени при взаимодействии

  с прикладными службами общего пользования

Основное предназначение NAT-метода — обеспечение “простого” соединения корпоративных сетей с Internet-сетью общего пользования. Если корпоративная сеть существовала до загрузки программного NAT-модуля, то тогда маловероятно (и в этом нет необходимости), что DNS-клиент этой корпоративной сети стал бы использовать зарегистрированный DNS-сегмент. В стандарте RFC 1123 указано, что DNS-запросы могут быть направлены на обработку DNS-клиенту с помощью локальных многоадресных сообщений. Подключение NAT-модуля, а также перенастройка DNS-клиента, который обслуживает этот NAT-модуль и размещен на уполномоченном DNS-сервере, на обработку всех внешних запросов, обеспечивает корпоративным IP-узлам доступ в сеть общего пользования. Настройка DNS-сервера общего пользования для обслуживания группы корпоративных IP-узлов, которым необходимо инициировать соединения с IP-узлами сети общего пользования,