Кратко

  • RFC 3539 требует считать, что дубликат AAA-транзакции может прийти по любому соединению. Альтернативная копия способна обогнать исходную, а отказ соединения не доказывает прекращение запроса.
  • При аутентификации, зависящей от состояния, один сервер может вернуть Accept, а другой — Reject для того же логического запроса. Идентичность дубликата, решение сервера, выбор клиента, применение NAS, accounting и результат пользователя требуют отдельных квитанций.

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

RFC 3539, опубликованный в июне 2003 года Proposed Standard Authentication, Authorization and Accounting (AAA) Transport Profile, фиксирует эту границу без привязки к конкретной аварии. Документ не доказывает сбой оператора или продукта. Он показывает, почему восстановленный транспорт ещё не является единственным решением авторизации.

Неисправное соединение не аннулирует посланную работу

Клиент AAA может поддерживать связи с несколькими агентами или серверами, используя основной и резервный путь либо балансировку. Он способен отправить транзакцию по альтернативному соединению до истечения периода, после которого пакеты старого пути гарантированно покинули сеть. Альтернативный экземпляр может прийти первым, исходный — позднее.

Поэтому RFC 3539 предписывает агентам и серверам быть готовыми к дубликатам и предполагать, что они возникают на любом соединении. Соединение описывает соседний транспортный контекст. Транзакция описывает намерение приложения. Новый socket не создаёт новое намерение; закрытие старого не отзывает уже доставленное.

Статус «primary down» не сообщает, успел ли сервер записать решение. Статус «secondary up» не исключает позднего ответа. Для расследования нужны отдельные моменты: подозрение peer, провал watchdog, replay очереди, commit каждого решения, приём ответа и применение на NAS.

Когда эти моменты сжимают в одно событие failover, доступность начинает говорить от имени транзакционной целостности.

Watchdog наблюдает ближайшего peer, а не весь сервис

RFC 3539 требует watchdog-сообщение на прикладном уровне, чтобы быстрее обнаруживать транспортный сбой или отказ прикладной функции peer. Механизм намеренно ограничен непосредственным соседом и не должен реагировать на проблемы нижележащих proxy или server. Это не heartbeat кластера.

Любой AAA Response от peer служит признаком его жизни. Отсутствие ответа на обычный запрос недостаточно для вывода о Down: задержка может находиться дальше. В описанном алгоритме основанием для перехода становится отсутствие ответа на специальный watchdog.

Ограничение сдерживает каскадную нестабильность, но одновременно ограничивает доказательство. Ответ watchdog не подтверждает доступность home realm, согласованность реплик, выполненную авторизацию, установку профиля на NAS или работающий доступ.

Таймер распределяет риск. Документ указывает 30 секунд как начальный default до jitter и допускает не менее шести секунд без jitter. Короткое значение повышает вероятность дубликатов, ложного failover и failback. Быстрое восстановление после настоящего отказа покупается меньшим терпением к просто медленному peer.

Это не универсальная оптимизация, а выбор владельца риска.

Pending queue знает только локальное отсутствие ответа

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

Запись pending означает: этот узел ещё не видел закрывающую квитанцию. Она не означает, что удалённый сервер ничего не сделал. Запрос мог пройти commit, а ответ задержаться. Он мог уйти за proxy, состояние которого локальная очередь не наблюдает.

Квитанция replay должна сохранить старого и нового peer, причину, поколение watchdog, точный snapshot очереди, сквозную идентичность, digest payload, retransmission flag и время обеих отправок. Одного retry=1 недостаточно, чтобы отличить точную копию от заново собранного сообщения.

RFC 6733 продолжает этот подход в Diameter Base Protocol: ожидающие запросы по возможности передаются альтернативному агенту с признаком retransmission, а failover может породить несколько идентичных запросов или ответов.

Hop-by-Hop и End-to-End отвечают на разные вопросы

Hop-by-Hop Identifier помогает сопоставить ответ с локальным ожидающим запросом. End-to-End Identifier вместе с Origin-Host позволяет обнаружить, что сообщения, прошедшие через разных агентов, относятся к одной логической работе.

Первая координата закрывает запись соседней очереди. Вторая объединяет копии намерения. Ни одна не является распределённой блокировкой, криптографическим доказательством происхождения, гарантией freshness или exactly-once.

После обнаружения дубликата нужен выбор действия: повторить сохранённый ответ, дождаться владельца решения, запретить повторную оценку или снова запустить policy. RFC 6733 говорит, что дубликат должен вызывать тот же ответ, кроме hop-specific деталей. Эта норма защищает логический запрос от второго произвольного решения.

Но для неё требуется долговечная память. Если первое решение не сохранено, cache истёк или состояние не дошло до второго сервера, общий ключ не создаёт отсутствующую истину. Detection, suppression, reconciliation и compensation остаются разными операциями.

Одинаковый запрос может встретить две разные эпохи

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

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

Клиент может получить Accept и Reject для одного дублированного запроса; RFC отмечает зависимость результата от порядка прихода. Так задержка превращается в скрытую политику. Размещение secondary, новый proxy или длина очереди способны изменить практическую авторизацию без изменения формальной policy.

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

Неприменённый ответ нельзя стирать

Если клиент хранит только итоговый Result-Code, он уничтожает свидетельство гонки. Для каждого ответа нужны сервер, сквозной ключ, state epoch, применённое ограничение, результат duplicate lookup, время commit и получения.

Слово «первый» требует точки наблюдения. Первым можно прочитать, проверить, записать, отправить на NAS или применить. В конкурентной системе эти порядки расходятся.

Квитанция выбора перечисляет все ответы, проверки, правило, победителя и судьбу остальных. Она отделяет транспортный replay от расхождения server state и от гонки enforcement.

Сохранение проигравшего ответа — не лишний шум. Без него двойное решение ретроспективно выглядит обычной успешной или отклонённой аутентификацией.

Accept ещё не является доступом

Accept фиксирует решение сервера. Клиент должен связать и проверить его, а NAS — установить атрибуты или профиль и изменить access state. Только наблюдение data plane показывает доступный сервис.

Reject также ограничен. Если другой Accept уже применён, поздний Reject не доказывает, что доступа никогда не было. Он может запустить закрытие, быть отброшен как duplicate или оставить конфликт.

Accounting создаёт отдельную поверхность. RFC 3539 называет Accounting Session-Id, Event-Timestamp и NAS identity для очистки повторных записей. Нужно сохранить disposition — отбросить, объединить, принять или компенсировать — и его влияние на аудит и начисления.

Полная цепь включает logical request, immediate-peer liveness, queue replay, каждое server decision, client selection, NAS enforcement, accounting disposition и user outcome. Владелец транспорта не подписывает policy; сервер не подписывает NAS; NAS не подписывает опыт пользователя.

Не подменять Diameter полями RADIUS

Классический RADIUS имеет собственные координаты: однобайтовый Identifier, Request Authenticator, транспортный контекст и shared secret участвуют в сопоставлении и повторной отправке. RFC 2865, RFC 2866 и RFC 5080 ограничивают этот механизм.

Это не прежние названия Hop-by-Hop Identifier, End-to-End Identifier и Origin-Host. Статья не повторяет историю идентичности RADIUS. Она рассматривает границу RFC 3539: копия через другое соединение может повторно вызвать зависимое от состояния решение.

Общий принцип только один: сохранить достаточно идентичности, чтобы replay оставался тем же намерением, и достаточно decision state, чтобы намерение не стало двумя эффектами.

Восемь квитанций вместо одного зелёного статуса

Квитанция запроса содержит origin, end-to-end key, неизменяемый digest, scope пользователя/сессии, приложение и время. Квитанция peer — generation соединения, последний ответ, watchdog, timer, jitter и failure classification.

Квитанция failover хранит обоих peer, snapshot очереди, retransmission marker и отправки. Каждый сервер сохраняет state epoch, правило, duplicate lookup, решение и commit. Клиент хранит все ответы и выбор. NAS — применённый профиль. Accounting — session identity, event time и disposition. Затем фиксируется реальный доступ или отказ.

Только после этого допустима фраза: «Этот immediate peer не ответил на этот watchdog; эти pending identities ушли к этому alternate; решения согласовали по этой норме; NAS применил этот ответ; наблюдались такие session и accounting». Отсутствующее звено остаётся неизвестным.

Граница доказательств

Статья не называет оператора, поставщика, AAA realm, внедрение RADIUS или Diameter, account, login, NAS, incident, outage, attack, двойное начисление или пользователя. Она не сообщает adoption, текущую конфигурацию, измеренную latency или фактическую частоту противоположных ответов.

RFC 3539 рассматривается как Proposed Standard июня 2003 года. RFC 3588 — исторический контекст, заменённый RFC 6733. RFC 6733 сохраняет failure и duplicate-механику, но не доказывает реализацию. RFC 8174 ограничивает нормативные слова, RFC 6298 даёт timer-контекст, не AAA-факт.

Работы Lu Heng о Running-Code Primacy и Minimum Initial Specification — раскрытая редакционная перспектива для разделения документа, реализации, локального решения и результата. Они не подтверждают намерение авторов RFC или поведение системы.

Узкий вывод: failover может скопировать запрос AAA до исчезновения оригинала. Общая идентичность делает копии узнаваемыми. Единственный эффект доказывают только идемпотентная disposition, явный selection, проверенный enforcement и наблюдаемый outcome.

Источники