VPN-hitelesítés sikertelen: ritkán a port vagy a DNS a hibás
Az elutasított bejelentkezés más hiba, mint az időtúllépés. Újrapróbálkozás előtt ellenőrizze a profilt, a hitelesítő adatok formátumát, a második tényezőt és a tanúsítványt.
A sikertelen hitelesítés azt jelenti, hogy a szolgáltatás kapott egy identitást és elutasította, ami szűkebb állítás annál, mint amit a legtöbben beleértenek. A port nyitva van, a TLS-munkamenet akár teljesen fel is épülhetett, és valami a hitelesítő adatokban vagy a fiókban elutasításra került. A hálózati beállítások módosítása ezt nem javítja, és a kísérlet ismétlése zárolhatja a fiókot. A hibaüzenet már megnevezi a szakaszt, ezért ott kezdje.
A hiba már megmondta, melyik szakasz hiúsult meg
Egy kapcsolat, amely soha nem fejezi be a TLS-kézfogást, egyáltalán nem érte el a hitelesítést. Egy kapcsolat, amely befejezi a kézfogást, majd hitelesítőadat-elutasítást jelent, elérte és ott hiúsult meg. Ez a két kimenet különböző vizsgálatot igényel, és gyakran összekeverik őket, mert mindkettő zárt ablakkal végződik.
OpenVPN egyértelművé teszi a különbséget a kiszolgáló AUTH_FAILED üzenetével, amely döntés, nem szállítási hiba. A TLS-tárgyalás időtúllépése vagy a tanúsítvány-ellenőrzési hiba a korábbi szakaszhoz tartozik. Olvassa el, melyik van Önnél, mielőtt a hitelesítő adatokhoz nyúl, mert a jelszó-visszaállítás nem javítja a kézfogást, a tűzfal módosítása pedig nem javítja az elutasított bejelentkezést. Az ügyfélnapló egyetlen sora megválaszolja a kérdést.
Ugyanez a logika érvényes arra a munkamenetre, amely csatlakozik, majd később megszakad. Az újrahitelesítés hibája a negyvenedik percben más hiba, mint az első bejelentkezés elutasítása, és az időköz a nyom.
Erősítse meg, hogy a profil a megfelelő szolgáltatásra mutat
A szolgáltató webhelyén használt fiók nem mindig az a fiók, amelyet a VPN-átjárója elfogad. Egy mentett profil régi átjáróra is mutathat jóval azután, hogy a szolgáltatás átköltözött.
Hasonlítsa össze a profil végpontját az üzemeltető által közzétettel, és ellenőrizze, melyik identitásrendszert kérdezi az átjáró. A webportálon végzett jelszó-visszaállítás semmit sem változtat, ha az alagút külön címtárral szemben hitelesít. Egy független nyilvános kiszolgáló hitelesítő adatai nem működnek az Önénél, és a munkahelyi jelszó kipróbálása egy nem megbízható üzenetben kapott profilban mindenképpen rossz üzlet. Mielőtt bármit begépel, erősítse meg az eredetet.
Két perc a profilon megelőzi a hitelesítő adatokkal való egy napos találgatást.
A bejelentkezési formátum a hitelesítő adatok része
A felhasználónévhez e-mail-forma, tartomány-előtag vagy címtár-utótag kellhet. Az átjáró a kapott karakterláncot hasonlítja össze, ezért a forma a hitelesítő adatok része, nem díszítés.
Ezután zárja ki az unalmas okokat, mielőtt eszkalál. Ellenőrizze a billentyűzetkiosztást, a másolásból bekerült záró szóközt és egy régi bejegyzést a jelszókezelőben. Visszaállítás után erősítse meg, hogy a VPN ugyanazt az identitásforrást használja, mint az az oldal, ahol a jelszó megváltozott. Ha ezek a részletek helyesek, hagyja abba a találgatást, és kérdezze meg az üzemeltetőt, hogy a fiók engedélyezett és jogosult-e VPN-hozzáférésre. Ez szolgáltatásoldali javítás, nem ügyfélbeállítás.
openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager
Az AUTH_FAILED-et tartalmazó naplósor általában okkódot vagy kihíváskarákterláncot tartalmaz. Segítségkéréskor másolja ki pontosan, ne fogalmazza át.
A második tényezőknek saját szerződésük van
A profil egyszeri kódot, interaktív kihívást vagy böngészős bejelentkezést várhat, amely tokent ad vissza az ügyfélnek. Használja az üzemeltető által támogatott folyamatot, ne találjon ki egyet.
Ne fűzzön kódot a jelszóhoz, hacsak ezt a formátumot kifejezetten nem írják elő, mert egyes telepítések külön mezőt, mások kihíváskaráterláncot használnak. Az időalapú kódoknál ellenőrizze az eszköz óráját, mert néhány perc eltérés minden kódot érvénytelenít. Ha a böngészős bejelentkezés sikerül, és az ügyfél soha nem folytatódik, jegyezze fel pontosan ezt a pontot, mert az átadást jelöli, nem a hitelesítő adatot. Egy újabb jelszó-visszaállítás valószínűleg nem segít.
A munkamenet-korlát a másik gyakori elutasítás. Ha a fiók egy munkamenetet enged, egy második bejelentkezés lezárhatja az elsőt, és a tünet hullámzó kapcsolatnak tűnik, nem szabályzatnak.
A tanúsítvány nem jelszó
Az ügyféltanúsítvány lejárhat vagy visszavonhatják, miközben a fiók jelszava teljesen helyes marad. A privátkulcs jelmondata megint harmadik titok, és fájlt véd, nem fiókot.
Olvassa el a hibát, mielőtt bármit lecserél, majd szerezze be a helyes cserét az ellenőrzött üzemeltetőtől. Eközben tartsa bekapcsolva a kiszolgáló identitásának ellenőrzését: egy független tanúsítvány elfogadása vagy valaki más privátkulcsának másolása nem javítás, hanem második incidens. Utána tesztelje az erőforrást, amelyre valóban szüksége van, mert az elérhetetlen szolgáltatással rendelkező csatlakozott alagút más vizsgálat témája. Jegyezze fel, melyik szakasz hiúsult meg, hogy a következő ember ne kezdje újra az egész folyamatot.
Ha a munkamenet létrejön és később meghiúsul, rögzítse az időközt és a közeli megújítási eseményeket. Ez a feljegyzés elválasztja a token élettartamának problémáját az első bejelentkezés hibájától, és ez a különbség az ötperces javítás és az egyhetes újrapróbálkozás között.