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

Другие наиболее важные аспекты модели “сквозного соединения” следующие:

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

‚  ключевым принципом расширения (масштабирования) сетей является перемещение функций управления соединениями на границы сети. Если управление состоянием соединений осуществляется сетевыми объектами, расположенными в магистральной части сети, то тогда в случае расширения сети, количество сетевых объектов, осуществляющих управление соединениями, также должно увеличиться. Условия функционирования сетевых объектов могут ухудшиться, сделав их “узким местом” в сети, и, следовательно, число соединений, которые могут выйти из строя, также возрастет;

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

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

В стандарте RFC-2101, в этой связи, отмечено: “Так как АН-протокол IPsec-архитектуры предполагает, что сетевыен IP-адреса в заголовке IP-пакета не изменяются на всем маршруте следования между оконечными IP-узлами, то тогда не очевидно, как можно обеспечить аутентификацию с помощью АН-протокола между двумя взаимодействующими IP-узлами, которые соединены через ALG-субмодуль или NAT-модуль.”

Кроме этого, существуют распределенные прикладные службы, которые предполагают, что IP-адреса являются глобальными и приемлемыми для осуществления процедур маршрутизации, и что все другие IP-узлы и прикладные службы имеют такое же представление об IP-адресах. Действительно, такие прикладные службы используют стандартный способ организации соединения и дальнейшего управления им, при котором один IP-узел передает другому IP-узлу свой IP-адрес и номер пóрта транспортного уровня, чтобы второй IP-узел (получатель этого адресного блока) смог бы соединиться с первым IP-узлом (инициатором соединения). К сожалению, NAT-модули нарушают функционирование таких прикладных служб. Также существуют и другие прикладные службы, которые предполагают, что все пóрты транспортного уровня для конкретного IP-адреса отображаются в точно такие же пóрты транспортного уровня на другом оконечном IP-узле. Однако, NAPT-модули (и их RSIP-разновидность), использующие методы объединения нескольких пóртов в один, нарушают функционирование таких прикладных служб. Например, W3-серверу необходимо установить соединение с другим W3-сервером, используя для этого свой порт “80” и порт другого сервера “443”, но вследствие наличия на маршруте следования IP-пакетов NAT - и NAPT-модуля нельзя гарантировать, что один IP-адрес будет принадлежать одному и тому же IP-узлу, в котором размещен W3-сервер.

Ограничение функционирования таких прикладных служб не является второстепенной проблемой: основной причиной сегодняшнего успешного и стремительного развития Internet-сети является “лёгкость и простота”, с которой новые прикладные службы могут встраивать свои программные модули в оконечные IP-узлы, не требуя при этом каких-либо изменений в объектах сетевой инфраструктуры. Если новые прикладные службы должны иметь встроенные программные NAT-модули и при этом необходимо обеспечить их повсеместное распространение и внедрение, то тогда, очевидно, что быстрое их распространение и внедрение не возможно, так как будут тормозиться по причине использования NAT-модулей.

V. ПРЕИМУЩЕСТВА NAT-МОДУЛЕЙ

Беглый взгляд на весьма популярный NAT-метод показывает, что он позволяет решить несколько реальных глобальных проблем, когда он используется на границе сетевого субсегмента:

  путем сокрытия изменений IP-адресов, которые имели место вследствие использования наборного доступа в сеть или смены провайдера, минимизируется отрицательное влияние на корпоративную сеть, то есть не требуется перенумерация объектов внутри корпоративной сети;

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

ƒ  существует возможность для Internet-провайдера, который обслуживает и управляет NAT-модулями, снизить бремя собственной нагрузки, если он встроит дополнительный прораммный модуль с заранее известными параметрами в пользовательский интерфейс доступа в сеть;

„  разбиение Internet-сети на совокупность сетевых адресных сегментов, каждый из которых управляется своей полномочной администрацией, снижает необходимость постоянно объяснять причины и порядок того или иного распределения адресного субпространства, а также позволяет сетевым администраторам отказаться от использования более сложных методов маршрутизации;

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

†  подобно сетевым экранам (брандмауэрам) на основе фильтрации IP-пакетов, NAPT-модули (и их RSIP-разновидность) блокируют входные соединения на всех портах транспортного уровня, причем до тех пор, пока не будет получено административное разрешение на их преобразование.

Теперь определив все положительные качества NAT-метода, можно понять более строгую мотивацию того, почему NAT-модули получили широкое распространение в Internet-сети. Классические NAT-модули (RFC 3022) осуществляют относительно более простую функцию отображения адресов, которая более понятна.

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

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

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

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