Summary

  • Рабочий проект RADEXT предлагает стандартизировать пакет RADIUS Protocol-Error с кодом 52. RFC 7930 ввёл его как эксперимент; реестр IANA пока ссылается на этот RFC.
  • Пакет должен содержать Error-Cause и Original-Packet-Code. Второй атрибут помогает найти нужный незавершённый запрос, когда разные типы запросов используют одинаковый Identifier.
  • Ошибка действует в пределах одного перехода. При причинах 502 и 505 прокси следует выбрать другое соединение либо адрес назначения; повторять запрос через только что отказавшее соединение запрещено.

Молчание сервера в RADIUS слишком долго выполняло роль универсального ответа. Сервер занят, пакет повреждён или следующий прокси потерял маршрут — для устройства доступа эти события могут выглядеть одинаково: таймер истёк.

Устройство применяет собственное правило повторной отправки. В аварии множество таких решений нагружает именно тот участок, который уже не справляется с запросами.

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

В 2016 году RFC 7930 зарегистрировал этот код экспериментально; новая редакция рабочей группы пытается определить его применение для разных операций RADIUS.

У сообщения есть два обязательных элемента. Error-Cause указывает причину. Original-Packet-Code сохраняет тип исходного запроса. Число Identifier может повторяться у запросов разных видов, поэтому одного числа для сопоставления мало. Ответ копирует Identifier исходного запроса; если исходный код не соответствует ни одному открытому запросу, клиент должен отбросить ответ. Точная диагностика, прикреплённая к чужой операции, способна запустить неверный повтор и объяснить пользователю несуществующее решение.

Сбой маршрута требует решения владельца маршрута

Раздел 4 ограничивает Protocol-Error одним переходом между соседями. Получив пакет, прокси не вправе механически переслать его дальше. Он читает Error-Cause и отделяет неисправность сети прокси от ответа домашнего сервера. Соединение с нижестоящим узлом принадлежит прокси; устройство доступа знает только о соединении с ним. В этой границе и находится ответственность за переключение.

Причины 502, Request Not Routable (Proxy), и 505, Other Proxy Processing Error, проект относит к сети прокси. Прокси следует попробовать другое соединение с тем же адресатом либо выбрать другого адресата. Отправлять исходный запрос снова по отказавшему соединению нельзя. Эта норма мешает выдать бессмысленную петлю пакетов за восстановление сервиса. Сколько запасных маршрутов проверять и сколько времени тратить, проект полностью не устанавливает; операторы должны определить пределы попыток сами.

Остальные причины обычно следует трактовать как сообщение домашнего сервера. Прокси формирует новый Protocol-Error своему клиенту, сохранив причину. Это уже его собственный ответ после проверки нижестоящего результата. Полная трасса должна связывать начальный запрос, ошибку следующего узла, выбор прокси и итоговый ответ устройству доступа. Сообщение о сбое обработки фиксирует сбой; подтверждение входа пользователя или записи учётного события требует итогового состояния соответствующей операции.

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

Проект RADEXT · Запись Datatracker · RFC 7930 · Реестр IANA