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

RFC-2993 ноябрь 2000 года

категория: информационный

ТРАНСЛЯТОР СЕТЕВЫХ IP-АДРЕСОВ С ТОЧКИ ЗРЕНИЯ

INTERNET-АРХИТЕКТУРЫ

(NAT)

I. ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

(Замечание. Необходимо отметить, что брандмауэры (или сетевые экраны, Firewall — FW) также нарушают принцип “сквозного соединения” и создают несколько точно таких же проблем, которые создают NAPT-модули, причем добавляют еще несколько собственных проблем. Но одно функциональное преимущество FW заключается в том, что они, как правило, встраиваются в сети с явной (очевидной) целью “вмешательства” в потоки трафика, и поэтому проблемы, связанные с функционированием брандмауэров, становятся более понятными или, по крайней мере, очевиидными, если конечно не возникают “непостижимые” проблемы.

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

II. ИСПОЛЬЗУЕМАЯ ТЕРМИНОЛОГИЯ*

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

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