L2TP se poveže, a pogajanje PPP vseeno spodleti: katera faza?

Tunel IPsec se vzpostavi, odjemalec pokaže zaščitenega partnerja, nato pa povezava umre, preden karkoli doseže zasebno podomrežje. Ta vrzel je PPP, ki opravlja svoje delo: možnosti povezave, preverjanje pristnosti uporabnika in dodeljevanje naslova se zgodijo šele po tem, ko šifrirani tunel obstaja. Nič v uspešni izmenjavi prve faze ne prinese gesla ali notranjega naslova. Preberite faze po vrsti in napaka se običajno poimenuje sama.

Tunel je le prva plast

L2TP prenaša okvire PPP v tunelu, zaščitenem z IPsec, kar pomeni, da morata pred usmerjanjem paketa uspeti dve neodvisni pogajanji. Zunanje dokazuje, da se oba konca strinjata glede ključev in identitet. Notranje odloči o parametrih povezave, ali se uporabnik preveri in kateri naslov prejme odjemalec.

Napaka znotraj PPP je videti kot pokvarjen tunel v vsakem odjemalcu, ki prikazuje samo eno statusno lučko. Če jo obravnavamo kot težavo tunela, to vodi v ponovno ustvarjanje ključev, ponovni zagon storitev in nazadnje v zamenjavo skupne skrivnosti, ki nikoli ni bila napačna. Uporabno razlikovanje je poceni: če se je izmenjava s partnerjem končala in je odjemalec prešel na poziv za uporabniško ime ali na stopnjo preverjanja pristnosti, je tunel v redu. Vse po tej točki pripada PPP.

Preberite zadnjo fazo, ki je uspela

Pojdite po dnevniku naprej in ustavite se pri prvi fazi, ki se ni končala. Najprej pride LCP, nato preverjanje pristnosti, nato IPCP za parametre 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

Zamuda LCP pomeni, da se dva konca nikoli nista dogovorila o osnovnih možnostih povezave, kar je neujemanje profila ali blokiran notranji protokol, ne slabo geslo. Izrecna zavrnitev preverjanja pristnosti je nasproten primer: povezava se je dvignila in ena stran je zavrnila poverilnice. Zamuda IPCP po uspešnem preverjanju pristnosti kaže na nize naslovov ali politiko strežnika. Vsak od teh ima drugega lastnika in drugo popravilo, zato je faza pomembnejša od končnega besedila napake.

Izvleček dnevnika hranite skupaj z imenom faze v zahtevku. Prilepljen rep brez meje faze vabi naslednjega bralca k ugibanju, ugibanje pa tu stane eno uro.

Soglasje med odjemalcem in strežnikom

Oba konca morata sprejeti isto metodo preverjanja pristnosti, shranjeni profil pa lahko zahteva tisto, ki jo je strežnik umaknil v prejšnjem četrtletju. Upravljave namestitve skrijejo tudi stran strežnika, kjer se razlog zavrnitve običajno zabeleži pri uporabniku in ne pri napravi.

Omogočite eno podprto metodo namesto vsake stare možnosti, ker odjemalec, ki ponuja pet metod, zakrije, katera je spodletela. Administratorja prosite za politiko na strani strežnika in natančno zavrnitev, kar ne zahteva, da kdo objavi geslo. Stara metoda, omogočena za reševanje enega odjemalca, se rada razširi na vsak profil, ki datoteko kopira.

Preverite naslov, ne prijave

Dokončana prijava še ni uporabna seja. IPCP se pogaja o notranjem naslovu, izčrpan niz ali politika, ki odjemalca zavrne, pa lahko vseeno pusti povezan tunel brez česar koli za usmerjanje.

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

Najprej preverite notranji naslov, nato pot in razreševalnik za vir, ki ga res potrebujete. Notranji naslov ni javni izhod, ki ga sporoča spletno mesto, in zamenjava obeh pošlje ljudi iskat uhajanje, ki ga ni. Zasebni vir preizkusite po naslovu, preden ga preizkusite po imenu, da se napaka DNS ne zamenja z napako usmerjanja.

Zapišite fazo, metodo in naslov v eno opombo ter jo datirajte. Če isti račun čez mesec znova spodleti, je ta opomba razlika med petminutnim preverjanjem in novo preiskavo. Napake v različnih fazah so različni dogodki, tudi ko odjemalec pokaže samo eno pogovorno okno.