VPN в Windows не подключается? Сопоставьте код с журналом событий

Диалог VPN в Windows скрывает этап, на котором произошёл сбой. Прочитайте код результата, извлеките событие RasClient для этой попытки и измените только тот уровень, который сломался.

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

Текст диалога — последний шаг, а не причина

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

То, что ещё можно зафиксировать, — это сама попытка. Запишите имя подключения, тип туннеля, сохранённый в профиле — PPTP, L2TP/IPsec, SSTP или IKEv2 —, время с точностью до секунды и код. Если вы не уверены, какой протокол действительно работал, откройте %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk и прочитайте запись вместо того, чтобы полагаться на память; профиль, повторно использованный для нового протокола, сохраняет своё старое отображаемое имя.

Прочитайте число прежде, чем читать слова

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

809 — противоположный класс: ничего не вернулось. Это проблема пути — TCP 443 фильтруется для SSTP, GRE блокируется для PPTP, UDP 500 и 4500 или ESP отбрасываются для прохождения IPsec. Новый пароль этого не исправит, и новый сертификат тоже. 720 означает, что канал поднялся, а PPP так и не завершил согласование, что указывает на несовместимость протокола или сервер, который не смог выдать адрес. 789, или 13801 на IKEv2, — это идентичность внутри IPsec: сертификат, субъект которого не совпадает с набираемым именем, недоверенная цепочка или предварительно общий ключ, различающийся на двух концах.

Извлеките событие RasClient за ту же минуту

В Просмотре событий Windows Logs > Application, отфильтрованное по источнику RasClient, — первое место, куда стоит смотреть. Описание Microsoft ошибки 720 указывает на событие 20227 в этом журнале. Тот же поставщик выдаёт другие идентификаторы для других исходов, поэтому читайте сообщение и встроенный в него код результата, а не считайте ID диагнозом; общий диалог плюс 20227, несущий 720, — уже гораздо более узкая история.

Из PowerShell, не щёлкая в графическом интерфейсе:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

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

Постройте одну временную шкалу вместо груды событий

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

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

Для воспроизводимого снятия данных дозвонитесь из командной строки и дайте ей напечатать результат:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

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

Что каждый этап велит изменить

Называть этап полезно, только если это сужает набор изменений до одного уровня:

  • 691 — аутентификация: метод EAP, который предлагает клиент, против того, который принимает сервер, состояние учётной записи, срок действия пароля, разрешение на дозвон.
  • 812 — политика сервера: политика удалённого доступа или правило NPS, соответствующее этому пользователю и этому временному окну.
  • 809 — доступность: правила брандмауэра на пути, NAT и прохождение протокола, порт, необходимый выбранному типу туннеля.
  • 720 — согласование PPP: несовместимость протокола аутентификации, назначение адреса, параметр PPP на стороне сервера.
  • 789 / 13801 — идентичность IPsec: субъект сертификата против набираемого имени, цепочка доверия, предварительно общий ключ.

Измените что-то одно, проверьте тот же профиль снова и запишите новый код. Другой код после изменения — это прогресс, а не противоречие: вы сдвинули сбой на более поздний этап, и именно так выглядит исправление многоэтапного рукопожатия. Чего делать не следует — менять брандмауэр, сертификат и пароль за один заход, а потом приписывать заслугу тому, что было последним.

Делитесь доказательствами, а не окружением

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

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

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

Похожие статьи