Один користувач не може увійти до VPN: упорядкована діагностика

Коли одна людина не може підключитися, а решта команди продовжує працювати, корисне питання не в тому, що зламалося, а в тому, який рівень не домовився. Вхід — це ланцюг: клієнт запускається, шлюз відповідає, ідентичність стверджується, другий фактор виконується, політика оцінюється, і лише потім іде трафік. Розрив будь-де в цьому ланцюгу доходить до вас однією й тією ж фразою від користувача, тому перше завдання — знайти ланку, яка справді відмовила.

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

Зафіксуйте етап і позначку часу

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

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

Прочитайте подію ідентичності для цієї єдиної спроби

Попросіть адміністратора витягти запис автентифікації, що відповідає записаній хвилині. У розгортанні Windows NPS посібник Microsoft з усунення несправностей NPS документує подію відмови 6273 разом із супутнім кодом причини, і це зазвичай відокремлює невідомого користувача, погані облікові дані, невідповідність політики та виклик, скинутий з не пов’язаної причини.

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

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

Змінюйте одну умову за раз, у межах політики

Спокуса — за один прохід перевстановити клієнт, скинути пароль і перенести ноутбук в іншу мережу. Це іноді усуває симптом і завжди знищує докази. Виберіть натомість одну дозволену заміну: та сама людина на другому зареєстрованому пристрої або схвалена тестова ідентичність на тому самому пристрої. Кожна заміна відповідає рівно на одне питання, тому успіх звужує несправність до того боку, який ви змінили, а не звинувачує VPN загалом.

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

Підтвердьте виправлення на початковому шляху

Коли пошкоджену ланку визначено, виправте лише її та повторіть початкову спробу: та сама людина, той самий пристрій, та сама мережа, той самий застосунок. Тестовий обліковий запис, що підключається з адміністративного VLAN, доводить, що шлюз живий, і нічого не доводить про ранок вівторка в користувача. Попросіть користувача виконати саме невдалу дію, а не простішу, бо успішний ping мало говорить про відхилений файловий ресурс.

Закрийте заявку тим, що було виключено і що змінилося. Ця нотатка — різниця між разовим порятунком і тим, що наступний черговий інженер зможе використати повторно.