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

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

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

И в заключении, несмотря на то, что различные разновидности NAPT-модулей (с функцией объединения портов транспортного уровня) работают весьма хорошо, когда корпоративные IP-узлы устанавливают соединения с серверами прикладных служб общего пользования (NAPT-модули популярны как раз потому, что позволяют обеспечивать множественный доступ в Internet-сеть, используя для этого только один IP-адрес), но они порождают проблемы управления соединением, когда серверы прикладных служб, расположенные в сети общего пользования, устанавливают соединение с корпоративными IP-узлами. В таких случаях, понятие “хорошо известный” порт нарушается, так как только одна корпоративная часть системы может быть отображена с помощью одного номера порта транспортного уровня внешней части системы. Это также будет иметь отношение к домашним сетям, когда прикладные службы, на подобии многопользовательских компьютерных Internet-игр, могут быть активизированы только в одной части системы на все время. Это также затронет системы для малого бизнеса, когда только одна система может быть задействована с использованием стандартного порта транспортного уровня на все время с целью обслуживания W3-служб. Пока это выглядит как ограничения среднего уровня, но в связи с тем, что основные свойства и характеристики Internet-сети не изменяться в будущем, такие ограничения в дальнейшем крайне не желательны. Проблема также состоит в том, что перед установлением соединения, инициируемого из сети общего пользования в корпоративную сеть, требуется административное отображение адресного блока для каждого получателя. Если Internet-провайдер выберет стандартную версию этой процедуры с целью снижения дополнительных функциональных процедур настройки, то тогда ему понадобиться нести дополнительные затраты, связанные с управлением ALG-субмодулей, и которые могут превысить затраты, связанные с использование доплнительного адресного пространства.

VII. ПОЯСНЕНИЯ

7.1. Точка отказа все системы

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

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

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

 

Рис.2. Пример корпоративной сети компании, имеющей удаленные

корпоративные сетевые сегменты

7.2. Сложность ALG-субмодулей

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

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-модули, несмотря на частые или одновременные изменения топологии корпоративной и внешней сетей.