Кодове за грешки на VPN в Windows: кой етап е отказал и какво да логвате

Отворете диалога на VPN в Windows след отказ и той ви дава число и изречение, като изречението обикновено е по-малко полезната половина. Числото показва кой етап от връзката е отказал, а етапът определя кой лог, коя настройка и кой екип да гледате след това. Преминаването през етапите поред отнема около десет минути и предотвратява познатата последователност от преинсталиране на адаптери, смяна на протоколи и нулиране на стека, за да се поправи акаунт, на който никога не е било разрешено да се свързва.

Четете числото като етап

Собствената връзка преминава през четири етапа. Тя достига до сървъра и установява връзка, договаря сигурност, удостоверява потребителя и прилага адресиране и маршрутизация. Отказът при всеки от тях оставя различни доказателства, а код, който принадлежи на един етап, не ви казва нищо полезно за другите.

Грешката, която трябва да избягвате, е да третирате кода като степен на сериозност. Отказ на връзката и отказ на оторизацията и двата се четат като "неуспешно свързване" и нямат нищо общо отвъд това. Сериозността казва колко е спешно; етапът казва какво да отворите.

Етап първи: връзката и опитът за свързване

829 означава, че основната връзка е прекъснала. Не казва дали отдалеченият партньор е спрял да отговаря, дали междинно устройство е убило сесията, или политика на клиента я е затворила. Код за завършване на свързването като 703 е още по-ранен: опитът не е стигнал дори до връзка, което обикновено сочи към профила, състоянието на услугата или локална политика.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

Заявката за събития е частта, която хората пропускат. Запис от страна на клиента с времева марка и име на интерфейс струва повече от диалога, защото ви казва дали опитът въобще е напуснал машината. Липса на запис и липса на отговор от слушателя е проблем с достъпността и никакво редактиране на клиента не го променя.

Ако същият профил работи в друга мрежа, спрете тук. Кодът описва състояние на пътя, а не грешка в конфигурацията, и следващото полезно сравнение са двата записа, а не поредна преинсталация.

Етап втори: PPP и свързването на минипорта

720 стои между връзката и потребителя. Тунелът се вдигна и след това PPP слоят не успя да договори адрес или протокол за управление, което често е проблем със свързването на клиента, а не отхвърлени идентификационни данни. Това разграничение е цялата стойност на кода: казва, че идентификационните данни никога не са били достигнати, така че акаунтът не е заподозреният.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Четенето на тези два изхода е по-информативно от нулиране на каквото и да е. Минипорт, който присъства, но не е стартиран, или свързване на протокол, изключено от друг софтуер, дава точно отказа на този етап. И двете се поправят, без да се пипа останалата част от стека. Пълното нулиране, за разлика, премахва адресиране и състояние на филтриране, които не са имали нищо общо с дефекта.

Етап трети: идентичност и оторизация

691 означава, че идентификационните данни са отхвърлени. 649 означава, че на акаунта не е разрешено да се свързва, а 812 означава, че политика за отдалечен достъп е отказала връзката. Това са решения, а не транспортни дефекти, и клиентът може само да ги докладва.

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

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

Етап четвърти: свързано, и нищо не работи

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

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

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

Дръжте промените до един слой на тест. Всяка редакция преди следващия опит става част от контекста на следващия код, а код, който описва последната ви редакция, е по-лош от никакъв код.

Един опит, една промяна, един запис

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

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

Този навик покрива почти всеки собствен дефект на VPN в Windows и нито един от клоните не изисква преинсталиране на каквото и да е. Диалогът винаги ви е казвал кой от тях имате; работата е в отказа да ги третирате всички като един и същ проблем.