Кратко

  • Operator-Name и непрозрачный Operator-NAS-Identifier из RFC 8559 помогают прокси вернуть CoA или Disconnect к исходному NAS. Это маршрутный контекст оператора, а не универсальный ключ абонентского сеанса.
  • Уже на NAS атрибуты могут выбрать ноль, один или несколько сеансов. ACK подтверждает атомарный переход выбранной совокупности, но бухгалтерский учёт и наблюдаемый трафик остаются другими уровнями.

Путь к правильному устройству — необходимое условие дистанционного управления, но не его завершение. На одном NAS могут одновременно находиться тысячи состояний, несколько операторских доменов и повторяющиеся пользовательские признаки. Доставка команды на этот адрес не говорит, какую строку состояния она изменит.

Именно здесь исходный RFC 5176 оставлял пробел. Он определил Disconnect-Request и CoA-Request, однако не стандартизировал достаточно данных, чтобы прокси надёжно восстановил обратный путь к NAS. RFC 8559 добавил Operator-Name и Operator-NAS-Identifier.

Непрозрачность защищает назначение идентификатора

Operator-NAS-Identifier формируется оператором и используется для поиска устройства на обратном пути. Его непрозрачность важна: посредник не должен выводить из значения чужую внутреннюю структуру или превращать его в идентификатор пользователя.

После доставки NAS всё равно сопоставляет User-Name, NAS-Port, Framed-IP-Address, Calling-Station-Id, Acct-Session-Id, Chargeable-User-Identity и другие разрешённые атрибуты. Результатом может быть отсутствие контекста, одна запись или множество.

Если совпадений нет, следует NAK. Если их несколько, запрос относится ко всем. NAS, неспособный выполнить множественный выбор, отвечает Error-Cause 508. Поэтому доказательство прокси заканчивается раньше доказательства точного воздействия.

Атомарность относится к выбранной совокупности

RFC 5176 требует считать атрибуты запроса обязательными. Для CoA все изменения должны успешно примениться ко всем совпавшим сеансам; только тогда отправляется CoA-ACK. Если хотя бы одно изменение невозможно, NAS отвечает NAK и не применяет ничего. Disconnect так же завершает либо все выбранные сеансы, либо ни одного.

Это предотвращает половинчатое состояние, но не исправляет чрезмерно широкий фильтр. Три ошибочно выбранных сеанса могут быть отключены атомарно и получить корректный ACK. Чтобы отличить это от точной команды, журнал должен хранить количество совпадений и идентификатор каждого сеанса до исполнения.

ACK — показание NAS, а не всей сети

Disconnect-ACK означает, что NAS заявляет об удалении связанного контекста и прекращении подключения выбранных сеансов. CoA-ACK заявляет об успешном изменении их авторизации. У ответа есть содержательная семантика исполнения.

Но учётные записи могут поступить позже, реплика политики — отстать, следующая точка принуждения — сохранить собственное состояние. Реальный трафик наблюдается другим датчиком. Эти расхождения не обесценивают ACK; они показывают, почему его нужно сопоставить с независимыми свидетельствами.

NAK также нельзя считать одним видом провала. При Authorize Only NAS, успешно начавший новый запрос авторизации, обязан вернуть CoA-NAK с Error-Cause 507, Request Initiated, а затем послать Access-Request. Итог задаст последующий Access-Accept или Access-Reject. Первый ответ подтверждает переход к следующему процессу.

Защищённый канал не создаёт полномочий

В историческом RADIUS/UDP источник выбирает общий секрет, а MD5-основанная конструкция аутентифицирует запрос. Event-Timestamp, повторная передача и обнаружение дубликатов решают отдельную задачу свежести. Но подлинный клиент одного провайдера не должен менять пользователей другого провайдера на общем NAS.

RFC 9765 обновляет транспорт до RADIUS/1.1 поверх согласованного TLS или DTLS. Защищённый канал заменяет прежнюю пакетную аутентификацию; Message-Authenticator не передаётся. Это укрепляет связь с узлом, но не отвечает, какие realm и сеансы находятся в его власти.

RFC 5176 получил статус Informational, поскольку известные уязвимости и смысловые неоднозначности уже развёрнутых реализаций нельзя было устранить без несовместимости. Из этого не следует, что ответам нельзя доверять. Следует требовать точного масштаба каждого утверждения: клиент сообщает намерение, прокси — маршрут, NAS — выбор и переход, учёт и трафик — последствия.

Такая архитектура не ищет единственный символ абсолютной истины. Она сохраняет минимальную спецификацию и делает проверяемым переход между локальными решениями.

Источники