Кратко

  • Однобайтовый Identifier лишь помогает найти ожидающий запрос. Затем клиент проверяет Response Authenticator с помощью 16-байтового Request Authenticator именно этого запроса и общего секрета на данном переходе.
  • Неизменённый повтор тому же серверу сохраняет Identifier, Request Authenticator и исходный порт. Сервер распознаёт дубликат и возвращает кэшированный ответ без новой проверки; изменение атрибутов создаёт новый запрос.

256 значений получили короткий срок полномочий

Заголовок RADIUS начинается с Code, восьмибитного Identifier, Length, 16-байтового Authenticator и списка Attributes. При параллельных подключениях, потерях UDP, резервных серверах и многошаговых проверках 256 значений неизбежно используются снова.

Первый документ RADIUS, RFC 2058, вышел в январе 1997 года. В апреле его сменил RFC 2138, а RFC 2865 в 2000 году закрепил классическую схему. Identifier во всех случаях помогает сопоставлять запрос и ответ, но не становится вечным номером операции.

Для одного исходного адреса и UDP-порта клиент не должен повторно использовать значение, пока прежний запрос не получил корректный ответ или не истёк. RFC 5080 рекомендует выбирать наименее недавно использованный Identifier.

Число 54 означает не «пятьдесят четвёртая аутентификация», а текущий ожидающий запрос 54 в конкретном контексте. После закрытия запроса то же число получает новое содержание. Ограниченный срок заменяет невозможную глобальную уникальность.

Ответ зависел от материала исходного вопроса

В Access-Request поле Authenticator содержит 16-байтовый Request Authenticator. При новом Identifier он обязан меняться и должен быть непредсказуемым и уникальным на протяжении жизни общего секрета.

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

Access-Accept, Access-Reject и Access-Challenge копируют Identifier запроса. Их Response Authenticator вычисляется по Code, Identifier, Length, атрибутам ответа, Request Authenticator исходного запроса и общему секрету.

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

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

Повторная передача должна была остаться тем же запросом

Классический RADIUS использовал UDP, поскольку решение о доступе нужно за секунды. Надёжная доставка старых данных через несколько минут не полезна пользователю. Клиент хранит копию выше транспорта, ведёт таймер и может повторить пакет или обратиться к другому серверу.

При повторе неизменённых Attributes тому же серверу сохраняются Request Authenticator, Identifier и исходный порт. Второй датаграмм пытается ещё раз доставить тот же логический запрос.

Если изменился хотя бы один Attribute, нужны новые Identifier и Request Authenticator. Добавленный Event-Timestamp, новый ответ на пароль или другой запрошенный сервис меняют вопрос. Одинаковое имя пользователя не делает байты и решение прежними.

Так «та же попытка» становится наблюдаемым инвариантом, а не предположением оператора.

Кэш повторял результат, не побочный эффект

RFC 5080 требует обнаруживать дублирующиеся Access-Request и временно хранить выданные Access-Accept, Access-Reject или Access-Challenge. Если дубликат приходит после ответа, сервер повторно отправляет исходный ответ и не обрабатывает запрос ещё раз. Если первый экземпляр всё ещё выполняется, повтор молча отбрасывается.

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

Ключ кэша включает исходный адрес и порт, Identifier, принимающий сокет и Request Authenticator. Запись обычно хранится от пяти до тридцати секунд. Если первые четыре координаты совпадают, а 16-байтовое значение отличается, прежняя запись удаляется. Видимое число не имеет права скрыть новый запрос.

Кэш не делает решение бессрочным. Он лишь восстанавливает доставку в коротком окне возможных повторов.

Изменённый вопрос лишал старый ответ текущего статуса

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

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

Access-Challenge показывает границу в многошаговой беседе. Сервер возвращает State и просит дополнительный ответ. NAS создаёт новый Access-Request с новыми Identifier и Request Authenticator, переносит State и добавляет данные пользователя. State связывает раунды сессии, но не превращает их в одну транзакцию.

Резервные серверы всё ещё могут расходиться в данных и политике. Правило первого корректного ответа закрывает запрос у клиента, но не синхронизирует инфраструктуру. Это обязанность оператора.

Accept не создавал отсутствующую возможность

Если NAS не способен предоставить услугу, указанную в Access-Accept, RFC 2865 требует трактовать ответ как отказ. Пакет не создаёт несуществующий VLAN, маршрут, порт или поддержку протокола.

Исторический Response Authenticator показывает в своих пределах, что обладатель секрета данного перехода связал этот ответ с ожидающим запросом. Он не доказывает сам по себе личность человека, правильность политики, завершение учёта или фактическую передачу трафика.

Удалённое решение заканчивается там, где начинается локальная способность выполнить его.

Прокси завершал одно доказательство и создавал следующее

Прокси проверяет ответ удалённого сервера секретом нижнего перехода, удаляет последний добавленный им Proxy-State, восстанавливает Identifier, ожидаемый предыдущим клиентом, и вычисляет новый Response Authenticator с секретом верхнего перехода.

NAS не получает сквозную подпись домашнего сервера. Он получает подтверждение непосредственного RADIUS-соседа. Proxy-State возвращает пакет по цепочке и остаётся непрозрачным для тех, кто его не создавал, но не выдаёт доступ.

Запись «ID 54, Accept» почти ничего не сохраняет. Для интерпретации нужны переход, адреса, порты, сокет, интервал ожидания, защищённый отпечаток Request Authenticator, форма запроса, действие кэша, путь прокси и применённый эффект. Секреты и чувствительные учётные данные при этом нельзя помещать в обычный журнал.

Синхронные таймеры превращали восстановление в перегрузку

RFC 5080 описывает клиентов с фиксированной секундной или ещё меньшей задержкой без перегрузочного backoff. После сбоя питания тысячи NAS стартуют одновременно, одновременно достигают тайм-аута и одновременно повторяют запросы. Механизм надёжности перегружает службу во время восстановления.

Рекомендуемый алгоритм увеличивает интервал, добавляет jitter и ограничивает задержку, число попыток и общую длительность. Случайность jitter нужна для рассинхронизации и не обязана быть криптографической. Непредсказуемость Request Authenticator защищает от атак и требует другого качества. Общее слово «случайный» не оправдывает один слабый генератор.

При перегрузке сервер может предпочесть запросы с корректным State, чтобы закончить уже начатые беседы. Прокси может пропускать ответы раньше новых запросов. Это приоритет прогресса, а не привилегия пользователя.

Позднее TLS перенёс границу доверия

RFC 6614 в 2012 году поместил RADIUS в TLS/TCP, но сохранил внутри туннеля прежние MD5-операции и фиксированный секрет radsec. Транспорт защищал соединение, а историческая обработка пакетов продолжалась.

RFC 9765 в 2025 году определил RADIUS/1.1. Только после явного согласования через ALPN поверх TLS 1.3 или новее исчезают общий RADIUS-секрет и MD5. 16-байтовое поле становится непрозрачным Token и принимает функцию сопоставления прежнего Identifier.

Это граница с уже опубликованной статьёй о RADIUS/1.1, а не её повтор. Профиль не меняет RADIUS/UDP и не обновляет автоматически другие переходы прокси-цепи. Он подтверждает узкий принцип: даже когда подлинность обеспечивает транспорт, ответу нужен достаточно большой контекстный указатель на свой запрос.

История механизма не оправдывает MD5 сегодня

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

Устойчивый урок касается масштаба доказательства. Короткое имя работает, пока вместе с ним сохраняются область, время и составной контекст. Опасность возникает, когда архив оставляет восемь бит, но удаляет состояние, давшее им смысл.