Кратко

  • RFC 3489 выводила шесть категорий из трёх Binding-тестов, хотя каждый ответ зависел от сокета, сервера, назначения, адресного пространства и времени.
  • RFC 5389 сохранила наблюдение отображённого адреса, но перестала считать тип доказательством проходимости. Нужна проверка с настоящим узлом и возможность relay.

В 2003 году RFC 3489 предложила убедительное дерево решений. Тест I запрашивал обычный ответ и сравнивал локальный сокет с MAPPED-ADDRESS. Тест II требовал ответить с другого IP-адреса и порта. Тест III менял только порт. Повторный тест I к CHANGED-ADDRESS сравнивал отображения. Результат назывался открытым Интернетом, симметричным UDP-фильтром либо одним из четырёх типов NAT.

Наблюдения были действительными, но название выходило за их пределы. Опыт относился к одному локальному сокету, серверу и его альтернативному адресу, направлению через один или несколько трансляторов, адресному пространству и моменту. Сам RFC требовал при повторе сменить локальный адрес или порт: состояние первого опыта могло исказить второй. Измерение меняло измеряемую поверхность.

Метка стирала назначение. Отображение, устойчивое для сервера STUN, могло измениться для нужного peer. Фильтр пропускал один источник и отклонял другой. Цепочка NAT сжималась до поведения наиболее строгого элемента без указания конкретного устройства, правила или таймера. Отношение превращалось в якобы постоянное свойство коробки.

Адресное пространство тоже ограничивало вывод. Сервер вне общего пространства мог сообщить адрес, бесполезный для другого участника. Два узла за одним NAT могли не связаться через внешнее отображение. MAPPED-ADDRESS означал лишь: этот сервер увидел такой исходный транспортный кортеж в этом запросе. Он не обещал доступность для любого третьего лица.

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

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

Ретроспектива RFC 5389 была прямой: классический STUN недостаточно хорошо работал как полное решение. Адрес иногда подходил, иногда нет; протокол не мог предсказать или исправить отказ. Многие NAT не укладывались в категории. Пересмотр убрал старые атрибуты смены адреса из базы и сделал STUN инструментом определённых сценариев.

RFC 5780 разделила поведение отображения и фильтрации. ICE в RFC 8445 собирал кандидатов, создавал пары и проверял их между реальными участниками до выбора пути. TURN в RFC 8656 давал relay, когда прямой маршрут не работал. Операционный вопрос сменился: не «какой это NAT?», а «какая пара работает сейчас и какой резерв остаётся?»

Подход Хэн Лу объясняет исправление. Минимальная общая спецификация сохраняет малый инструмент, а сценарий локально выбирает серверы, время, аутентификацию и fallback. Разделение уровней не позволяет смешать создание сокета, ответ STUN, наблюдаемый адрес, peer-check, номинацию, обмен пакетами и успех приложения.

Классификация может кратко изложить доказательства. Она не должна стирать условия их получения. RFC 3489 назвала устройство; RFC 5389 вернула решение проверяемому пути.

Источники