Egy felhasználó nem tud bejelentkezni a VPN-be: rendezett diagnózis

Amikor egy ember nem tud csatlakozni, miközben a csapat többi tagja tovább dolgozik, a hasznos kérdés nem az, hogy mi tört el, hanem hogy melyik réteg nem értett egyet. A bejelentkezés lánc: a kliens elindul, az átjáró válaszol, egy identitás megerősítést nyer, egy második tényező teljesül, a szabályzat kiértékelődik, és csak ezután folyik a forgalom. A lánc bármely pontján keletkező szakadás ugyanazon mondatként érkezik meg hozzád a felhasználótól, ezért az első feladat annak a láncszemnek a megtalálása, amely valóban meghibásodott.

Kezelje a jelentést kiindulópontként, nem diagnózisként. Az alábbi ellenőrzések a legolcsóbbtól haladnak, és mindegyik úgy van megírva, hogy lezárja a vizsgálatot, ha megbukik.

Rögzítse a szakaszt és az időbélyeget

Írjon le négy dolgot, mielőtt bármilyen konfigurációhoz nyúl: a klienst és verzióját, a képernyőn látható pontos szöveget, a kísérlet percét és azt a hálózatot, amelyen a személy volt. A szöveg valódi információt hordoz, mert az elutasított hitelesítő adatok, a nem válaszoló átjáró és a befejezett bejelentkezés, amely még mindig nem tud megnyitni egy belső oldalt három különböző probléma három különböző felelőssel. Jegyezze fel, készített-e a kliens helyi naplósort, mert az a kliens, amely soha nem küldött csomagot, semmit nem tud hozzátenni a kiszolgálóoldali kereséshez. Az időbélyeg rögzítésével minden későbbi lekérdezés kereséssé válik, nem hajszává.

Ezen a ponton hagyja abba a jelszavak találgatását. Ahol a fióknak újrapróbálkozási korlátja van, a gyors próbálkozások sorozata zárolhatja, és egy második, mesterséges hibát tesz a valódi fölé. Jegyezze fel, hány próbálkozás történt már, hogy a zárolást később ne nézzék új tünetnek. A zárolt fiók azt is elveszi, hogy meg tudja különböztetni a rossz jelszót az elutasított szabályzattól, mivel mindkettő elutasításként érkezik.

Olvassa el az identitáseseményt ehhez az egyetlen kísérlethez

Kérje meg az adminisztrátort, hogy hozza elő a rögzített percnek megfelelő hitelesítési bejegyzést. Windows NPS-telepítésben a Microsoft NPS-hibaelhárítási útmutatója dokumentálja az 6273-as elutasítási eseményt a hozzá tartozó okkóddal együtt, ami általában elválasztja az ismeretlen felhasználót, a rossz hitelesítő adatokat, a szabályzat-eltérést és a független okból megszakadt hívást.

Az üres eredmény is információ. Ha semmi nem ért el az identitásszolgáltatáshoz, a kísérlet korábban halt meg: elavult átjárócím a profilban, egy figyelő, amelyet a kliens nem ér el, vagy egy gazdagép, amelyet kivontak az üzemből, miközben a profil tovább élt. Ha a bejegyzés létezik és sikert jelent, a hitelesítő adatok nem a probléma, és az érvelés az engedélyezésre vagy az átjáró mögötti útvonalválasztásra terelődik. Ez a két eredmény ellentétes irányba mutat, ezért a naplókeresésnek azelőtt kell megtörténnie, hogy bárki újratelepítene egy klienst.

Tartsa meg az okkódot a jegyben. Ez az egyetlen mező a következő előfordulást ötperces kereséssé teszi ismételt vizsgálat helyett. Párosítsa a kliensverzióval, mert az egyik buildben megjelenő kód más beszélgetés, mint a minden buildben megjelenő.

Egyszerre egy feltételt változtasson, a szabályzaton belül

A kísértés az, hogy egy menetben telepítse újra a klienst, állítsa vissza a jelszót és vigye a laptopot másik hálózatra. Ez néha megszünteti a tünetet, és mindig megsemmisíti a bizonyítékot. Válasszon helyette egyetlen engedélyezett cserét: ugyanazt a személyt egy második regisztrált eszközön, vagy egy jóváhagyott tesztidentitást ugyanazon az eszközön. Minden csere pontosan egy kérdésre válaszol, így a siker a hiba okát arra az oldalra szűkíti, amelyet megváltoztatott, ahelyett hogy az egész VPN-t hibáztatná.

Ne kérjen kölcsön kolléga hitelesítő adatait ehhez az összehasonlításhoz. Használjon tesztidentitást a támogatott folyamaton keresztül, és soha ne másoljon eszközkulcsot, és ne hagyja ki a regisztrációt azért, mert gyorsabb lenne. Ahol a szabályzat teljesen tiltja a cserét, az a korlátozás a vizsgált rendszer része, és a feljegyzésbe tartozik, nem egy megkerülő megoldásba.

Erősítse meg a javítást az eredeti útvonalon

Amikor a törött láncszemet azonosította, csak azt a láncszemet javítsa, és ismételje meg az eredeti kísérletet: ugyanaz a személy, ugyanaz az eszköz, ugyanaz a hálózat, ugyanaz az alkalmazás. Az admin VLAN-ból csatlakozó tesztfiók bizonyítja, hogy az átjáró él, és semmit nem bizonyít a felhasználó kedd reggeléről. Kérje meg a felhasználót, hogy a meghiúsult műveletet hajtsa végre, ne egy egyszerűbbet, mert egy sikeres ping keveset mond egy elutasított fájlmegosztásról.

Zárja le a jegyet azzal, mit zártak ki és mi változott. Ez a feljegyzés a különbség az egyszeri mentés és aközött, amit a következő ügyeletes mérnök újra felhasználhat.