RFC: 2993
Оригинал: Architectural Implications of NAT
Категория: Информационный
Дата публикации:
Автор:
Перевод: Мельников Дмитрий Анатольевич

RFC 2993, Страница 14 из 29

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

Страница 14 из 29

2007 - 2022 © Русские переводы RFC, IETF, ISOC.