Служба 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

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

Інструкція закінчується, коли три стани названо, режим відмови прочитано з робочої системи, повторні спроби мають одного власника, а аварійний доступ має власне затвердження й огляд. Передбачуване застосування плюс відомий шлях відновлення — це результат, вартий документування.