L2TP se připojí, ale vyjednávání PPP selže: která fáze?

Tunel IPsec se naváže, klient ukáže chráněného protějška a pak spojení umře dřív, než se cokoli dostane do privátní podsítě. Ta mezera je PPP při vlastní práci: volby spoje, autentizace uživatele a přidělení adresy se dějí až poté, co šifrovaný tunel existuje. Nic na úspěšné výměně první fáze nedodá heslo ani vnitřní adresu. Čtěte fáze v pořadí a selhání se obvykle pojmenuje samo.

Tunel je jen první vrstva

L2TP přenáší rámce PPP uvnitř tunelu chráněného IPsec, což znamená, že před směrováním paketu musí uspět dvě nezávislá vyjednávání. Vnější dokazuje, že se oba konce shodnou na klíčích a identitách. Vnitřní rozhoduje o parametrech spoje, zda se uživatel autentizuje a jakou adresu klient dostane.

Selhání uvnitř PPP vypadá jako rozbitý tunel v každém klientovi, který ukazuje jedinou stavovou kontrolku. Když se bere jako problém tunelu, vede k obnově klíčů, restartu služeb a nakonec k výměně sdíleného tajemství, které nikdy nebylo špatné. Užitečné rozlišení je levné: pokud výměna s protějškem skončila a klient přešel k výzvě na uživatelské jméno nebo k fázi autentizace, tunel je v pořádku. Vše po tomto bodě patří PPP.

Přečtěte poslední fázi, která uspěla

Projděte log dopředu a zastavte se u první fáze, která se nedokončila. Nejprve přijde LCP, pak autentizace, pak IPCP pro parametry IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Timeout LCP znamená, že se oba konce nikdy nedohodly na základních volbách spoje, což je neshoda profilu nebo blokovaný vnitřní protokol, ne špatné heslo. Výslovné odmítnutí autentizace je opačný případ: spoj se zvedl a jedna strana odmítla přihlašovací údaje. Timeout IPCP po úspěšné autentizaci ukazuje na fondy adres nebo politiku serveru. Každý z nich má jiného vlastníka a jinou opravu, a proto je fáze důležitější než konečný text chyby.

Uchovejte výňatek z logu spolu s názvem fáze v tiketu. Vložený konec bez hranice fáze vyzývá dalšího čtenáře k hádání a hádání tady stojí hodinu.

Shoda mezi klientem a serverem

Oba konce musí přijmout stejnou metodu autentizace a uložený profil si může vyžádat tu, kterou server loni vyřadil. Spravované instalace také skrývají stranu serveru, kde se důvod odmítnutí obvykle zaznamenává k uživateli, ne k zařízení.

Zapněte jednu podporovanou metodu místo každé starší volby, protože klient nabízející pět metod zakrývá, která selhala. Požádejte správce o politiku na straně serveru a přesné odmítnutí, což nevyžaduje, aby někdo zveřejnil heslo. Starší metoda zapnutá na záchranu jednoho klienta se obvykle rozšíří do každého profilu, který soubor zkopíruje.

Ověřte adresu, ne přihlášení

Dokončené přihlášení není použitelná relace. IPCP vyjednává vnitřní adresu a vyčerpaný fond nebo politika, která klienta odmítá, může i tak nechat připojený tunel bez čehokoli ke směrování.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Nejprve zkontrolujte vnitřní adresu, pak trasu a resolver pro zdroj, který skutečně potřebujete. Vnitřní adresa není veřejný výstup, který hlásí webová stránka, a záměna obojího posílá lidi hledat únik, který tam není. Testujte privátní zdroj podle adresy dřív než podle jména, aby se selhání DNS nepletlo se selháním směrování.

Zapište fázi, metodu a adresu do jedné poznámky a opatřete ji datem. Pokud stejný účet za měsíc znovu selže, tato poznámka je rozdíl mezi pětiminutovou kontrolou a novým vyšetřováním. Selhání v různých fázích jsou různé incidenty, i když klient ukazuje jediný dialog.