Která fáze VPN selhala: IPsec, řízení L2TP, nebo autentizace PPP

Změnili jste heslo a nic se nepohnulo, protože porucha nikdy nebyla v PPP. L2TP/IPsec hlásí jednu chybu připojení pro pět značně odlišných předání a každé předání má vlastní opravu. Postupujte obráceně: najděte poslední fázi, která uspěla, a měňte jen to, co přichází po ní. Pořadí níže také rozhoduje, které důkazy shromáždíte první.

Odpovězte na čtyři otázky v pořadí

Vynuťte nový pokus, protože některé klienty zobrazují předchozí chybu, dokud se profil neodpojí a znovu nepřipojí. Pak odpovězte: existovalo přidružení zabezpečení IPsec, objevilo se řídicí spojení L2TP a volání, dospělo PPP k verdiktu autentizace a přidělil IPCP klientovi adresu? První ne je fáze, kterou opravujete. Vše po ní je neotestované, takže odmítnuté uživatelské jméno nic nedokazuje, když přidružení nikdy neexistovalo.

Před porovnáním srovnejte hodiny na obou koncích. Opakování, které vyčistilo IPsec a selhalo na PPP, vypadá jako jediná porucha, když klient ukazuje jen poslední zprávu a serverový log stále drží předchozí pokus. Čtěte podle časové značky, ne podle nejhlasitějšího řádku.

Když máte jen snímek obrazovky od uživatele, opřete se o nejlevnější dělení: špatný předem sdílený klíč a xl2tpd, které nikdy neodpovídá, dávají v dialogu Windows stejný text, ale jedno vyžaduje tajemství změněné na obou koncích a druhé spuštěný démon nebo pravidlo firewallu na samotném serveru. Zařízení uprostřed nemůže zahodit vnitřní 1701, jakmile ho IPsec v transportním režimu obalil, takže nehledejte filtr cesty, který tam není.

Co každá vrstva skutečně vlastní

IPsec chrání pakety mezi dvěma protějšky; L2TP nese relaci PPP uvnitř této chráněné cesty, a proto RFC 3193 předepisuje transportní režim místo vlastního tunelu. Štítek klienta říká L2TP, takže tunel a přihlášení vypadají jako jeden mechanismus. Nejsou: řídicí spojení L2TP autentizuje koncové body tunelu tam, kde to nasazení zapne, a PPP odděleně autentizuje uživatele pomocí CHAP, PAP nebo MS-CHAPv2 podle politiky serveru.

Toto rozdělení vysvětluje dvě tajemství, která si lidé stále pletou. Předem sdílený klíč autentizuje protějšky IPsec. Uživatelské jméno a heslo identifikují uživatele vůči PPP. Opětovné zadání sdíleného tajemství Windows do profilu, který se autentizuje certifikáty, nic nemění v selhávající fázi a úprava hesla PPP nemůže dodat chybějící chráněný kanál. Stejná zdrženlivost platí pro kontrolu identity: nevypínejte identitu protějšku ani ověřování certifikátu, abyste získali tunel, protože pak se připojuje cesta, ne protějšek.

Ani autentizace není konec PPP. Poté, co je uživatel přijat, IPCP vyjednává adresu klienta a volby DNS a WINS, které je server ochoten vydat. Klient může projít CHAP nebo MS-CHAPv2 a přesto skončit bez adresy, což je porucha uvnitř PPP, ne problém směrování. Prostý L2TP bez IPsec zůstává platný a nechráněný, takže úspěšné připojení nikdy nedokazuje, že provoz je chráněn; kontrolujte, co vyžaduje server, ne štítek klienta.

Rozhodujte podle první chybějící fáze

Čtěte tabulku podle prvního chybějícího prvku, zleva doprava. Pravý sloupec je jediná práce, která v tu chvíli stojí za to; vše nalevo od něj je už prokázáno a opětovné testování spálí okno výpadku, aniž by přidalo informaci.

Tři řádky si zaslouží varování. Řádek 1701 je místo, kde obvykle končí klienti Windows za NAT: přidružení se dokončí, pak nic nedorazí a příčinou je zapouzdření, ne špatné heslo. Řádek IPCP je ten, který se mylně čte jako problém trasy, protože Windows zabalí chybějící adresu do chyby 720 a ikona v oznamovací oblasti jen řekne, že připojení selhalo; tato porucha leží po autentizaci a před směrováním. Poslední řádek není vůbec porucha IPsec, i když ikona říká odpojeno.

Příkazy, které oddělují vrstvy

Na linuxovém serveru se strongSwan swanctl --list-sas vypisuje navázaná přidružení s identitou protějšku a ipsec statusall pokrývá starší hostitele strongSwan a libreswan. Pod tím ip xfrm state ukazuje skutečná přidružení jádra, zatímco ss -lunp | grep 1701 dokazuje, kam je xl2tpd připojeno. Spusťte xl2tpd -D na popředí, abyste viděli řídicí spojení a volání, a zapněte ladění pppd v /etc/ppp/options.xl2tpd, abyste viděli nabízenou metodu a odpověď.

Jakmile logy ukážou úspěšnou autentizaci, další otázkou je, zda IPCP dokončil. Zkontrolujte, že ip range v sekci [lns default] souboru /etc/xl2tpd/xl2tpd.conf má ještě volné adresy a že /etc/ppp/options.xl2tpd skutečně nese ms-dns a ms-wins, pokud je klient očekává. Vyčerpaný fond a chybějící volba DNS vypadají na drátu různě: první nechá klienta bez adresy a s 720, druhé dá adresu, ale žádný resolver, takže jména selhávají, zatímco ping na holé adresy funguje. Ani jedno se neopraví opětovným zadáním hesla.

Na klientu plugin L2TP v NetworkManageru zapisuje konverzaci pppd do žurnálu, takže journalctl -u NetworkManager -b obvykle oddělí tunel nahoře, autentizace odmítnuta od žádný tunel. Ve Windows Get-VpnConnection hlásí skutečné nastavení autentizace profilu a události RasClient v části Application v Event Vieweru pojmenují selhávající komponentu. Když je dialog příliš vágní, zapněte netsh ras set tracing * enable.

Snímky vyžadují jedno upozornění. Při IPsec v transportním režimu je vnitřní UDP 1701 šifrované, takže snímek na vnějším rozhraní ukazuje ESP, nebo UDP 4500 pod NAT-T, a vůbec žádné L2TP. Chybějící 1701 ve snímku je očekávané a není důkazem blokovaného portu; sledujte, zda se počítadla ESP nebo 4500 hýbou.

NAT, MTU a trasy: kde vás zásobník mate

NAT boří předpoklady dřív, než je cokoli autentizováno. ESP je vlastní IP protokol, takže překládající zařízení ho zahodí, pokud protějšky nezapouzdří; přesně to poskytuje UDP 4500. Na serveru Windows, který sám stojí za domácím routerem nebo cloudovou bránou NAT, fáze IPsec selhává s chybou 789, dokud se AssumeUDPEncapsulationContextOnSendRule nenastaví na 2 pod klíčem PolicyAgent a stroj se nerestartuje, a porucha zůstává nerozeznatelná od zavřeného portu. Klienti za NAT jsou snazší: s veřejnou adresou na serveru je nese NAT-T na UDP 4500 a ta hodnota do hry nevstupuje.

Jakmile PPP běží, MTU s černou dírou napodobuje mrtvý tunel: malé pakety procházejí, TLS handshake nebo načtení stránky visí a klient může stále ukazovat připojeno. Snižte MTU rozhraní nebo sevřete MSS na bráně, než obviníte server. Směrování rozděleného tunelu je druhý podvodník; podsíť poslaná s nesprávnou maskou nechá tunel zdravý a jednu aplikaci nedostupnou. Privátní název hostitele přidává vlastní krok: pokud dotaz odejde přes místní resolver, název se nerozliší dřív, než se otestuje jakákoli trasa.

Kontrolní seznam, než sáhnete na přihlašovací údaje

Projděte seznam v pořadí a zastavte se u první selhávající položky. Každý krok je levný a každý vylučuje celou třídu úprav.

1. Potvrďte, že přidružení existuje na obou koncích, spárované podle identity protějšku, ne podle štítku připojeno.
2. Potvrďte, že UDP 1701 dosáhne na xl2tpd; přidružení bez volání je vaše porucha.
3. Přečtěte verdikt PPP, a pokud autentizovalo, výsledek IPCP, než budete předpokládat, že heslo je špatné.
4. Teprve nyní zadejte údaje znovu ve formátu, který server očekává, protože předpona domény mění účet.
5. Pokud stále selhává, sejměte oba konce se srovnanými časovými značkami a porovnejte fázi po fázi.

Zastavení u druhého kroku znamená problém cesty nebo zapouzdření a žádná úprava hesla s tím nepohne. Zastavení u třetího kroku znamená, že log už pojmenovává metodu nebo fond adres k opravě. V obou případech je další změna taková, kterou umíte odůvodnit, a přestanete kroužit kolem nastavení, která nikdy nebyla ve hře.