Windows VPN не се свързва? Съпоставете кода с журнала на събитията

Диалогът на Windows VPN скрива етапа, който се е провалил. Прочетете кода на резултата, извадете събитието 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 за същата минута

В Event Viewer Windows Logs > Application, филтриран по източник RasClient, е първото място за гледане. Описанието на Microsoft за грешка 720 сочи към събитие 20227 в този журнал. Същият доставчик излъчва други идентификатори за други резултати, така че четете съобщението и вградения код на резултата, вместо да третирате ID като диагноза; общ диалог плюс 20227, носещ 720, вече е много по-тясна история.

От PowerShell, без да кликате през GUI:

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

Конзолата показва числото, което GUI крие зад приятелски текст, и пускането два пъти ви казва дали кодът е стабилен или периодичен.

Какво ви казва всеки етап да промените

Назоваването на етапа е полезно само ако свие набора от промени до един слой:

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

Променете едно от тях, тествайте отново същия профил и запишете новия код. Различен код след промяна е напредък, а не противоречие: преместили сте отказа на по-късен етап и точно така изглежда поправянето на многоетапно ръкостискане. Това, което не бива да правите, е да промените защитната стена, сертификата и паролата наведнъж и после да отдадете заслугата на последното.

Споделяйте доказателствата, не средата

Съобщенията за събития са по-богати, отколкото изглеждат. Те носят името на връзката, акаунта, често вътрешното име или адрес на шлюза, а понякога и отпечатък на сертификат. Пазете оригинала там, където му е мястото, и изградете отделно редактирано копие за всеки друг; преписването на времевата линия по памет губи точно детайлите, които я правят полезна.

Предаване, което ще бъде обработено, изисква пет полета: кодът, етапът, към който принадлежи, клиентът и типът тунел, времевият печат с неговата часова зона и дали шлюзът изобщо е видял заявката. Всичко останало е по избор. С тези пет следващият човек може да различи спор за идентификационни данни от спор за маршрутизация, без да повтаря разследването.

Преди да приключите нещо, повторете опита на същия профил и потвърдете къде попада кодът сега. Успехът го приключва; различен отказ означава, че първоначалният етап е поправен и следващият е в ръцете ви.

Подобни статии