Windows VPN-hibakódok: melyik szakasz hasalt meg, és mit naplózzunk

Nyissa meg a Windows VPN párbeszédpaneljét egy hiba után, és ad egy számot meg egy mondatot, amelyben a mondat általában a kevésbé hasznos fele. A szám megnevezi, melyik szakasz hibázott a kapcsolatban, a szakasz pedig meghatározza, melyik naplót, melyik beállítást és melyik csapatot nézze következőként. A szakaszok sorrendbeli végigjárása körülbelül tíz percet vesz igénybe, és megelőzi az ismert sorozatot: adapterek újratelepítése, protokollváltás és a verem visszaállítása egy olyan fiók javításához, amelynek soha nem engedélyezték a betárcsázást.

Olvassa a számot szakaszként

Egy natív kapcsolat négy mérföldkövön halad át. Eléri a kiszolgálót és összeköttetést létesít, egyeztet a biztonságról, hitelesíti a felhasználót, majd címzést és útválasztást alkalmaz. Mindegyiknél a hiba más bizonyítékot hagy, és az egyik szakaszhoz tartozó kód semmi hasznosat nem mond a többiről.

Az elkerülendő hiba, hogy a kódot súlyossági fokként kezeljük. Az összeköttetés hibája és az engedélyezés hibája egyaránt "nem sikerült csatlakozni" formában olvasható, és ezen kívül semmi közös nincs bennük. A súlyosság azt mondja meg, mennyire sürgős valami; a szakasz azt, mit nyisson meg.

Első szakasz: az összeköttetés és a tárcsázási kísérlet

829 azt jelenti, hogy az alatta lévő összeköttetés megszakadt. Nem mondja meg, hogy a távoli fél abbahagyta-e a válaszolást, egy köztes eszköz megölte-e a munkamenetet, vagy egy házirend bezárta-e az ügyfélen. Egy tárcsázás-befejezési kód, mint a 703, még korábbi: a kísérlet soha nem jutott el összeköttetésig, ami általában a profilra, a szolgáltatás állapotára vagy egy helyi házirendre utal.

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

Az eseménylekérdezés az a rész, amelyet az emberek kihagynak. Egy ügyféloldali bejegyzés időbélyeggel és interfésznévvel többet ér a párbeszédpanelnél, mert megmondja, hogy a kísérlet egyáltalán elhagyta-e a gépet. Nincs bejegyzés és nincs válasz a figyelőtől: ez elérhetőségi probléma, és semmilyen ügyfélmódosítás nem változtat rajta.

Ha ugyanaz a profil más hálózaton működik, álljon meg itt. A kód útvonalállapotot ír le, nem konfigurációs hibát, és a következő hasznos összehasonlítás a két rögzítés, nem egy újabb telepítés.

Második szakasz: PPP és a miniport kötése

720 az összeköttetés és a felhasználó között helyezkedik el. Az alagút feljött, majd a PPP réteg nem tudott címet vagy vezérlőprotokollt egyeztetni, ami gyakran kötési probléma az ügyfélen, nem elutasított hitelesítő adat. Ez a megkülönböztetés a kód teljes értéke: azt mondja, hogy a hitelesítő adatot soha nem érték el, tehát a fiók nem gyanúsított.

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

Ezt a két kimenetet olvasni tanulságosabb, mint bármit visszaállítani. Egy létező, de el nem indított miniport vagy egy másik szoftver által letiltott protokollkötés pontosan ennek a szakasznak a hibáját okozza. Mindkettő javítható a verem többi részének érintése nélkül. A teljes visszaállítás ezzel szemben olyan címzést és szűrőállapotot távolít el, amelynek semmi köze nem volt a hibához.

Harmadik szakasz: identitás és engedélyezés

691 azt jelenti, hogy a hitelesítő adatokat elutasították. 649 azt jelenti, hogy a fióknak nincs tárcsázási engedélye, a 812 pedig azt, hogy egy távoli hozzáférési házirend elutasította a kapcsolatot. Ezek döntések, nem szállítási hibák, és az ügyfél csak jelenteni tudja őket.

A bizonyíték a másik oldalon van. Kérje meg az átjáró üzemeltetőjét a kísérletre azon az időbélyegen és a hozzá illeszkedő házirendre; kérdezze meg a címtár tulajdonosát, hogy a fióknak van-e tárcsázási engedélye, és benne van-e a házirend által megkövetelt csoportban. Az alagút típusának megváltoztatása vagy az ügyfél újratelepítése nem változtathat meg egy identitásról hozott döntést.

Hasznos szokás ebben a szakaszban a pontos fiók-karakterlánc beírása a jegybe, bármilyen tartomány-előtaggal együtt. Meglepően sok 691-es eset a rossz tartományhoz mentett hitelesítő adat, és ez a fiók-karakterláncban látszik, nem a protokoll beállításaiban.

Negyedik szakasz: csatlakozva, és semmi sem működik

Egy kapcsolat befejeződhet és mégis hasznavehetetlen lehet. Van címe, az ügyfél sikert jelent, és az alkalmazás minden kérése időtúllépésbe fut. A párbeszédpanelen semmi sem tükrözi ezt, és nincs kód, amit megnézhetne. Ezen a ponton a párbeszédpanel véget ért, és a hasznos bizonyíték máshol van.

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

Ha hiányzik az útvonal, a kiszolgáló nem tolta be, vagy az ügyfél eldobta. Ha az útvonal létezik és a név meghiúsul, a feloldás a probléma. Ha mindkettő működik és az alkalmazás mégis meghiúsul, túl van az alagúton, és az alkalmazás saját konfigurációjában van.

Tartsa a változtatásokat egy rétegen tesztenként. Minden szerkesztés a következő kísérlet előtt a következő kód kontextusának része lesz, és az a kód, amely az utolsó szerkesztését írja le, rosszabb, mint a kód hiánya.

Egy kísérlet, egy változtatás, egy bejegyzés

Bármelyik szakaszról legyen szó, a bejegyzésnek tartalmaznia kell a kódot, az üzenetet, a profil nevét, az időbélyeget és a hálózatot, amelyen volt. Öt mező, és mindegyik már előtte van a párbeszédpanelen vagy az ügyfélnaplóban. Ez a készlet elég kicsi ahhoz, hogy beillessze egy jegybe, és elég konkrét ahhoz, hogy valaki más reprodukálja.

Ezután tegye azt az időbélyeget a másik oldali bejegyzés mellé. Az oldal tetejéhez közeli táblázat megmondja, melyik szakaszhoz tartozik az egyes eltérések. A második bejegyzés nélkül a kód csak szűkíti a keresést; vele a szakasz eldől. Az összehasonlítás az, ami a számot diagnózissá teszi, nem találgatássá.

Ez a szokás szinte minden natív Windows VPN-hibát lefed, és egyik ág sem igényel újratelepítést. A párbeszédpanel mindig megmondta, melyik van Önnél; a munka az, hogy megtagadjuk mindegyikük ugyanazon problémaként való kezelését.