Кратко

  • В draft-ietf-radext-radiusdtls-bis-18 работоспособность RadSec относится к конкретному соединению и следующему узлу. Прокси скрывает состояние последующих realm, домашних серверов и хранилищ учётных данных.
  • TLS/DTLS и Status-Server дают полезную локальную квитанцию. Для вывода о сервисе нужны отдельные данные о маршруте, владельце повтора, решении авторизации, действии NAS и наблюдаемом результате.

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

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

Раздел 3.8 редакции 18 задаёт точную процедуру. Реализация должна учитывать состояние TCP, TLS или DTLS вместе с watchdog прикладного уровня из RFC 3539. Соединение помечается down, когда сетевой стек считает его нежизнеспособным, когда D(TLS) не даёт пригодного соединения либо когда watchdog вынес такой вердикт.

Проверка выполняется по каждому соединению. Если одно из нескольких соединений к серверу перестало отвечать, остальные нельзя автоматически помечать down. Причиной может быть потерянное состояние одной DTLS-ассоциации или отдельный backend балансировщика.

Эта норма сдерживает blast radius. Но она же запрещает расширять успех: ответ одного соединения не является свидетельством для соседних соединений, всех realm и всех зависимостей за прокси.

RFC 5997 делает область Status-Server явной. Сервер или прокси RADIUS не должен пересылать такой пакет. Ответ приходит только от адреса и порта, которые проверялись. Запрос не направляется по realm из User-Name, поэтому из него нельзя вывести достижимость конкретного realm.

Непересылаемость устраняет одну неопределённость. Если обычный запрос молчит, а watchdog отвечает, первый прокси не следует объявлять мёртвым. Однако проверка не называет неисправную зависимость: таблицу маршрутов, последующий канал, домашний сервер или credential backend.

Редакция 18 требует, чтобы клиент RadSec поддерживал Status-Server, а сервер отвечал на него. Из-за всего 256 одновременных значений Identifier рекомендуется резервировать нулевое значение на каждом соединении. TCP keepalive и DTLS heartbeat могут раньше заметить обрыв транспорта. Они ускоряют ответ на вопрос о соединении, но не меняют сам вопрос.

Слишком широкая интерпретация рождает две противоположные аварии управления.

В первой timeout одного realm приводит к выводу всего прокси. Рабочие запросы других организаций уходят на резерв, там строятся новые соединения и растут очереди. Локальная потеря превращается в общую перегрузку. RFC 3539 объясняет исходное ограничение: клиент за прокси не имеет прямой транспортной связи с home server и не может по локальному каналу определить end-to-end таймер failover.

Во второй аварии автоматизация сохраняет неисправный маршрут, потому что watchdog остаётся зелёным. Наблюдение истинно, но получило чужие полномочия. Для решения по realm нужны запись выбора маршрута, квитанция отправки следующему узлу, ответ home server, состояние базы идентичности, авторизация и выполнение результата NAS.

Protocol-Error также ограничен одним hop. Он сообщает, что текущий узел не поддерживает пакет или не может его маршрутизировать, прекращает повтор на текущем соединении и позволяет выбрать другой сервер. Ответ не пересылается и ничего не утверждает о решении скрытого назначения.

Шифрование защищает свой участок, а не всю цепь. TLS или DTLS аутентифицирует соседнего участника RadSec и сохраняет конфиденциальность сегмента. Тем не менее промежуточный прокси может дальше отправить пакет по RADIUS/UDP. У начального клиента нет протокольного способа обязать всю цепочку использовать защищённый транспорт. Полная защита требует организационного контроля конфигурации каждого посредника.

На границе транспортов меняется владелец повтора. RADIUS/TCP и RADIUS/TLS полагаются на надёжный транспорт и не повторяют RADIUS-пакет в том же соединении. Для UDP и DTLS нужна прикладная ретрансляция. Получив пакет по ненадёжному каналу и передавая по надёжному, прокси не должен пересылать каждую входящую копию. В обратном направлении он сам отвечает за повторы на ненадёжном участке.

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

Accounting показывает, как размытая ответственность превращается в нагрузку. Документ рекомендует неизменный Event-Timestamp, обозначающий реальное время события. Его нельзя обновлять при повторе. Изменение Acct-Delay-Time создаёт новый пакет почти с теми же сведениями и, возможно, новый Identifier. На переходе TLS–UDP для каждой версии возникает самостоятельная downstream-ретрансляция.

В приложении A.2 одно событие появляется на сервере под ID 101, 102 и 103. Стабильное время помогает распознавать дубликаты, но не является глобальным transaction ID и не гарантирует обработку ровно один раз. Нужна связь между событием, пакетом, hop, владельцем таймера, решением сервера и конечной записью.

Даже ошибка Response Authenticator не всегда означает атаку. В приложении A.1 Identifier используется снова после timeout, а поздний ответ на старый запрос проверяется относительно нового. Проверка не проходит. Такой ответ отбрасывают, но соединение оставляют открытым. Гонка пакетов, отказ соединения и злонамеренный peer — разные выводы.

Редакция 18 размещена 30 сентября 2026 года как действующий Internet-Draft рабочей группы RADEXT. Намерение — Proposed Standard, срок действия — до 3 апреля 2027 года; номера RFC нет. Экспериментальные RFC 6614 и RFC 7360 будут заменены только после одобрения и публикации. Запись не доказывает внедрение, совместимость или инцидент в какой-либо названной сети.

Поэтому надёжное утверждение намеренно узкое: этот peer RadSec ответил в это время по этому соединению. Для вывода о сервисе добавляются realm, маршрут, downstream-сервер или база, авторизация, действие NAS и результат пользователя. Общая спецификация координирует соседей; работающий код каждой организации создаёт доказательства остального пути.

Источники