Jeden błąd, trzy sekrety: które dane logowania VPN zawiodły?
Klient pokazuje jeden błąd dla każdego etapu. Przeczytaj skojarzenie, wymianę użytkownika i metodę, zanim zresetujesz hasło, którego nikt nie sprawdził.
„Uwierzytelnianie nie powiodło się” może wskazywać na certyfikat serwera, współdzielony klucz maszyny albo hasło użytkownika. Który z nich to znaczy, zależy od protokołu, ponieważ każdy protokół definiuje inny zestaw sekretów. Zresetuj niewłaściwy, a błąd pozostanie bez zmian. Wyjściem jest ustalenie, ilu dowodów wymaga protokół, zanim cokolwiek zmienisz.
Dwa dowody wskazujące w przeciwne strony
Tunel musi odpowiedzieć, czy dotarł do właściwej bramy, a osobno, kim jest użytkownik. Dowód bramy jest na poziomie maszyny: certyfikat serwera, współdzielony klucz albo statyczny klucz publiczny. Dowód użytkownika jest na poziomie osoby: hasło, token, certyfikat klienta albo nic. To przeciwne kierunki zaufania i zużywają różny materiał.
IKEv2 wykonuje dowód bramy wewnątrz IKE_AUTH, a gdy używany jest EAP, przeprowadza dowód użytkownika w osobnej wymianie później. Specyfikacja IKEv2 trzyma te części osobno, co jest mocną wskazówką, gdzie szukać, gdy jedna wiadomość obejmuje obie rundy.
Czytaj etap, nie komunikat
Klient pokazuje jeden ciąg błędu niezależnie od tego, który etap zawiódł, więc sam ciąg prawie nic nie wnosi. Informację niesie stan, który możesz sprawdzić na każdym etapie: czy istnieje skojarzenie, czy rozpoczęła się wymiana użytkownika i czy klient zaproponował metodę, której chciała brama. Tabela porządkuje etapy w ten sposób, a nie według nazwy protokołu.
| 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 |
Tylko drugi wiersz dotyczy danych, które użytkownik może wpisać ponownie. Pozostałe trzy to fakty konfiguracyjne i ta niezgodność jest powodem, dla którego wiele takich zgłoszeń kończy się resetem hasła, który niczego nie zmienia. Przeczytaj wiersz pasujący do twoich dowodów, zanim dotkniesz pola.
Protokół z dwoma sekretami pokazuje karty
L2TP przez IPsec czyni liczbę widoczną, ponieważ obie kontrole odbywają się w różnych procesach. Warstwa IPsec musi najpierw wstać ze współdzielonym kluczem lub certyfikatem, a dopiero potem PPP w jej wnętrzu próbuje logowania użytkownika.
Gdy sekret maszyny jest błędny, nie powstaje żadne skojarzenie i dane użytkownika nigdy nie są sprawdzane. Gdy sekret maszyny jest poprawny, a sekret użytkownika błędny, skojarzenie istnieje, a PPP odrzuca logowanie, gdy tunel już działa. Oba dają ten sam komunikat na ekranie, pochodzący z dwóch różnych zdarzeń.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerPusta lista skojarzeń natychmiast eliminuje warstwę użytkownika, więc sprawdź ją przed hasłem. Ustanowione skojarzenie z powtarzającymi się błędami PPP wskazuje w drugą stronę, na warstwę użytkownika albo na protokół uwierzytelniania w niej. Żadnego z tych wniosków nie da się wyciągnąć z tekstu błędu klienta.
Od czego naprawdę zależy dostęp tylko z hasłem
Dostęp tylko z hasłem jest zwyczajny dla L2TP, PPTP, SSTP i IKEv2 z EAP. WireGuard nie ma takiej opcji w ogóle, ponieważ jego peery to klucze, a nie użytkownicy. W OpenVPN odpowiedź wynika z wymogu certyfikatu klienta po stronie serwera: brama, która wymaga zarówno certyfikatu, jak i hasła, będzie odrzucać klienta z samym hasłem, cokolwiek wpiszesz w pole.
Który komponent jest potrzebny, wynika z tej samej odpowiedzi. Logowanie hasłem w IKEv2 wymaga klienta mówiącego EAP, natomiast logowanie certyfikatem potrzebuje klucza prywatnego klienta i łańcucha serwera. Zainstaluj niewłaściwy, a awaria wygląda jak błąd danych logowania, choć brakuje samej metody uwierzytelniania.
Zmień jedną rzecz, potem sprawdź ponownie
Najpierw ustal trzy fakty: który protokół działa, ile sekretów definiuje i które z nich należą do maszyny, a nie do użytkownika. Maszyny zawodzą na pierwszym etapie, a ludzie na drugim, i pomieszanie tych dwóch to cały ten problem.
Następnie zmień dokładnie jedną rzecz i sprawdź ponownie z tego samego klienta. Ta dyscyplina zamienia mylącą awarię w poprawkę, którą możesz opisać następnej osobie, co jest bardziej przydatne niż działające połączenie, którego nikt nie potrafi wyjaśnić.