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

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

Все в этом рассмотренном примере будет работать, но до тех пор, пока прикладная служба не укажет (разместит) свое имя в DNS-системе. Например (рис.5), W3-сервер, размещенный на IP-узле “D”, может может иметь зарегистрированный URL-идентификатор в форме “http://D/bar.html”, который будет работать с IP-узлом “С”, но вполне может ввести в заблуждение IP-узел “А”. Если на DNS-запрос c зарегистрированным URL-идентификатором поступил ответ с IP-адресом общего пользования, то тогда IP-узел “А” будет более удачным, по сравнению с IP-узлом “С”, который будет продолжать поиск  некоего удаленного IP-узла. Используя полное DNS-имя для установления соединения между IP-узлами “C” и “D” (в даном случае инициатором соединения является IP-узел “C”), в начале NAT-модуль должен будет проверить адрес (идентификатор) IP-узла получателя сообщения, и только затем направить IP-пакет маршрутизатору. (Нормальный режим функционирования NAT-модуля заключается в преобразовании адресной информации и передаче IP-пакетов на другие интерфейсы, в то время как маршрутизаторы не передает IP-пакеты на те же интерфейсы, с которых они поступили на маршрутизатор.) NAT-модули не осуществляют фрагментацию пространства DNS-имен, но они упрощают процедуру объединения сетей, который обслуживаются администрациями с независимыми DNS-именами.

7.6. L2TP-туннели увеличивают вероятность адресных коллизий

Последний массовый рост Internet-сети был вызван размещением в W3-системе большого числа публикаций (электронные СМИ), которые требуют минимальных затрат. Другим стимулом расширения Internet-сети стало распространение так называемых виртуальных корпоративных сетей (Virtual Private Networks — VPN), которые, как правило, основаны на применении L2TP-протокола (Layer Two Tunneling Protocol — L2TP, RFC 2661). С технической точки зрения, VPN-туннели относятся к IP-инфраструктуре, так как канальный уровень Internet-архитектуры, отвечающий за мультплексирование (временное объединение) различных потоков IP-трафика, “позволяет” оконечным IP-узлам формировать, что вполне очевидно, сквозные маршруты. Эти VPN(L2TP)-туннели формируют видимость сетей и увеличивают увеличивают вероятность адресных коллизий*, когда на их пути функционирует несколько NAT-модулей. Управление IP-адресами в корпоративной сети, обслуживаемой NAT-модулем, станет весьма обременительным, так как не существует центрального функционального модуля, способного управлять, либо вообще нет ничего такого, чтобы делало это. Снижением такой нагрузки для Internet-провайдера будет реальная передача этой нагрузки на локальный (корпоративный) уровень, так как администрирование IP-адресов и DNS-имен становится распределенным и значит более сложным.

Рис.6. Пример совместного применения L2TP-туннеля и NAT-модулей

В соответствии со стандартом RFC 1918, слияние корпоративных адресных субпротсранств в одно может послечь за собой перекрытие эти субпространств, и тем самым создать функциональные проблемы. L2TP-туннели будут увеличивают вероятность и частоту такого перекрытия вследствие простоты их построения. Существует несколько вариантов настройки адресного пространства, которые могут повлечь за собой отказы в работе системы. На рис.6 представлен простой пример, когда IP-узлом “В” имеет корпоративный IP-адрес, который совпадает с корпоративным адресом VPN-сегмента, используемым IP-узлом “А” для входящих соединений. Когда IP-узел “В” пытается сформировать VPN-интерфейс, IP-узел “А” назначит ему IP-адрес из своего набора IP-адресов для входящих соединений и определит IP-узлу “В” шлюз (интерфейс) для использования. В представленном примере (рис.6), IP-узел “В” не способен различить IP-адрес удаленного VPN-интерфейса/шлюза IP-узла “А” от своего собственного корпоративного IP-адреса на физическом интерфейсе, и поэтому данное соединение потерпит провал. По определению, IP-адреса, используемые корпоративно, не связаны с IP-адресами общего пользования, что увеличивает структурную, топологическую и функциональную сложность VPN-сетей, и следовательно возрастает вероятность возникновение сбоев в работе системы, которые невозможно будет разрешить (то есть фатальные случаи).

7.7. Корреляция сообщений в системах централизованного сбора данных

Ранее сообщалось, что NAT-метод вносит дополнительные проблемы, когда системы обнаружения вторжений (Intrusion Detection System — IDS) пытаются скоррелировать сообщения между IDS-датчиками (синхронизировать работу IDS-датчиков), расположенными с внешней и с внутренней сторон относительно NAT-модулей. Несмотря на то, что рассмотрение функциональных особенностей конкретных систем диспетчерского управления не является целью данного стандарта, все равно очевидно, что в системах централизованного мониторинга, когда датчики текущего контроля систем расположены по обеим сторонам NAT-модулей, также необходим доступ к процедурам отображения IP-адресов, которые осуществляют NAT-модули, в целях обеспечения корректного функционирования таких систем. Это тоже весьма критично, когда данные о текущем состоянии системы снабжаются соответствующим идентификатором, так как возможна ситуация, при которой датчики с внешней стороны NAT-модулей используют IP-адреса, совпадающие с корпоративными IP-адресами.

Все сказанное выше в полной мере относиться к управлению технологическими данными, которые собираются на основе SNMP-протокола (Simple Network Management Protocol — SNMP, RFC 2274). Любой SNMP-трафик содержит IP-адреса, и поэтому центральный модуль сбора SNMP-данных или SNMP-ALG-субмодуль будут вынуждены обрабатывать SNMP-данные, основываясь на текущих преобразованиях, осуществляемых NAT-модулями.

VIII. IPv6-АДРЕСАЦИЯ

Бытует мнение, что IPv6-адресация больше не нужна, так как NAT-модули снимают ограничения на использование адресного пространства и позволяют Internet-сети продолжать свое развитие и расширение. Но реализм ситуации заключается в обратном, то есть именно NAT-модули указывают на необходимость использования IPv6-адресации, причем с большей очевидностью, чем когда бы то ни было. Люди, старающиеся соединить несколько компьютеров с помощью одной линии связи с системой Internet-провайдера, готовы отказаться от некоторой функциональности, чтобы обеспечить минимальные затраты при создании корпоративной сети. Очень часто, причиной роста затрат на создание и развитие корпоративной сети является ощущуение недостатка (порой, весьма большого) IPv4-адресов, который мог быть ликвидирован с помощью более широкого применения IPv6-адресации. Этот “кризис ума” порождает рынок решений проблемы, которая уже решена с помощью IPv6-адресации, являющейся весьма гибкой системой.

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

Но в то же самое время, NAT-метод, с функциональной точки зрения, может быть “рискованным посредником” в распространении IPv6-адресации. В сетях передачи данных несколько миллионов компьютеров используют IPv4-адресацию. Некоторые из этих сетей подключены к Internet-сети, и являются, таким образом, ее компонентами, а другие являются изолированными корпоративными сетями. Это просто невероятно, что мог быть “день флага”·, когда в одно и то же время все существующие IP-узлы, использующие IPv4-адресацию, перешли на применение IPv6-адресации. Временной интервал, в течении которого Internet-сеть и корпоративные сети будут одновременно использовать обе системы адресации, будет весьма длительным. Первоначальный план перехода на IPv6-адресацию жестко зависел от способности новых IPv6-узлов использовать систему IPv4-адресации (“dual stack” — IP-узлы со сдвоенной архитектурой). Когда IP-узел со сдвоенной архитектурой запрашивал другой IP-узел в DNS-системе, в ответном DNS-сообщении он получал, либо IPv4-адрес, либо IPv6-адрес. Если в ответном DNS-сообщении будет представлен IPv4-адрес, то тогда IP-узел будет использовать этот адрес для установления соединения с другим IP-узлом. А если в ответном DNS-сообщении будет представлен IPv6-адрес, то тогда этот адрес может быть использован для установления соединения. Включение NAT-модуля в состав программного обеспечения маршрутизатора с целью преобразования IPv6-адресации в IPv4-адресацию обеспечивает широкое распространение IPv6-адресации, несмотря на обслуживание маршрута с IPv4-адресацией, если IPv6-адресация не возможна. И несмотря на то, что в такой ситуации возникает несколько проблем, которые касаются IPv4-соединений, тем не менее NAT-модуль, преобразующий IPv6-адреса в IPv4-адреса и наоброт, фактически формирует “свозное соединение” для систем с IPv6-адресацией.