Który etap VPN zawiódł: IPsec, sterowanie L2TP czy uwierzytelnianie PPP

Zmieniłeś hasło i nic się nie ruszyło, bo usterka nigdy nie była w PPP. L2TP/IPsec zgłasza jeden błąd połączenia dla pięciu zupełnie różnych przekazań, a każde przekazanie ma własną naprawę. Pracuj wstecz: znajdź ostatni udany etap i zmieniaj tylko to, co następuje po nim. Kolejność poniżej decyduje też, jakie dowody zbierzesz najpierw.

Odpowiedz na cztery pytania po kolei

Wymuś nową próbę, bo niektóre klienty pokazują poprzedni błąd, dopóki profil nie zostanie rozłączony i połączony ponownie. Potem odpowiedz: czy istniało stowarzyszenie bezpieczeństwa IPsec, czy pojawiły się połączenie sterujące L2TP i wywołanie, czy PPP doszło do rozstrzygnięcia uwierzytelniania i czy IPCP dał klientowi adres? Pierwsze nie to etap, który naprawiasz. Wszystko po nim jest niesprawdzone, więc odrzucona nazwa użytkownika niczego nie dowodzi, gdy stowarzyszenie nigdy nie istniało.

Przed porównaniem zsynchronizuj zegary po obu stronach. Ponowna próba, która wyczyściła IPsec i zawiodła na PPP, wygląda jak jedna usterka, gdy klient pokazuje tylko ostatni komunikat, a log serwera wciąż trzyma wcześniejszą próbę. Czytaj według znacznika czasu, nie według najgłośniejszej linii.

Gdy masz tylko zrzut ekranu użytkownika, oprzyj się na najtańszym podziale: zły klucz wstępnie współdzielony i xl2tpd, który nigdy nie odpowiada, dają ten sam tekst w oknie Windows, ale jeden wymaga sekretu zmienionego po obu stronach, a drugi uruchomionego demona lub reguły zapory na samym serwerze. Urządzenie pośrodku nie może odrzucić wewnętrznego 1701, gdy IPsec w trybie transportowym już go opakował, więc nie szukaj filtra ścieżki, którego nie ma.

Co naprawdę posiada każda warstwa

IPsec chroni pakiety między dwoma równorzędnymi; L2TP przenosi sesję PPP wewnątrz tej chronionej ścieżki, dlatego RFC 3193 określa tryb transportowy, a nie własny tunel. Etykieta klienta mówi L2TP, więc tunel i logowanie wydają się jednym mechanizmem. Nie są: połączenie sterujące L2TP uwierzytelnia końce tunelu tam, gdzie wdrożenie to włącza, a PPP osobno uwierzytelnia użytkownika przez CHAP, PAP lub MS-CHAPv2 zgodnie z polityką serwera.

Ten podział wyjaśnia dwa sekrety, które ludzie stale mylą. Klucz wstępnie współdzielony uwierzytelnia partnerów IPsec. Nazwa użytkownika i hasło identyfikują użytkownika wobec PPP. Ponowne wpisanie współdzielonego sekretu Windows na profilu uwierzytelnianym certyfikatami niczego nie zmienia na zawodnym etapie, a edycja hasła PPP nie może dostarczyć brakującego chronionego kanału. Ta sama powściągliwość dotyczy sprawdzenia tożsamości: nie wyłączaj tożsamości partnera ani walidacji certyfikatu, aby uzyskać tunel, bo wtedy łączy się ścieżka, nie partner.

Uwierzytelnianie też nie jest końcem PPP. Po zaakceptowaniu użytkownika IPCP negocjuje adres klienta oraz opcje DNS i WINS, które serwer chce wydać. Klient może przejść CHAP lub MS-CHAPv2 i nadal zostać bez adresu, co jest usterką wewnątrz PPP, a nie problemem routingu. Zwykły L2TP bez IPsec pozostaje ważny i niechroniony, więc udane połączenie nigdy nie dowodzi, że ruch jest chroniony; sprawdź, czego wymaga serwer, a nie etykietę klienta.

Zdecyduj na podstawie pierwszego brakującego etapu

Czytaj tabelę według pierwszego brakującego elementu, od lewej do prawej. Prawa kolumna to jedyna praca warta zachodu w tym momencie; wszystko na lewo od niej jest już dowiedzione, a ponowne testowanie wypala okno awarii bez dodawania informacji.

Trzy wiersze zasługują na ostrzeżenie. Wiersz 1701 to miejsce, gdzie zwykle lądują klienty Windows za NAT: stowarzyszenie się kończy, potem nic nie przychodzi, a przyczyną jest enkapsulacja, nie złe hasło. Wiersz IPCP to ten błędnie czytany jako problem trasy, bo Windows pakuje brakujący adres w błąd 720, a ikona w zasobniku mówi tylko, że połączenie nie powiodło się; ta usterka leży po uwierzytelnieniu i przed routingiem. Ostatni wiersz nie jest wcale usterką IPsec, choć ikona mówi rozłączono.

Polecenia, które rozdzielają warstwy

Na serwerze Linux z strongSwan swanctl --list-sas wylicza ustanowione stowarzyszenia z tożsamością partnera, a ipsec statusall obejmuje starsze hosty strongSwan i libreswan. Pod spodem ip xfrm state pokazuje rzeczywiste stowarzyszenia jądra, a ss -lunp | grep 1701 dowodzi, gdzie jest przypięty xl2tpd. Uruchom xl2tpd -D na pierwszym planie, aby zobaczyć połączenia sterujące i wywołania, i włącz debugowanie pppd w /etc/ppp/options.xl2tpd, aby zobaczyć oferowaną metodę i odpowiedź.

Gdy logi pokażą udane uwierzytelnienie, następne pytanie brzmi, czy IPCP się zakończył. Sprawdź, czy ip range w sekcji [lns default] pliku /etc/xl2tpd/xl2tpd.conf ma jeszcze wolne adresy i czy /etc/ppp/options.xl2tpd naprawdę zawiera ms-dns oraz ms-wins, jeśli klient ich oczekuje. Wyczerpana pula i brakująca opcja DNS wyglądają inaczej na przewodzie: pierwsza zostawia klienta bez adresu i z 720, druga daje adres, ale bez resolvera, więc nazwy zawodzą, podczas gdy ping do surowych adresów działa. Żadnego nie naprawia ponowne wpisanie hasła.

Na kliencie wtyczka L2TP NetworkManagera zapisuje rozmowę pppd w dzienniku, więc journalctl -u NetworkManager -b zwykle oddziela tunel w górę, uwierzytelnienie odrzucone od brak tunelu w ogóle. W Windows Get-VpnConnection raportuje rzeczywiste ustawienia uwierzytelniania profilu, a zdarzenia RasClient w sekcji Application Podglądu zdarzeń nazywają zawodny komponent. Gdy okno dialogowe jest zbyt niejasne, włącz netsh ras set tracing * enable.

Przechwyty wymagają jednej ostrożności. W trybie transportowym IPsec wewnętrzny UDP 1701 jest szyfrowany, więc przechwyt na interfejsie zewnętrznym pokazuje ESP lub UDP 4500 pod NAT-T i zupełnie żadnego L2TP. Brak 1701 w przechwycie jest oczekiwany i nie jest dowodem zablokowanego portu; obserwuj, czy liczniki ESP lub 4500 się poruszają.

NAT, MTU i trasy: gdzie stos cię zwodzi

NAT łamie założenia, zanim cokolwiek zostanie uwierzytelnione. ESP to własny protokół IP, więc urządzenie tłumaczące odrzuca go, jeśli partnerzy nie enkapsulują; właśnie to zapewnia UDP 4500. Na serwerze Windows, który sam stoi za routerem domowym lub bramą NAT w chmurze, etap IPsec zawodzi z błędem 789, dopóki AssumeUDPEncapsulationContextOnSendRule nie zostanie ustawione na 2 pod kluczem PolicyAgent i maszyna nie zostanie zrestartowana, a usterka pozostaje nieodróżnialna od zamkniętego portu. Klienty za NAT są łatwiejsze: przy publicznym adresie serwera NAT-T na UDP 4500 je przenosi i ta wartość nie bierze udziału.

Gdy PPP jest w górze, MTU z czarną dziurą imituje martwy tunel: małe pakiety przechodzą, uścisk TLS albo ładowanie strony wisi, a klient może nadal pokazywać połączono. Obniż MTU interfejsu lub zaciśnij MSS na bramie, zanim obwinisz serwer. Routing tunelu dzielonego to drugi oszust; podsieć wypchnięta z niewłaściwą maską zostawia tunel zdrowym, a jedną aplikację nieosiągalną. Prywatna nazwa hosta dodaje własny skok: jeśli zapytanie wychodzi przez lokalny resolver, nazwa nie zostaje rozwiązana, zanim zostanie przetestowana jakakolwiek trasa.

Lista kontrolna, zanim dotkniesz poświadczeń

Przejdź listę po kolei i zatrzymaj się na pierwszym zawodnym elemencie. Każdy krok jest tani, a każdy wyklucza całą klasę zmian.

1. Potwierdź, że stowarzyszenie istnieje po obu stronach, dopasowane po tożsamości partnera, a nie po etykiecie połączono.
2. Potwierdź, że UDP 1701 dociera do xl2tpd; stowarzyszenie bez wywołania to twoja usterka.
3. Przeczytaj wyrok PPP, a jeśli uwierzytelnił, wynik IPCP, zanim uznasz, że hasło jest złe.
4. Dopiero teraz wpisz poświadczenia ponownie w formacie oczekiwanym przez serwer, bo prefiks domeny zmienia konto.
5. Jeśli nadal zawodzi, przechwyć obie strony z wyrównanymi znacznikami czasu i porównaj etap po etapie.

Zatrzymanie na drugim kroku oznacza problem ścieżki lub enkapsulacji, i żadna zmiana hasła tego nie ruszy. Zatrzymanie na trzecim kroku oznacza, że log już nazywa metodę lub pulę adresów do naprawy. Tak czy inaczej następna zmiana jest taka, którą potrafisz uzasadnić, i przestajesz krążyć po ustawieniach, które nigdy nie brały udziału.