Ktorá fáza VPN zlyhala: IPsec, riadenie L2TP alebo autentifikácia PPP

Zmenili ste heslo a nič sa nepohlo, pretože porucha nikdy nebola v PPP. L2TP/IPsec hlási jednu chybu pripojenia pre päť veľmi odlišných odovzdaní a každé odovzdanie má vlastnú opravu. Pracujte odzadu: nájdite poslednú úspešnú fázu a meňte iba to, čo prichádza po nej. Poradie nižšie tiež rozhoduje, aké dôkazy zbierate ako prvé.

Odpovedzte na štyri otázky v poradí

Vynúťte nový pokus, pretože niektorí klienti zobrazujú predchádzajúcu chybu, kým sa profil neodpojí a znova nepripojí. Potom odpovedzte: existovalo pridruženie zabezpečenia IPsec, objavili sa riadiace spojenie L2TP a volanie, dospelo PPP k verdiktu autentifikácie a pridelil IPCP klientovi adresu? Prvé nie je fáza, ktorú opravujete. Všetko po nej je neotestované, takže odmietnuté používateľské meno nič nedokazuje, keď pridruženie nikdy neexistovalo.

Pred porovnaním zosynchronizujte hodiny na oboch koncoch. Pokus, ktorý vyčistil IPsec a zlyhal na PPP, vyzerá ako jediná porucha, keď klient zobrazuje iba poslednú správu a serverový log stále drží predchádzajúci pokus. Čítajte podľa časovej značky, nie podľa najhlasnejšieho riadku.

Keď máte len snímku obrazovky používateľa, oprite sa o najlacnejšie rozdelenie: nesprávny predbežne zdieľaný kľúč a xl2tpd, ktorý nikdy neodpovedá, dávajú v dialógu Windows rovnaký text, ale jedno vyžaduje tajomstvo zmenené na oboch koncoch a druhé spusteného démona alebo pravidlo firewallu na samotnom serveri. Zariadenie v strede nemôže zahodiť vnútorný 1701, keď ho IPsec v transportnom režime už obalil, preto nehľadajte filter cesty, ktorý neexistuje.

Čo ktorá vrstva skutočne vlastní

IPsec chráni pakety medzi dvoma partnermi; L2TP nesie reláciu PPP vnútri tej chránenej cesty, a preto RFC 3193 predpisuje transportný režim namiesto vlastného tunela. Štítok klienta hovorí L2TP, takže tunel a prihlásenie pôsobia ako jeden mechanizmus. Nie sú: riadiace spojenie L2TP autentifikuje konce tunela tam, kde to nasadenie zapne, a PPP oddelene autentifikuje používateľa pomocou CHAP, PAP alebo MS-CHAPv2 podľa politiky servera.

Toto rozdelenie vysvetľuje dve tajomstvá, ktoré si ľudia stále pletú. Predbežne zdieľaný kľúč autentifikuje partnerov IPsec. Používateľské meno a heslo identifikujú používateľa voči PPP. Opätovné zadanie zdieľaného tajomstva Windows na profile, ktorý sa autentifikuje certifikátmi, nič nemení v zlyhávajúcej fáze a úprava hesla PPP nemôže poskytnúť chýbajúci chránený kanál. Rovnaká zdržanlivosť platí pri kontrole identity: nevypínajte identitu partnera ani overovanie certifikátu, aby ste získali tunel, pretože potom sa pripája cesta, nie partner.

Ani autentifikácia nie je koniec PPP. Po prijatí používateľa IPCP vyjednáva adresu klienta a možnosti DNS a WINS, ktoré je server ochotný vydať. Klient môže prejsť CHAP alebo MS-CHAPv2 a napriek tomu skončiť bez adresy, čo je porucha vnútri PPP, nie problém smerovania. Obyčajný L2TP bez IPsec zostáva platný a nechránený, takže úspešné pripojenie nikdy nedokazuje, že prevádzka je chránená; skontrolujte, čo vyžaduje server, nie štítok klienta.

Rozhodnite podľa prvej chýbajúcej fázy

Čítajte tabuľku podľa prvého chýbajúceho prvku, zľava doprava. Pravý stĺpec je jediná práca, ktorá v tej chvíli stojí za to; všetko naľavo od neho je už dokázané a opätovné testovanie spáli okno výpadku bez pridania informácie.

Tri riadky si zaslúžia varovanie. Riadok 1701 je miesto, kde zvyčajne končia klienti Windows za NAT: pridruženie sa dokončí, potom nič neprichádza a príčinou je zapuzdrenie, nie zlé heslo. Riadok IPCP je ten, ktorý sa mylne číta ako problém trasy, pretože Windows zabalí chýbajúcu adresu do chyby 720 a ikona v oznamovacej oblasti len povie, že pripojenie zlyhalo; táto porucha leží po autentifikácii a pred smerovaním. Posledný riadok nie je vôbec porucha IPsec, aj keď ikona hovorí odpojené.

Príkazy, ktoré oddeľujú vrstvy

Na linuxovom serveri so strongSwan swanctl --list-sas vypisuje nadviazané pridruženia s identitou partnera a ipsec statusall pokrýva staršie hostiteľov strongSwan a libreswan. Pod tým ip xfrm state zobrazuje skutočné pridruženia jadra, zatiaľ čo ss -lunp | grep 1701 dokazuje, kam je xl2tpd priviazaný. Spustite xl2tpd -D v popredí, aby ste videli riadiace spojenia a volania, a zapnite ladenie pppd v /etc/ppp/options.xl2tpd, aby ste videli ponúkanú metódu a odpoveď.

Keď logy ukážu úspešnú autentifikáciu, ďalšia otázka je, či sa IPCP dokončil. Skontrolujte, či ip range v sekcii [lns default] súboru /etc/xl2tpd/xl2tpd.conf má ešte voľné adresy a či /etc/ppp/options.xl2tpd naozaj nesie ms-dns a ms-wins, ak ich klient očakáva. Vyčerpaný fond a chýbajúca možnosť DNS vyzerajú na vodiči inak: prvý nechá klienta bez adresy a s 720, druhý dá adresu, ale žiadny prekladač, takže mená zlyhávajú, kým ping na surové adresy funguje. Ani jedno sa neopraví opätovným zadaním hesla.

Na klientovi doplnok L2TP v NetworkManageri zapisuje rozhovor pppd do denníka, takže journalctl -u NetworkManager -b zvyčajne oddelí tunel hore, autentifikácia odmietnutá od žiadny tunel. V Windows Get-VpnConnection hlási skutočné nastavenia autentifikácie profilu a udalosti RasClient v časti Application v Prehliadači udalostí pomenúvajú zlyhávajúci komponent. Keď je dialóg príliš nejasný, zapnite netsh ras set tracing * enable.

Záznamy vyžadujú jedno upozornenie. Pri IPsec v transportnom režime je vnútorný UDP 1701 šifrovaný, takže záznam na vonkajšom rozhraní ukazuje ESP, alebo UDP 4500 pod NAT-T, a vôbec žiadne L2TP. Chýbajúci 1701 v zázname je očakávaný a nie je dôkazom zablokovaného portu; sledujte, či sa počítadlá ESP alebo 4500 hýbu.

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

NAT búra predpoklady skôr, než je čokoľvek autentifikované. ESP je vlastný protokol IP, takže prekladajúce zariadenie ho zahodí, ak partneri nezapuzdria; presne to poskytuje UDP 4500. Na serveri Windows, ktorý sám stojí za domácim routerom alebo cloudovou bránou NAT, fáza IPsec zlyháva s chybou 789, kým sa AssumeUDPEncapsulationContextOnSendRule nenastaví na 2 pod kľúčom PolicyAgent a stroj sa nereštartuje, a porucha zostáva nerozoznateľná od zatvoreného portu. Klienti za NAT sú jednoduchší: s verejnou adresou na serveri ich nesie NAT-T na UDP 4500 a tá hodnota do hry nevstupuje.

Keď je PPP hore, MTU s čiernou dierou napodobňuje mŕtvy tunel: malé pakety prechádzajú, TLS podanie ruky alebo načítanie stránky visí a klient môže stále zobrazovať pripojené. Znížte MTU rozhrania alebo stiahnite MSS na bráne, skôr než obviníte server. Smerovanie rozdeleného tunela je druhý podvodník; podsieti poslaná s nesprávnou maskou nechá tunel zdravý a jednu aplikáciu nedostupnú. Súkromný názov hostiteľa pridáva vlastný krok: ak dopyt vychádza cez lokálny prekladač, názov sa nevyrieši pred testovaním akejkoľvek trasy.

Kontrolný zoznam predtým, než sa dotknete prihlasovacích údajov

Prejdite zoznam v poradí a zastavte sa pri prvom zlyhávajúcom prvku. Každý krok je lacný a každý vylučuje celú triedu úprav.

1. Potvrďte, že pridruženie existuje na oboch koncoch, spárované podľa identity partnera, nie podľa štítku pripojené.
2. Potvrďte, že UDP 1701 dosiahne xl2tpd; pridruženie bez volania je vaša porucha.
3. Prečítajte verdikt PPP a, ak autentifikoval, výsledok IPCP, skôr než budete predpokladať, že heslo je nesprávne.
4. Až teraz zadajte prihlasovacie údaje znova vo formáte, ktorý server očakáva, pretože predpona domény mení účet.
5. Ak stále zlyháva, nasnímajte oba konce s vyrovnanými časovými značkami a porovnajte fázu po fáze.

Zastavenie na druhom kroku znamená problém cesty alebo zapuzdrenia a žiadna úprava hesla ho nepohne. Zastavenie na treťom kroku znamená, že log už pomenúva metódu alebo fond adries na opravu. V oboch prípadoch je ďalšia zmena taká, ktorú dokážete odôvodniť, a prestanete krúžiť okolo nastavení, ktoré nikdy neboli v hre.