Egy hiba, három titok: melyik VPN-hitelesítő adat hiúsult meg?
A kliens minden szakaszhoz egyetlen hibát mutat. Olvassa el az asszociációt, a felhasználói cserét és a módszert, mielőtt olyan jelszót állít vissza, amelyet senki nem ellenőrzött.
Az „a hitelesítés sikertelen” utalhat szervertanúsítványra, a gép előre megosztott kulcsára vagy felhasználói jelszóra. Hogy melyikre, az a protokolltól függ, mert minden protokoll más titokkészletet határoz meg. Ha a rosszat állítja vissza, a hiba változatlan marad. A kiút az, hogy előbb tisztázza, hány bizonyítékot követel a protokoll, és csak azután szerkesszen bármit.
Két bizonyíték ellentétes irányban
Az alagútnak meg kell válaszolnia, hogy elérte-e a megfelelő átjárót, és külön azt, hogy ki a felhasználó. Az átjáró bizonyítéka gép szintű: szervertanúsítvány, előre megosztott kulcs vagy statikus nyilvános kulcs. A felhasználó bizonyítéka személy szintű: jelszó, token, kliens-tanúsítvány vagy semmi. Ezek a bizalom ellentétes irányai, és más anyagot használnak fel.
Az IKEv2 az átjáró bizonyítékát az IKE_AUTH belsejében végzi el, és ha EAP-t használnak, utána a felhasználói bizonyítékot külön cserében futtatja. A IKEv2 specifikáció külön szakaszként tartja ezeket, ami erős utalás arra, hol keressen, amikor egy üzenet mindkét kört lefedi.
A szakaszt olvassa, ne az üzenetet
A kliens egyetlen hibakarakterláncot mutat, bármelyik szakasz is hiúsult meg, így maga a lánc szinte semmilyen információt nem hordoz. Információt az az állapot hordoz, amelyet minden szakaszban megvizsgálhat: létezik-e asszociáció, elindult-e felhasználói csere, és felajánlotta-e a kliens azt a módszert, amelyet az átjáró akart. A táblázat így rendezi a szakaszokat, nem a protokoll neve szerint.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Csak a második sor szól olyan hitelesítő adatról, amelyet a felhasználó újra beírhat. A másik három konfigurációs tény, és éppen ez az eltérés az oka, hogy e jelentések közül oly sok olyan jelszó-visszaállítással végződik, amely semmit nem változtat. Mielőtt bármely mezőhöz nyúl, olvassa el a bizonyítékához illő sort.
Egy két titkos protokoll felfedi a lapjait
L2TP IPsec felett láthatóvá teszi a számot, mert a két ellenőrzés külön folyamatokban történik. Az IPsec-rétegnek előbb fel kell jönnie előre megosztott kulccsal vagy tanúsítvánnyal, és csak ezután próbál a benne lévő PPP felhasználói bejelentkezést.
Ha a gép titka rossz, nem jön létre asszociáció, és a felhasználói hitelesítő adat soha nem kerül kipróbálásra. Ha a gép titka jó és a felhasználó titka rossz, az asszociáció létezik, és a PPP elutasítja a bejelentkezést, miután az alagút már áll. Mindkettő ugyanazt az üzenetet adja a képernyőn, két különböző eseményből.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerAz üres asszociációs lista azonnal kizárja a felhasználói réteget, ezért azt a jelszó előtt ellenőrizze. A létrejött asszociáció ismétlődő PPP-hibákkal a másik irányba mutat, a felhasználói rétegre vagy a benne lévő hitelesítési protokollra. Egyik következtetés sem szerezhető meg a kliens hibaüzenetéből.
Mitől függ valójában a csak jelszavas belépés
A csak jelszavas hozzáférés szokásos az L2TP, a PPTP, az SSTP és az EAP-s IKEv2 esetében. A WireGuardnak egyáltalán nincs ilyen lehetősége, mert a partnerei kulcsok, nem felhasználók. Az OpenVPN esetében a válasz a szerver kliens-tanúsítvány követelményéből jön: az az átjáró, amely tanúsítványt és jelszót is követel, továbbra is elutasítja a csak jelszavas klienst, bármit írnak a mezőbe.
Hogy melyik összetevőre van szüksége, ugyanabból a válaszból következik. Az IKEv2 alatti jelszavas bejelentkezés EAP-t beszélő klienst igényel, míg a tanúsítványos bejelentkezéshez a kliens titkos kulcsa és a szerver lánca kell. Ha a rosszat telepíti, a hiba hitelesítő adatok hibájaként olvasható, pedig maga a hitelesítési módszer hiányzik.
Változtasson egy dolgot, majd teszteljen újra
Először három tényt rögzítsen: melyik protokoll fut, hány titkot határoz meg, és melyek tartoznak a géphez, nem a felhasználóhoz. A gépek az első szakaszban hiúsulnak meg, az emberek a másodikban, és a kettő összekeverése ez az egész probléma.
Ezután pontosan egy dolgot változtasson, és ugyanarról a kliensről teszteljen újra. Ez a fegyelem zavaró hibából olyan javítást csinál, amelyet le tud írni a következő embernek, és ez hasznosabb, mint egy működő kapcsolat, amelyet senki nem tud megmagyarázni.