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

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

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

Зафиксируйте этап и отметку времени

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

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

Прочитайте событие идентичности для этой единственной попытки

Попросите администратора извлечь запись аутентификации, соответствующую записанной минуте. В развёртывании Windows NPS руководство Microsoft по устранению неполадок NPS документирует событие отказа 6273 вместе с сопровождающим его кодом причины, и это обычно разделяет неизвестного пользователя, плохие учётные данные, несоответствие политики и вызов, сброшенный по посторонней причине.

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

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

Меняйте одно условие за раз, в рамках политики

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

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

Подтвердите исправление на исходном пути

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

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