Служба MFA недоступна: решите вопрос доступа к VPN заранее

Доступ к VPN останавливается, и оповещение сообщает, что служба второго фактора недоступна. Может ли кто-то ещё подключиться — это вопрос политики, на который следовало ответить до сбоя, а не во время него. Недоступный проверяющий не является доказательством того, что фактор пройден, а отклонённый вызов — не то же событие, что недоступный. Инструкция ниже превращает это различие в письменное правило, которое можно проверить.

Шаг 1: назовите три исхода отдельно

Запишите три состояния и откажитесь их объединять: первичная аутентификация не удалась, вызов второго фактора отклонён или истёк, а служба MFA так и не ответила. У каждого свой владелец, своя строка в журнале и свой правильный ответ. Одно общее сообщение об истечении времени скрывает, в каком из них вы находитесь, и именно эта неопределённость превращает сбой в спор. Назовите состояния в инструкции до того, как они понадобятся.

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

Шаг 2: прочитайте режим отказа, который прокси действительно использует

Найдите параметр, управляющий поведением, когда служба недоступна, и прочитайте его из работающей конфигурации, а не из шаблона. В RADIUS-прокси Duo документированные значения failmode — это safe и secure, где safe разрешает попытку только при успешной первичной аутентификации, а secure отклоняет попытку в этом условии.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

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

Остановитесь, если никто не может сказать, какой режим активен. Остальная часть инструкции зависит от этого ответа.

Шаг 3: согласуйте повторные попытки с потоком

Согласуйте тайм-аут и поведение при повторных попытках шлюза с потоком аутентификации, которым он управляет. Нескоординированные повторные попытки создают несколько запросов, путают сопоставление попыток и оставляют журнал неспособным сказать, какой результат относится к какому входу. Очень долгий тайм-аут — не проект доступности; это более долгое ожидание того же ответа.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

Собственный тайм-аут запроса прокси — отдельная граница: запрос аутентификации, который выдан и никогда не завершён, отклоняется, и этот отказ не является сбоем, из которого отступают. Рассматривайте отказ, незавершённый вызов и недоступную службу как три разных входа в вашу таблицу решений. Затем сделайте таблицу явной: какое состояние допускает, какое удерживает и какое эскалируется к человеку.

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

Шаг 4: управляйте аварийным доступом отдельно

Если аварийный доступ необходим, дайте ему собственные рамки, идентичность, авторизацию и след аудита. Тихое отключение MFA для всех пользователей — не аварийная процедура; это постоянное ослабление с привязанным инцидентом. Владелец безопасности заранее утверждает правило допуска, видимость и путь эскалации.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

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

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