Оглавление
- 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-модули, растет в геометрической прогрессии с ростом числа терминалов. В больших сетях, это может потребовать от конкретного прикладного процесса или службы обеспечения одновременного обновления данных во всех терминалах.