Кратко

  • NAT мог экономить глобально уникальные IPv4-адреса на границе сети, но приложения, использовавшие значения адресов, нуждались не только в переписывании IP-заголовка.
  • Историческое предупреждение RFC 2993 касалось того, кому доставалась оставшаяся работа: шлюзам приложений, согласованным обновлениям конечных узлов, локальному управлению именами и поддержке — а не только устройству на пути маршрутизатора.

Транслятор может выполнить заданную замену без ошибки, но приложение всё равно не подключится. Таблица трансляции не обязательно неисправна. Проблема возникает, когда один адрес обозначает узел внутри частной сети, снаружи превращается в другое значение, а в сообщениях приложения остаётся ещё одна копия исходного адреса.

Это противоречие было видно уже в предложении 1994 года. RFC 1631 предлагал Network Address Translation как поэтапный ответ на дефицит IPv4: конечные сети могли повторно использовать внутренние адреса, а пограничное устройство переводило только трафик, выходивший в глобальное адресное пространство. Документ признавал и цену такого решения. Сквозное значение IP-адреса ослабевало, а в сети появлялось дополнительное состояние. Если у площадки было несколько выходов, трансляторы должны были одинаково понимать таблицы соответствий. Это был практичный переходный мост, а не архитектура без издержек.

В ноябре 2000 года Tony Hain подвёл итоги шести лет растущего интереса к NAT и его распространения в RFC 2993. Вопрос уже состоял не только в том, может ли маршрутизатор заменить один адрес другим. Важно было, продолжит ли работать сервис, если адрес появится там, куда транслятор не заглядывает.

Ответ зависел от приложения. Простая связь двух узлов через один NAT могла быть сравнительно управляемой. Но одни протоколы помещали IP-адреса в полезную нагрузку, другие требовали неизменности заголовка для контрольных сумм, аутентификации или защиты. Транслятор, который анализирует только заголовок, не способен исправить все такие предположения. Шлюзы прикладного уровня (ALG) и прокси могли помочь, но каждый должен был понимать обслуживаемый протокол. Ранее в том же году RFC 2775 отметил похожую обязанность: с появлением нового приложения, зависящего от адресов, ALG или прокси тоже требовалось обновить.

«Прозрачность» стала условным обещанием. Если приложение не показывало преобразованный адрес и не зависело от него, пограничная функция могла оставаться незаметной. В противном случае обходное решение требовалось согласовать во всех местах, где работало приложение. RFC 2993 противопоставлял сравнительно простой случай двух узлов резервным путям через NAT и многоточечным приложениям, например совместной работе с документами. В документе сказано, что сложность координации геометрически растёт с числом конечных узлов. Формулы или измеренной кривой затрат RFC не приводит: речь идёт о масштабировании архитектуры, а не о результатах эксперимента.

Резервирование добавляло ещё одну зависимость от состояния. Два транслятора на альтернативных путях должны были одинаково трактовать соответствия для одного устройства. Если состояние соединения оставалось на первом пути, а трафик переходил на второй, там могло появиться другое соответствие. Возврат на исходный маршрут не обязательно восстанавливал прежний разговор. Значит, состояние не исчерпывалось адресом в пакете: имели значение и таблица транслятора, и его место на пути.

Издержки могли переходить между организациями. RFC 2993 отмечал, что NAT под управлением интернет-провайдера способен упростить часть поддержки со стороны провайдера, но увеличить объём локального управления адресами и именами. Это описанный в документе перенос нагрузки, а не измеренное доказательство всеобщего роста совокупных затрат. После слияния компаний локальному администратору могло потребоваться устранить дубли частных адресов, настроить разные ответы DNS для внутренней и внешней стороны или согласовать исправление приложения, ранее невидимое провайдеру.

Безопасность особенно ясно показала разницу между трансляцией и политикой доступа. RFC 2993 предупреждал, что NAT, особенно трансляция портов, может создавать впечатление защитного барьера, хотя в нём нет намеренного контроля доступа, присущего межсетевому экрану. В документе также разбирались проблемы совместимости с IPsec, поведением DNS и аутентификацией SNMPv3. Эти механизмы зависят от протокола и конфигурации; они не доказывают, что любой NAT нарушает работу любого средства защиты. Транслятор меняет данные, связанные с адресом, но сам по себе не решает, какой трафик разрешён.

Позднейшие документы сделали эту работу явнее, но не доказывают её исчезновения. В 2001 году RFC 3022 заменил RFC 1631 описанием традиционного NAT. В 2002 году RFC 3235 изложил рекомендации для разработчиков приложений, дружественных к NAT. Эти публикации не доказывают, что RFC 2993 вызвал какое-либо конкретное внедрение или что все программы следовали рекомендациям. Они показывают, как пограничная технология породила отдельную литературу по проектированию приложений.

Историческая ценность RFC 2993 — не в приговоре, что NAT всегда терпит неудачу. Документ отделяет экономию адресов на границе от работы по обеспечению совместимости выше сетевого уровня. Транслятор мог находиться на одном шлюзе, а исправление — требовать обновлений на множестве узлов, согласованного состояния на разных путях и локального управления именами. Сеть не устранила работу, а изменила того, кому приходилось её замечать и координировать.

Источники