A Windows VPN nem csatlakozik? Párosítsa a kódot az eseménynaplóval

Pénteken működött. Hétfőn ugyanaz a Windows-ügyfél egy párbeszédablakkal válaszol, amely szerint a kapcsolódási kísérlet meghiúsult, és az alatta lévő mondat az, amelyet már láttál egy tucat összefüggéstelen problémánál. Az a párbeszédablak egy lánc vége, nem a kezdete. A Windows elrejti azt a szakaszt, ahol a kísérlet valójában meghalt, és két apró bizonyíték nevezi meg: a numerikus eredménykód és egyetlen RasClient-esemény ugyanabból a percből. Íme a sorrend, amelyet használok — rögzítse a kísérletet, olvassa ki a kódot, hozza elő az eseményt, majd módosítson pontosan egy réteget.

A párbeszédablak szövege az utolsó lépés, nem az ok

Az a mondat, amelyet olvasol, azután választódik ki, hogy a kísérlet már lezajlott. A "A kapcsolatot a távoli számítógép bontotta meg, mielőtt a kapcsolat létrejött volna" akkor jelenik meg, amikor egy kiszolgáló a tárgyalás közepén leteszi a telefont, amikor az IPsec meghiúsult, mielőtt a felhasználóneved egyáltalán elküldésre került volna, és amikor egy házirend kerek perec elutasítja az alagutat. Három különböző felelős, egy mondat. Kezeld a megfogalmazást tünetosztályként, és ne engedd, hogy bármit is irányítson, amíg a kód egyet nem ért vele.

Amit még rögzíthetsz, az maga a kísérlet. Írd fel a kapcsolat nevét, a profilban tárolt alagút-típust — PPTP, L2TP/IPsec, SSTP vagy IKEv2 —, az időt másodpercre és a kódot. Ha nem vagy biztos benne, melyik protokoll futott valójában, nyisd meg a %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk fájlt, és olvasd el a bejegyzést ahelyett, hogy az emlékezetedre bíznád magad; az új protokollhoz újrahasznált profil megtartja a régi megjelenített nevét.

Olvasd el a számot, mielőtt a szavakat olvasnád

A kódok három szakaszba esnek, és a szakasz fontosabb a pontos megfogalmazásnál: egy elért és elutasított hitelesítési csere, egy kiszolgáló, amely soha nem válaszolt, vagy egy tárgyalás, amely a kapcsolat felállása után omlott össze. A 691 az első fajta — a hitelesítő adatok ellenőrzése lefutott és meghiúsult, akár rossz jelszó, akár zárolt vagy lejárt fiók, akár a kiszolgáló által nem elfogadott hitelesítési protokoll miatt. A 812 szintén elutasítás, de érvényes hitelesítő adatokkal: a távoli hozzáférési kiszolgálón lévő házirend ellened döntött. A Microsoft gondozza a kanonikus betárcsázós és VPN-kapcsolatok hibakódjainak listáját, és érdemes ott elolvasni a saját számodat, mielőtt az üzenet szövegében keresnél.

A 809 az ellenkező osztály: semmi nem jött vissza. Ez útvonalprobléma — a TCP 443 szűrve az SSTP-hez, a GRE blokkolva a PPTP-hez, az UDP 500 és 4500 vagy az ESP eldobva az IPsec-átjárás miatt. Új jelszó nem tudja megjavítani, és friss tanúsítvány sem. A 720 azt jelenti, hogy a kapcsolat felállt, és a PPP soha nem fejezte be a tárgyalást, ami protokoll-összeférhetetlenségre vagy olyan kiszolgálóra utal, amely nem tudott címet kiosztani. Az 789, vagy IKEv2 esetén a 13801, az IPsec-en belüli identitás: olyan tanúsítvány, amelynek tárgya nem egyezik a tárcsázott névvel, nem megbízható lánc, vagy a két vég között eltérő előre megosztott kulcs.

Hozd elő az ugyanahhoz a perchoz tartozó RasClient-eseményt

Az Eseménynapló-nézegetőben a Windows Logs > Application a(z) RasClient forrásra szűrve az első hely, ahol érdemes nézni. A Microsoft 720-as hibáról szóló írása az adott napló 20227 eseményére mutat. Ugyanaz a szolgáltató más azonosítókat bocsát ki más kimenetelekhez, ezért az üzenetet és a benne lévő eredménykódot olvasd, ne az azonosítót tekintsd a diagnózisnak; egy általános párbeszédablak plusz egy 720-at hordozó 20227 már sokkal szűkebb történet.

PowerShellből, anélkül hogy a GUI-n kattintanál:

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

Az üres eredmény informatív. Általában azt jelenti, hogy a tárcsázás soha nem jutott elég messzire ahhoz, hogy a RAS bármit is naplózzon, vagy hogy a meghiúsult szoftver egyáltalán nem az eredeti ügyfél — a harmadik féltől származó ügyfelek saját diagnosztikát tartanak, és gyakran semmit sem írnak az Application naplóba. Ellenőrizd a szállító naplóját, mielőtt arra jutnál, hogy az eseménynaplózás elromlott.

Építs egyetlen idővonalat eseményhalom helyett

Az újrapróbálkozási hurkok zajt termelnek. Öt automatikus újracsatlakozás eseményfürtöt hagy maga után, és a kísértés az, hogy egyetlen okkal rendelkező sorozatként olvasd őket. Ezek öt különálló kísérlet, és közülük csak néhány ért el kiszolgálót. Vegyél egy két-három perces ablakot, egy kapcsolatnevet, és minden eseményt a saját kódjával sorolj fel, mielőtt bármit is értelmeznél.

Utána kérdezd meg, hol állt meg a kísérlet. Amikor az átjáró vagy a hitelesítési háttér nem tart nyilvántartást arról az időbélyegről, az ügyfél soha nem érte el, és elérhetőségi problémát látsz. Amikor a háttér kérést és elutasítást mutat, a döntés ott született, és a hitelesítő adatok vagy a házirend osztálya érvényes. Hasonlítsd össze az órákat, mielőtt az időket összehasonlítanád: az ügyfelek helyi időt jelentenek, sok átjáró UTC-ben naplóz, és az eltérés egy tökéletesen korrelált párt összefüggéstelennek tüntet fel.

Ismételhető rögzítéshez tárcsázz a parancssorból, és hagyd, hogy kiírja az eredményt:

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

A konzol megmutatja azt a számot, amelyet a GUI barátságos szöveg mögé rejt, és a kétszeri futtatás megmondja, hogy a kód stabil vagy időszakos.

Mit mond az egyes szakasz, mit változtass

A szakasz megnevezése csak akkor hasznos, ha a változtatások halmazát egyetlen rétegre szűkíti:

• 691 — hitelesítés: az ügyfél által kínált EAP-módszer szemben azzal, amelyet a kiszolgáló elfogad, a fiók állapota, a jelszó lejárata, a betárcsázási engedély.
• 812 — kiszolgálóházirend: az a távoli hozzáférési házirend vagy NPS-szabály, amely ehhez a felhasználóhoz és ehhez az időablakhoz illeszkedik.
• 809 — elérhetőség: tűzfalszabályok az útvonalon, NAT és protokoll-átjárás, a kiválasztott alagút-típus által igényelt port.
• 720 — PPP-tárgyalás: hitelesítési protokoll összeférhetetlensége, címkiosztás, kiszolgálóoldali PPP-beállítás.
• 789 / 13801 — IPsec-identitás: a tanúsítvány tárgya szemben a tárcsázott névvel, megbízhatósági lánc, előre megosztott kulcs.

Változtass meg egyet ezek közül, teszteld újra ugyanazt a profilt, és írd fel az új kódot. A változtatás utáni más kód előrelépés, nem ellentmondás: későbbi szakaszba mozdítottad a hibát, és így néz ki egy többlépcsős kézfogás javítása. Amit nem szabad tenned, az az, hogy egy ülésben módosítod a tűzfalat, a tanúsítványt és a jelszót, majd annak tulajdonítod a sikert, amelyik utoljára jött.

A bizonyítékokat oszd meg, ne a környezetet

Az eseményüzenetek gazdagabbak, mint amilyennek látszanak. Hordozzák a kapcsolat nevét, a fiókot, gyakran az átjáró belső nevét vagy címét, és néha egy tanúsítvány ujjlenyomatát. Tartsd az eredetit ott, ahová való, és építs külön szerkesztett másolatot bárki másnak; az idővonal emlékezetből történő újragépelése éppen azokat a részleteket veszíti el, amelyek hasznossá teszik.

Egy ténylegesen feldolgozott átadásnak öt mezőre van szüksége: a kódra, arra a szakaszra, amelyhez tartozik, az ügyfélre és az alagút típusára, az időbélyegre az időzónájával, és arra, hogy az átjáró egyáltalán látta-e a kérést. Minden más opcionális. Ezekkel az öttel a következő ember meg tudja különböztetni a hitelesítő adatokról szóló vitát az útvonalválasztási vitától anélkül, hogy megismételné a vizsgálatot.

Mielőtt bármit lezárnál, játsszad újra a kísérletet ugyanazon a profilon, és erősítsd meg, hová esik most a kód. A siker lezárja; egy másfajta hiba azt jelenti, hogy az eredeti szakasz javítva van, és a következő a kezedben.