RFC 2993 — Транслятор сетевых IP-адресов (NAT) с точки зрения Internet-архитектуры

Оглавление

• 1. Введение
• 2. Используемая терминология
• 3. Область исследования
• 4. Модель «Сквозного соединения»
• 5. Преимущества NAT-модулей
• 6. Недостатки NAT-модулей
• 7. Пояснения
• 7.1. Точка отказа всей системы
• 7.2. Сложность ALG-субмодулей
• 7.3. Нарушение функциональных режимов ТСР-протокола
• 7.4. Управление состоянием симметричного соединения
• 7.5. Необходимость глобального полного DNS-имени при взаимодействии с прикладными службами общего пользования
• 7.6. L2TP-туннели увеличивают вероятность адресных коллизий
• 7.7. Корреляция сообщений в системах централизованного сбора данных
• 8. IPv6-адресация
• 9. Вопросы обеспечения безопасности
• 10. Правила распространения NAT-модулей в Internet-сети
• 11. Заключение
• 12. Литература

1. Введение

Опубликованный в мае 1994 года стандарт RFC-1631, разработанный Kjeld Borch Egevang и Paul Francis, ввел понятие транслятора сетевых адресов, который используется как средство преодоления проблемы уменьшение числа свободных IPv4-адресов. Но авторы этого стандарта не заботились о сущности этого способа. В своей публикации они указали несколько мест, когда потребуется экспериментальный анализ их способа и в дальнейшем необходимо проверить те прикладные службы, которые будут функционировать корректно после обработки заголовков сообщений NAT-модулями.

Теперь, по прошествии нескольких лет, применение NAT-модулей стало повсеместным в Internet. Более того, сейчас проводится работа по адаптации NAT-модулей к IPv6-адресации. Однако, в Internet-сообществе существуют две группы пользователей: стронники и противники применения NAT-модулей. Вот их аргументация:

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

• Противники смотрят на NAT-модули как на «вредную» технологию. Они ститают, что это «сорняк», который способен «задушить» дальнейшее прогрессивное развитие Internet. Даже понимая, что существует ярко выраженная нехватка IP-адресов, противники применения NAT-модулей рассматривают их как функционально не адекватный способ улучшения работы Internet-сетей, причем граничащий с обманом, который вводит в заблуждение пользователей по поводу упрощения доступа в Internet.

Истина лежит где-то между этими двумя крайне противоположными точками зрения.

В любом случае, очевидно, что NAT-метод нарушает принцип прозрачности сквозного (межтерминального) соединения при доставке IP-пакетов, основываясь на адресной информации в IP-заголовке, и при функционировании протоколов, которые транспортируют адресную информацию в других частях сообщений, отличных от IP-заголовка. Используя специализированные прикладные программные интерфейсы/шлюзы (Application Level Gateway — ALG), сетевые терминалы могут нормально взаимодействовать между собой, невзирая на имеющиеся функциональные проблемы NAT-модулей. Эти функциональные проблемы варьируются в зависимости от ряда факторов, среди которых сетевая топология, топология прикладной службы и использование специфических прикладных служб. С одной стороны, эти проблемы могут быть сравнительно легко преодолимы, когда речь идет о простейшей ситуации, например, когда трафик между двумя оконечными пользователями проходит через сеть, которая не имеет параллельных NAT-модулей. Но, с другой стороны, ситуация может резко усложниться, когда имеет место большое число, порой не нужных, параллельных NAT-модулей, или когда имеют место распределенные и многоузловые прикладные службы, функционирование которых напоминает распределение многостраничного документа. Сложность синхронизации и координации процедур обновления данных, что вызвано необходимостью обеспечения корректного «прохождения трафика» через NAT-модули, растет в геометрической прогрессии с ростом числа терминалов. В больших сетях, это может потребовать от конкретного прикладного процесса или службы обеспечения одновременного обновления данных во всех терминалах.

Архитектурный смысл NAT-модулей состоит в том, чтобы разделить всю Internet-сеть на независимые адресные зоны (административные зоны) и способствовать более упрощенному использованию специально выделенных и зарегистрированных (RFC-1918) диапазонов корпоративных (локальных) IP-адресов. Как было правильно указано в RFC-2101, как только в сети началось корпоративное (локальное) использование IP-адресов, то сразу после этого IP-адреса были обречены на неоднозначность и двусмысленность. Например, когда в сети размещены простые NAT-модули, то тогда процесс принятия решения относительно вида преобразования, то есть что и во что преобразовывать (преобразование DNS-имени в IP-адрес или преобразование IP-адреса в DNS-имя), становится зависимым от точки, где этот вопрос задается. В результате такого разграничения можно определить структуру «клиент/сервер» (в противном случае структуру «клиент/клиент») и в каких точках адресной сетевой зоны общего пользования необходимо размещать серверы.

Важным фактором нормального функционирования Internet-сети является ее гибкость, которая, в свою очередь, является следствием нескольких фундаментальных принципов:

1. И прежде всего, это принцип «сквозного соединения» (End-to-End Principle), который гласит, что сетевые терминалы (оконечные прикладные программные модули/процессы) могут выполнять только определенные функции, и в какой-то степени они осуществляют контроль соединения, а сеть должна быть просто службой доставки IP-пакетов (дейтаграмм), которая транслирует биты между этими сетевыми терминалами. Говоря другими словами, прикладные процессы (службы) в оконечных модулях очень часто являются теми единственными средствами, которые способны корректно управлять потоками данных. Освобождение программных модулей нижних уровней, отвечающих за доставку IP-пакетов, от не свойственной для них функции управления потоками данных, позволяет, тем самым, добиться упрощения процедуры доставки IP-пакетов и, следовательно, повысить общую эффективность функционирования системы.

2. Другим принципом является то, что сеть функционирует на основании информации о состоянии самой сети, то есть всех возможных соединений (а не только лишь одного соединения). Это позволяет быстро перенаправлять трафик по альтернативным маршрутам в обход неисправного сетевого сегмента и улучшать масштабирование всей сети в целом. Даже отсутствие данных о состоянии соединений также исключает какие-либо требования к сетевым узлам по информированию друг друга об установлении, наличии или прерывании связи между оконечными модулями. Более того, оконечные модули не знают (и не нужно им знать) о каких-либо сетевых компонентах, за исключением IP-узла назначения, первого маршрутизатора на пути следования трафика и, дополнительно, службы именования сетевых сегментов/областей. Целостность IP-пакетов сохраняется на всем пути их доставки по сети, а проверочные суммы транспортного уровня и какие-либо другие средства защиты данных, не зависящие от сетевых адресов, контролируются только в оконечных модулях.

NAT-модули (включая разновидности NAPT-модулей) нарушают эти базовые принципы, в часности, принцип сквозного соединения, снижая, тем самым, функциональную гибкость сети и увеличивая, во многих случаях, алгоритмическую сложность обработки трафика, а также затрудняя проведение диагностических процедур. Некоторые разновидности NAT-модулей, такие как RSIP-NAT-модули (Realm Specific IP), были предложены недавно и нацелены на снижение числа проблем, которые связанны с их функционированием. Однако, несмотря на то, что такие RSIP-NAT-модули могут обеспечить некоторое повышении эффективности при обслуживании корпоративного IP-узла с глобальным IP-адресом (если порты транспортного уровня доступны), тем не менее они не устраняют некоторые проблемы, в часности, связанные с сетевым управлением, управлением сеансов связи транспортного уровня (например, состояние ожидания/тайм-аута «TCP_TIME_WAIT», то есть в пассивном режиме функционирования), или проблемы, связанные с функционированием «хорошо известных» портов транспортного уровня. Каждый из этих «хорошо известных» портов имеет свои специфические (отличные от других) алгоритмы мультиплексирования данных, причем каждый из них также накладывает определенные ограничения при взаимодействии с DNS-системой, как и при функционировании NAPT-модулей. Каждая прикладная служба, имеющая свой «хорошо известный» порт, предъявляет определенные требования к составу протоколов и интерфейсов (архитектуре IP-узлов), обеспечивающих ее функционирование.

2. Используемая терминология

• NAT (Network Address Translation)

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

• ALG (Application Layer Gateway)

  Интерфейс (шлюз) прикладного уровня. Как правило представляет собой специализировнный программный субмодуль, который размещается между двумя взаимодействующими прикладными процесами с целью обеспечения между ними прямого соединения, когда некоторый «посторонний» протокол или программный модуль нарушает прямой доступ. ALG-субмодуль прерывает работу транспортного протокола и может изменять последовательность данных до того, как они будут переданы в канал связи.

• NAT/ALG

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

• DNS/ALG

  специализированная разновидность NAT/ALG-комплекса (DNS/ALG-субмодуль). DNS/ALG-субмодуль предназначен для обслуживания с DNS-системы и осуществляет преобразование содержания DNS-сообщений/запросов.

• Firewall

  брандмауэр (сетевой экран). Специально выделенное средство управления доступом. Этим средством может быть специализированная разновидность ALG-субмодуля или фильтр IP-пакетов.

• Proxy

  уполномоченный объект. Специализированный программный модуль-посредник, который встроен в соответствующий протокол и обеспечивает ретрансляцию сообщений этого протокола. В отличие от ALG-субмодуля, хотя бы один прикладной процесс должен знать о наличии Proxy-модуля.

• Static NAT

  статический NAT-модуль обеспечивает фиксированное взаимооднозначное отображение адресных пространств (одно в другое и наоборот).

• Dynamic NAT

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

• NAPT (Network Address Port Translation)

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

• RSIP (Realm Specific IP)

  метод назначения специфического IP-адреса внешней зоны, который позволяет конечным IP-узлам получать во «временное пользование» глобальный IP-адрес и номер порта транспортного уровня (адресный блок) у специализированного RSIP-сервера. Данный метод предусматривает ряд специализированных механизмов, которые позволяют корпоративному IP-узлу запрашивать несколько адресных блоков (адрес/порт) одновременно. RSIP-клиенты должны знать границы адресного пространства, принадлежащего их сетевой администрации. Эти границы определяют административную зону для корпоративных пользователей каждой прикладной службы, а топология этой административной зоны должна быть известна ее каждому корпоративному пользователю. При установлении соединения, RSIP-клиент запрашивает один или несколько IP-адресов и/или номеров портов транспортного уровня у соответствующего RSIP-сервера, а затем он инициирует сеанс связи через этот RSIP-сервер, используя для этого приобретенный(е) во «временное пользование» адресный(е) блок(и). IP-узлы должны иметь в своем составе специализированные программные RSIP-модули для реализации функции туннелирования трафика.

• VPN (Virtual Private Network)

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

• AH (IP Authentication Header)

  заголовок аутентификации (RFC-2401), который обеспечивает целостность данных, аутентификацию источника данных и, дополнительно, защиту от повторной передачи IP-пакетов.

• ESP (Encapsulating Security Payload)

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

• Address administration

  сетевая администрация, которой выделено определенное адресное пространство для идентификации некоторой совокупности маршрутизаторов и оконечных IP-узлов.

• Addressing realm

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

Большинство из предлагаемых здесь терминов и определений дано в стандарте RFC-2663.

3. Область исследования

При определении архитектурного смысла NAT-модулей в Internet, вопервых, необходимо определить саму Internet-сеть (ее границы), как область исследования. Наиболее общее определение Internet-сети следующее: объединение сетей, которое строится по технологиям и стандартам IETF (Internet Engineering Task Force). Это слишком обещее и простое определение не указывает различия между сетью общего пользования, известной как Internet, и корпоративными (частными) сетями, создаваемыми по таким же технологиям и стандартам IETF (включая их объединение с помощью NAT-метода). В стандарте RFC-1918 определено, что IP-узлы считаются IP-узлами общего пользования, когда им необходим доступ во внешнее сетевое пространство на сетевом (IP) уровне, используя для этого глобальный однозначный (недвусмысленный) IP-адрес. А те IP-узлы, которым необходим ограниченный или вообще не нужен доступ во внешнее сетевое пространство, именуются корпоративными. С другой стороны, это определение можно рассматривать с точки зрения прозрачности соединения между конкретным IP-узлом и остальной частью Internet-сети.

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

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

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

4. Модель «Сквозного соединения»

Концепция «сквозного соединения» представлена в стандарте RFC-2775 («Internet Transparency»). Одно из ключевых понятий этой концепции звучит следующим образом: «режим соединения между оконечными IP-узлами должен управляться только прикладными процессами (программными модулями), функционирующими в этих IP-узлах, и с этой точки зрения, соединение может быть прервано (нарушено) только тогда, когда один из оконечных процессов прервет себя сам»; по другому это можно назвать «процессы с роковым стечением обстоятельств». Одним из путей преодоления таких ситуаций является обеспечение отказоустойчивости (живучести) сети. Так как сети расширяются, вероятность прерывания соединения в следствие отказа одного из сетевых компонентов становится все больше и больше. Если такие сбои приводят к потере связи, так как нарушается соединение, то тогда сеть становится все более и более уязвимой, а ее значимость снижается. Однако, если оконечный прикладной процесс прерывает сам себя, то тогда вообще нет уверенности в том, что возможно установление последующих соединений. Более того, модель «сквозного соединения» доказывает, насколько это возможно, что только оконечные прикладные процессы должны поддерживать соединение в критических ситуциях.

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

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

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

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

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

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

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

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

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

5. Преимущества 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-узле, когда известно, что данные модифицируются на промежуточных этапах маршрута.

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

6. Недостатки 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-адреса (Maximum Segment Lifetime — максимальный интервал «времени жизни», стандарт RFC-793 определяет его равным две минуты). Если используются NAT-модули (с функцией трансляции номеров портов транспортного уровня), которые удовлетворяют требованиям состояния «TCP_TIME_WAIT», то тогда они должны просто воздерживаться от назначения одного и того же адресного блока (адрес/порт) пока не пройдет интервал времени, равный «2×MSL», с момента последнего использования этого адресного блока. Несмотря на то, что эти требования являются простыми для обслуживания соединения, они могут оказать серьезное функциональное давление на NAT-модуль, так как они временно сокращают диапазон доступных IP-адресов и номеров портов транспортного уровня. Соответственно, возникнет дилемма, либо разработчики NAT-модулей будут игнорировать требования состояния «TCP_TIME_WAIT», либо будут сокращены сами требования состояния «TCP_TIME_WAIT» в ущерб высокой надежности ТСР-протокола.

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

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

В частности, существует ошибочное мнение, что 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-игр, могут быть активизированы только в одной части системы на все время. Это также затронет системы для малого бизнеса, когда только одна система может быть задействована с использованием стандартного порта транспортного уровня на все время с целью обслуживания WWW-служб. Пока это выглядит как ограничения среднего уровня, но в связи с тем, что основные свойства и характеристики Internet-сети не изменяться в будущем, такие ограничения в дальнейшем крайне не желательны. Проблема также состоит в том, что перед установлением соединения, инициируемого из сети общего пользования в корпоративную сеть, требуется административное отображение адресного блока для каждого получателя. Если Internet-провайдер выберет стандартную версию этой процедуры с целью снижения дополнительных функциональных процедур настройки, то тогда ему понадобиться нести дополнительные затраты, связанные с управлением ALG-субмодулей, и которые могут превысить затраты, связанные с использование доплнительного адресного пространства.

7. Пояснения

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

Одной из характеристик дискретных динамических систем (объектов) с последействием, к которым относятся NAT-модули, является создание точки отказа всей системы.

Примечание. Система (объект) с последействием (stateful object) — это такая система, которая сохраняет свой состояние, явившееся результатом обработки одного или нескольких обращений к ней пользователей. С другой стороны существуют системы (объекты) без последействия (stateless object), которые не сохраняют свое состояние, явившееся результатом обработки одного или нескольких обращений к ней пользователей.

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

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

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

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

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

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

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

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

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

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

Все в этом рассмотренном примере будет работать, но до тех пор, пока прикладная служба не укажет (разместит) свое имя в DNS-системе. Например (рис.5), WWW-сервер, размещенный на 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-сети был вызван размещением в WWW-системе большого числа публикаций (электронные СМИ), которые требуют минимальных затрат. Другим стимулом расширения 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-имен становится распределенным и значит более сложным.

В соответствии со стандартом 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-модулями.

8. 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-адресации.

Примечание. «День флага» («flag day») — американский сленг, который означает срок внесения в систему изменений, исключающих возможность использования ранее эксплуатировавшихся программ.

Временной интервал, в течении которого 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-адресацией.

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

9. Вопросы обеспечения безопасности

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

IPsec-архитектура (RFC-2401) определяет несколько способов аутентификации на IP-уровне (на уровне IP-пакетов) и шифрования, которое используется в IP-сетях. Несмотря на то, что безопасность на сетевом уровне менее эффективна, чем на прикладном уровне, но говоря словами стандарта RFC-1752 «проведение аутентификации на сетевом уровне будет способствовать внедрению весьма необходимой, широкомасштабной инфраструктуры обеспечения безопасности для всей Internet-сети.»

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

• Применение АН-протокола невозможно, так как специальная хэш-функция защищает IP-адрес в заголовке IP-пакета.

• Аутентифицированные электронные сертификаты могут содержать IP-адрес в качестве элемента имени субъекта, который проходит процедуру аутентификации.

• При использовании шифрования в «Ускоренном режиме» информационного обмена в период формирования защищенного виртуального соединения отдельные сообщения могут содержать IP-адреса и номера портов транспортного уровня с целью определения выбранной стратегии обеспечения информационной безопасности.

• При использовании шифрования с открытыми ключами в период проведения информационного обмена в «Режиме модификации» отдельные сообщения будут содержать данные, удостоверяющие пользователей, в зашифрованном поле полезной нагрузки.

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

Как определено в стандарте RFC-2694, DNS-ALG-субмодуль способен обеспечить безопасность DNS-серверов в коропоративных сетевых сегментах. Внутризональные процедуры информационного обмена между DNSSEC-серверами, обеспечивающие необходимую модификацию данных в DNS-БД (база данных DNS-системы), потерпят провал. Это относится и к тем случаям, когда DNS-ALG-субмодуль «искажает» любые подписанные ответные DNS-сообщения, содержащие измененные DNS-данные. Например, это может быть случай, когда все DNS-запросы относительно объектов в сети общего пользования, направляются корпоративными IP-узлами, а DNS-сервер расположен внутри корпоративной сети. Все сказанное выше справедливо и в случае, когда все DNS-запросы относительно объектов корпоративной сети, направляются корпоративными IP-узлами, а DNS-сервер расположен в сети общего пользования. Любой DNS-ALG-субмодуль может только тогда модифицировать RR-записи с ЭЦП (подписанные DNS-данные), когда он имеет доступ к ключу, аутентифицированному источником DNS-данных. Группа DNSSEC-протоколов была специально разработана для того, чтобы исключить процедуру распределения этого ключа по сети, и для проведения процедуры аутентификации источника DNS-данных. Очевидно, что NAT-модули, которые используют DNS-ALG-субмодули для исправления DNS-имен объектов в DNS-запросах относительно IP-адресов, будут:

1. нарушать безопасность при изменении RR-записей в DNS-БД;

2. требовать доступа к ключам всех источников DNS-данных при получении на обработку DNS-запросов относительно IP-адресов.

Те способы обеспечения безопасности, которые не защищают или не транслируют IP-адреса в качестве идентификаторов (такие как TLS, SSL и SSH), могут функционировать в обслуживаемых NAT-модулями сетевых сегментах. Если прикладные службы способны формировать и использовать такого типа соединения, то тогда NAT-модули не будут создавать дополнительных проблем для их функционирования. Такие способы обеспечения безопасности не способны эффективно защитить все прикладные службы, так как IP-заголовок полностью открыт (не защищен), и они не запрещают проведение «губительных» управляющих процедур, подобных переходу на новый ТСР-сеанс связи.

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

10. Правила распространения NAT-модулей в Internet-сети

Учитывая, что NAT-модули продолжают распространяться в Internet-сети с довольно приличной скоростью, далее перечислены некоторые правила, которые по своей сути являются и предостерегающими, и рекомендательными:

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

• Определить настройку NAT-модуля: статическое или динамическое однозначное отображение IP-адресов. Если динамическое: убедиться, что TTL для ответных DNS-сообщений имеет значение «0», и что DNS-клиенты уделяют внимание тому, чтобы служебные DNS-сообщения не хранились в кэш-памяти.

• Определить разновидность используемого NAT-модуля: одиночный или параллельный (на несколько маршрутов). Если одиночный, то тогда учитывайте то, что NAT-модуль будет вносить сбои в работе системы. Если многомаршрутный, необходимо определить как настроить маршрутизаторы с обеих стороны NAT-модуля, чтобы поток IP-пакетов гарантированно проходил через один и тот же NAT-модуль в течении всех сеансов связи, инициированных прикладными службами (процессами).

• Проверить прикладные службы, которым необходим для пробразования IP-адресов NAT-модуль, и проверить их иммунитет к трансляции IP-адресов. Если необходимо, использовать ALG-субмодуль или сформировать VPN-интерфейс для изоляции прикладной службы от NAT-модуля.

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

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

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

• Определить маршрут следования DNS-сообщений (запросов и ответов на них). Если IP-узлы расположены с корпоративной стороны NAPT- или RSIP-модуля, и полагая, что DNS-серверы должны «видеть друг друга», то тогда может понадобиться дополнительный DNS-сервер в корпоративном сетевом сегменте.

• Если в DNS-системе используются защищенные RR-записи (DNS-данные), то тогда DNS-ALG-субмодуль должен иметь доступ к криптоключам аутентифицированного источника DNS-данных, если эти данные транслируются через NAT-модуль.

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

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

• Если используется RSIP-модуль, необходимо установить предельную границу для конкретной корпоративной сети, соединенной с Internet-сетью. Так как если на маршруте доставки IP-пакетов будут встречаться другие разновидности NAT-модулей (включая модули распределения загрузки WWW-серверов), то тогда RSIP-туннель (сквозное использование адресного блока — адрес/порт) будет нарушен.

• Если используется RSIP-модуль, необходимо определить вероятность сбоев, вызванных переходом ТСР-протокола в режим ожидания «TCP_TIME_WAIT», когда последующие корпоративные IP-узлы пытаются соединиться с только что завершившим сеанс связи IP-узлом в сети общего пользования.

11. Заключение

За время, прошедшее с момента опубликования стандарта RFC-1631, значительно вырос практический опыт функционального анализа NAT-модулей, который указывает на все большую обеспокоенность их применением у специалистов Internet-сообщества. NAT-метод нарушает фундаментальный принцип создания и развития всемирной Internet-сети: оконечные прикладные процессы управляют соединением. Другим принципом является «функциональная простота» («keep-it-simple»), который также нарушается, так как на сети возлагается дополнительная функциональная нагрузка по преодолению проблем, вызванных функционированием NAT-модулей. И в заключении, общая системная гибкость и управляемость снижаются, а затраты на поддержание сетевой функциональности растут, что связано с ростом проблем.

Сторонники и противники NAT-метода, соответственно, либо снижают, либо преувеличивают уровень проблематичности функционирования NAT-модулей:

• NAT-модули являются «сетевой реальностью» и будут распространяться, что способствует сохранению существующей сетевой IPv4-инфраструктуры.

• NAT-модули являются «порочной практикой» и создают дополнительную административную нагрузку, с которой весьма не легко справиться. Еще более важно, что они препятствуют распространению протоколов IPsec-архитектуры, а это, в свою очередь, замедляет рост прикладных служб, которые нуждаются в инфраструктуре безопасности.

В любом случае, применение NAT-модулей требует однозначного прикладного заключения относительно того, что работает, а что не работает.

На рис.7 представлена таблица функциональных преимуществ и недостатков NAT-модулей:

Преимущества NAT-модулей	Недостатки NAT-модулей
Скрывают изменения IP-адресов общего пользования.	Нарушают принцип (модель) «сквозного соединения».
Облегчают перенумерацию корпоративных IP-узлов при смене Internet-провайдера.	Улучшают связность нескольких протсранств DNS-имен
Избавляют сетевые администрации от юридической регистрации корпоративных IP-адресов.	Нарушают принципы IPsec-архитектуры.
Снижают размер необходимого адресного пространства.	Являются объектами с последействием, которые, в случае их отказа, приводят к отказу всей системы.
Снижают уровень функциональной нагрузки, возложенной на Internet-провайдеров.	Требуют специфических DNS-ответов на DNS-запросы или применение DNS-ALG-субмодуля.
В некоторых случаях обеспечивают прозрачность сквозного соединения.	DNS-ALG-субмодуль нарушает принципы обеспечения безопасности DNSSEC-протоколов.
Позволяют распределять нагрузку, подобно виртальным IP-узлам (распределенным многомашинным комплексам).	Увеличивают вероятность адресных коллизий при сквозном соединении.
Снижают остроту проблемы нехватки IPv4-адресов и потому тормозят переход к системе IPv6-адресации.	Увеличивают функциональную нагрузку на корпоративную сеть и ее функциональную сложность.
	Требуют специфических доработок в программном обеспечении каждой прикладной службы.
	Накладывают ограничения при масштабировании сетей.
	Могут усложнять интеграцию системы IPv6-адресации.
Рис.7. Таблица преимуществ и недостатков NAT-модулей

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

К средствам повышения уровня общей безопасности в Internet-сети относятся протоколы IPsec-архитектуры и DNSSEC-протоколы. Эти способы предназначены для обслуживания широкого круга прикладных и сетевых систем на основе аутентифкации и защиты передаваемой информации. Нарушая функционирование систем обеспечения безопасности, реализующих эти способы, путем искусственного включения NAT-модулей и DNS-ALG-субмодулей, проиходит «тороможение» дальнейшего распространения более надежных систем обеспечения безопасности по всей Internet-сети.

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

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

12. Литература

[1]	Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, Октябрь 1996.
[2]	Egevang, K. и P. Francis, «The IP Network Address Translator», RFC 1631, Май 1994.
[3]	Srisuresh, P. и M. Holdrege, «NAT Terminology and Considerations», RFC 2663, Август 1999.
[4]	Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. и E. Lear, «Распределение адресов в частных IP-сетях», RFC 1918, BCP 5, Февраль 1996.
[5]	Carpenter, B., Crowcroft, J. и Y. Rekhter, «IPv4 Address Behavior Today», RFC 2101, Февраль 1997.
[6]	M. Borella, D. Grabelsky, J., K. Tuniguchi, «Realm Specific IP: Protocol Specification», Work in Progress, Март 2000.
[7]	Kent, S. и R. Atkinson, «Security Architecture for IP», RFC 2401, Ноябрь 1998.
[8]	Carpenter, B., «Internet Transparency», RFC 2775, Февраль 2000.
[9]	Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. и J. Postel, «Internet Registry IP Allocation Guidelines», BCP 12, RFC 2050, Ноябрь 1996.
[10]	Postel, J., «Протокол TCP», RFC 793, STD 7, Сентябрь 1981.
[11]	Jacobson, V., Braden, R. и L. Zhang, «TCP Extension for High-Speed Paths», RFC 1185, Октябрь 1990.
[12]	Braden, R., «Требования к хостам Internet - Прикладные и служебные протоколы», RFC 1123, STD 3, Октябрь 1989.
[13]	Carpenter, B. и K. Moore, «Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels», Work in Progress.
[14]	Bradner, S. и A. Mankin, «Recommendation for IPng», RFC 1752, Январь 1995.
[15]	Srisuresh, P., Tsirtsis, G., Akkiraju, P. и A. Heffernan, «DNS extensions to NAT», RFC 2694, Сентябрь 1999.
[16]	Dierks, T. и C. Allen, «Протокол TLS», RFC 2246, Январь 1999.
[17]	http://home.netscape.com/eng/ssl3/ssl-toc.html, Март 1996.
[18]	Ylonen T. и Lonvick C., «Архитектура протокола SSH», RFC 4251, Январь 2006.
[19]	Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, Август 1998.