Dlaczego PPTP i L2TP/IPsec zatrzymują się przed pytaniem o nazwę użytkownika?

Brak pytania o nazwę użytkownika to diagnostyczny prezent: PPP jeszcze się nie rozpoczął, więc konto, hasło i zasady domeny nie zostały jeszcze zapytane. W połączeniu PPTP lub L2TP/IPsec klient prosi o dane logowania dopiero wtedy, gdy tunel istnieje, a serwer rozpoczął sesję PPP. Wszystko, co może zawieść przed tym momentem, to transport, wymiana kluczy lub konfiguracja tunelu, czyli znacznie mniejszy obszar niż „VPN jest zepsuty”.

Brakujące pytanie zawęża błąd do trzech etapów

Zapisz ostatni etap, który widocznie się udał, bo każdy ma innego właściciela i inne rozwiązanie. Zgadywanie ustawień konta, gdy utknąłeś dwa etapy wcześniej, to sposób, w jaki znika popołudnie.

Klient, który kończy się przekroczeniem czasu bez pytania, nigdy nie dostał asocjacji IPsec, więc błąd leży w IKE albo w tym, czy twoje pakiety w ogóle docierają do bramy. Ten, który zgłasza weryfikację danych logowania, a potem spada, zaszedł dalej, niż sugeruje komunikat. Pytanie po którym następuje odrzucenie to uwierzytelnianie PPP, a to należy do artykułu o koncie, nie do tego.

Etap pierwszy: protokół, który zapora po cichu odrzuca

PPTP potrzebuje TCP 1723 dla kanału sterującego i protokołu IP 47 dla ścieżki danych, a oba podróżują osobno. Wiele sieci przepuszcza 1723 i odrzuca protokół 47, co daje tunel, który negocjuje, a potem nie przenosi zupełnie nic. Router wykonujący NAT potrzebuje też przepustu obsługującego GRE, a ścieżka dostępu tylko przez IPv6 nie może przenosić PPTP w żadnej konfiguracji.

L2TP przez IPsec zużywa port 500 na IKE i port 4500 na przejście przez NAT, a potem opakowuje sam ruch L2TP w 1701, podczas gdy ESP przenosi chroniony ładunek, gdy asocjacja już istnieje. Zezwól na dwa porty sterujące, ale nie na ESP, a otrzymasz dokładnie objaw z tytułu: widoczny postęp, potem martwy klient przed jakimkolwiek oknem danych logowania. Testowanie z hotspota telefonu to tani sposób oddzielenia problemu klienta od problemu ścieżki.

Etap drugi: klucz, który nie jest kluczem, propozycja, której się nie oferuje

Niezgodny klucz wstępnie współdzielony zawodzi szybko i cicho, a typowa wersja to klucz, który wygląda poprawnie na ekranie, ale zawiera wklejone złamanie wiersza albo spację na końcu. Na kliencie Linux okno dialogowe nie jest koniecznie źródłem prawdy: wtyczka L2TP NetworkManagera trzyma sekrety w plikach pod /etc/ipsec.d/, a starszy plik dla połączenia, który /etc/ipsec.secrets nadal dołącza, zostanie użyty zamiast tego, który właśnie wpisałeś. Skopiuj ten plik w bezpieczne miejsce, usuń go ze ścieżki dołączania, a potem wpisz klucz ponownie ręcznie.

Druga połowa tego etapu to propozycja. Obie strony muszą uzgodnić ten sam zestaw algorytmów fazy 1 — szyfrowanie, integralność i grupę Diffie-Hellmana — oraz pasujące transformacje ESP dla fazy 2, inaczej asocjacja w ogóle nie powstaje. Brama oferująca tylko 3DES, SHA1 i MODP1024 odrzuci klienta skonfigurowanego na mocniejsze algorytmy, a jej dziennik nazywa odrzuconą transformację. Dziennik nazywa niezgodność, jeśli go przeczytasz, zamiast po raz kolejny restartować usługę. Zamiast kopiować łańcuch algorytmów z wątku forum, zapytaj bramę, o jakie transformacje naprawdę będzie negocjować: ike-scan skierowany na jej adres zwraca transformacje, o które będzie negocjować. Jeśli jedyną ofertą jest kryptografia, której twoja polityka już nie pozwala, poprawka należy do bramy, a nie do obniżenia klienta.

W Windows klucz i metoda uwierzytelniania żyją w profilu VPN, a niezgodność pojawia się przed pytaniem o dane logowania, nie po nim. Gdy odbiorcą jest Windows Server, potwierdź, że rola dostępu zdalnego jest zainstalowana, że certyfikat odpowiada nazwie, z którą łączą się klienci, i że żaden filtr portów nie jest węższy niż powyższe protokoły.

Etap trzeci: tunel istnieje, a PPP nie startuje

Gdy IKE się zakończy, a pytanie nadal się nie pojawia, patrz na demona tunelu, a nie na zaporę. L2TP potrzebuje czegoś, co nasłuchuje na UDP 1701 — xl2tpd lub kl2tpd w Linuksie, usługi dostępu zdalnego w Windows — a zainstalowana, ale zatrzymana usługa wygląda z perspektywy klienta dokładnie jak odrzucony pakiet. Sprawdź nasłuch, zanim ponownie otworzysz reguły, które już zweryfikowałeś. Potem PPP musi wynegocjować, a pierwsza wymiana LCP to miejsce, w którym zwykle ląduje cicha porażka.

Jedna pułapka na tym etapie wcale nie jest awarią sieci: Windows pozwala na jedno połączenie danego typu VPN naraz, więc druga próba zwraca błąd 937, „inne połączenie tego typu jest w użyciu”. To reguła lokalna, a obejściem jest inne urządzenie, inny typ tunelu albo współdzielenie jedynego istniejącego połączenia.

Czytaj dziennik w kolejności etapów, zamiast zgadywać

Zatrzymaj klienta, uruchom go ponownie i czytaj komponenty w kolejności, w jakiej piszą dziennik. To znaczy najpierw demon IPsec — strongSwan lub Libreswan, a ipsec --version mówi który — potem demon L2TP, potem pppd. Którykolwiek komponent napisał ostatni przed awarią, oznacza etap do zbadania, bo wszystko, co w sekwencji przychodzi po nim, w ogóle nie działało.

Weryfikuj świeżym połączeniem, a nie zapisaną sesją, bo klient łączący się ponownie z pamięci podręcznej może pominąć części wymiany i odtworzyć nieaktualny wynik. Potwierdź osiągalność, wymianę kluczy, tunel i PPP po kolei, w tej kolejności. Wtedy brakujące pytanie przestaje być zagadką i staje się drugą linijką listy, przez którą naprawdę można przejść. Ta lista to także to, co przekazujesz zespołowi sieciowemu, od którego inaczej oczekiwano by sprawdzenia zapory z powodu usterki żyjącej w nieuruchomionym demonie.