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

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

VI. НЕДОСТАТКИ NAT-МОДУЛЕЙ

Проблемы, вызванные функционированием NAT-модулей, следующие:

Œ  NAT-модули нарушают принцип “сквозного соединения” в Internet;

  NAT-модули являются точками отказа всей системы, то есть их отказ в работе влечет сбой всей системы, так как они контролируют состояние соединения и динамически преобразуют данные;

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

  NAT-модули не позволяют использовать средства обеспечения информационной безопасности на IP(сетевом)-уровне Internet-архитектуры;

  NAT-модули могут привести к конфликтным ситуациям, являющимся следствием применения корпоративных IP-адресов. Такие не согласованные IP-адреса являются причиной всевозможных недоразумений особенно тогда, когда компании, использующие такие IP-адреса сливаются в одну компанию или хотят напрямую соединиться использя для этого VPN-технологию;

‘  NAT-модули способствуют более легкой привязки существующих корпоративных наборов имен к DNS-именам общего пользования;

’  NAPT-модули (и их RSIP-разновидности) увеличивают функциональную сложность прикладных систем особенно в тех случаях, когда программные модули прикладных служб общего пользования располагаются внутри корпоративных сетей;

“  NAT-модули усложняют или вообще могут исключить применение процедур аутентификации в интересах SNMPv3-протокола;

”  сетевые объекты могут использовать NAT-функции без оповещения других сетевых объектов об этом.

При проектировании прикладных протоколов необходимо учитывать, что NAT-модули накладывают ограничения на функциональную сетевую гибкость. По существу, появление дополнительных трудностей, связанных с использованием NAT-модулей, требует к себе более пристального внимания. И это вполне понятно, особенно там, где NAT-модули функционируют скрытно, например, маршрутизаторы, выравнивающие нагрузку, которые переписывают IP-адреса в другие IP-адреса общего пользования. Так как все IP-адреса могут относится в адресному пространству общего пользования, они редко распознаются как адреса NAT-модулей, но последние все равно нарушают целостность модели “сквозного соединения”.

NAT-модули накладывают ограничения на распространение прикладных служб, которые включают IP-адреса (или их производные) в поля полезной нагрузки своих сообщений. Более того NAT-модули функционируют в предположении, что каждый сеанс связи независит от другого. Однако, существуют прикладные службы, такие как служба доставки файлов (FTP-протокол) и система видеоконференцсвязи (Рекомендация ITU-T Н.323), которые используют один или несколько управляющих сеансов связи для передачи, согласования и настройки параметров последующих информационных сеансов связи, причем сами параметры размещаются в поле полезной нагрузки управляющих сообщений. Другими примерами являются SNMP-протокол (настройка базы данных управляющей информации — MIB) и единая служба определения открытой стратегии (COPS-сообщения — Common Open Policy Service). Прикладные службы и протоколы, подобные этим, предполагают обеспечения “свозной” целостности IP-адресов, а при наличии NAT-модуля на маршруте следования IP-пакетов, содержащих их сообщения, будут прекращать свое функционирование. (ТСР-протокол транспортного уровня Internet-архитектуры был специально разработан для того, чтобы получить дополнительное преимущество от использования IP-адреса в сочетании с ТСР-портами, то есть адресного блока (адрес/порт), что позволяет многократно использовать один и тот же IP-адрес.) Для предотвращения негативного влияния NAT-модулей на функционирование таких прикладных служб необходимо использование ALG-субмодуля, который должен размещаться внутри или рядом с каждым NAT-модулем. Для каждой прикладной службы, которая может размещать в поле полезной нагрузки своих сообщения IP-адреса, необходимо использование дополнительной системы ALG-субмодулей.

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

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

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

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

Динамический NAT-модуль и RSIP-модуль будут, в конечном счете, нарушать предположения верхних уровней Internet-архитектуры о повторном использовании адресного блока (адрес/порт), как это определено в стандартах RFC-793, RFC-1323. Функциональное состояние (режим) ТСР-протокола “TCP_TIME_WAIT” специально разработано для защиты от повторной передачи IP-пакетов между сетевым интерфейсом с 4-байтовым IP-адресом и транспортныи интерфесом с номером ТСР-порта для конкретной пары IP-адресов (отправитель/получатель). Так как оконечный ТСР-процесс, алгоритм которого представляет собой конечный автомат (функционирующий в IP-узле), ничего не знает о каком-либо предшествующем использовании RSIP-модуля, его попытка соединиться с той же самой удаленной службой, которая ближе всего к нему и только что освободилась (которая по-прежнему находится в состоянии “TCP_TIME_WAIT”), может потерпеть неудачу, или оконечный ТСР-процесс попытается открыть прежнее соединение, но с большим последовательным номером, прямо из состояния “TCP_TIME_WAIT” в ущерб защиты, обеспечиваемой состоянием “TCP_TIME_WAIT”.

Если используются NAT-модули (без функции трансляции номеров портов транспортного уровня), которые удовлетворяют требованиям состояния “TCP_TIME_WAIT”, то тогда они должны воздерживаться от назначения одного и того же IP-адреса различным IP-узлам пока не пройдет интервал времени, равный “2×MSL”*, с момента последнего использования IP-адреса. Если используются NAT-модули (с функцией трансляции номеров портов транспортного уровня), которые удовлетворяют требованиям состояния “TCP_TIME_WAIT”, то тогда они должны просто воздерживаться от назначения одного и того же адресного блока (адрес/порт) пока не пройдет интервал времени, равный “2×MSL”, с момента последнего использования этого адресного блока. Несмотря на то, что эти требования являются простыми для обслуживания соединения, они могут оказать серьезное функциональное давление на NAT-модуль, так как они временно сокращают диапазон доступных IP-адресов и номеров портов транспортного уровня. Соответственно, возникнет дилемма, либо разработчики NAT-модулей будут игнорировать требования состояния “TCP_TIME_WAIT”, либо будут сокращены сами требования состояния “TCP_TIME_WAIT” в ущерб высокой надежности ТСР-протокола. (Замечание. В случае, когда высокая надежность, фактически, скомпрометирована за счет появления старого IP-пакета, отказ в работе может обнаружиться сам по себе, так как приемный модуль получит искаженые данные.)

Иногда появляется аргументация того, что NAT-модули выполняют простую функцию, которая упрощает “маршрутные зоны”, то есть когда каждый сетевой сегмент отвечает за поиск IP-адресов в пределах собственных границ. Такая точка зрения скрывет ограничения, вызванные применением NAT-модуля и более глубоким пониманием необходимости управления маршрутизацией. Корректное обособление маршрутной информации является функцией протколов маршрутизации в пределах их компетенции. NAT-модуль — это просто средство для административного распределения IP-адресов и для реализации процедуры отображения IP-адресов одной адресной зоны в IP-адреса другой адресной зоны.