L2TP forbinder, men PPP-forhandlingen fejler: hvilken fase?

IPsec-tunnelen etableres, klienten viser en beskyttet peer, og derefter dør forbindelsen, før noget når det private undernet. Det hul er PPP, der gør sit eget arbejde: linkmuligheder, brugergodkendelse og tildeling af adresse sker alt sammen, efter at den krypterede tunnel findes. Intet ved en vellykket første-fase-udveksling giver en adgangskode eller en indre adresse. Læs faserne i rækkefølge, og fejlen navngiver som regel sig selv.

Tunnelen er kun det første lag

L2TP bærer PPP-rammer inde i en IPsec-beskyttet tunnel, hvilket betyder, at to uafhængige forhandlinger skal lykkes, før en pakke kan routes. Den ydre beviser, at begge ender er enige om nøgler og identiteter. Den indre afgør linkparametre, om brugeren godkendes, og hvilken adresse klienten får.

En fejl inde i PPP ser ud som en brudt tunnel i enhver klient, der kun viser én statuslampe. Behandles den som et tunnelproblem, fører det til ny nøgleudveksling, genstart af tjenester og til sidst udskiftning af en delt hemmelighed, der aldrig var forkert. Den brugbare skelnen er billig: hvis peer-udvekslingen blev færdig, og klienten gik videre til en brugernavnsprompt eller en godkendelsesfase, er tunnelen fin. Alt efter det punkt hører til PPP.

Læs den sidste fase, der lykkedes

Gå frem gennem loggen, og stop ved den første fase, der ikke blev færdig. LCP kommer først, derefter godkendelse, derefter IPCP for IPv4-parametre.

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

En LCP-timeout betyder, at de to ender aldrig blev enige om grundlæggende linkmuligheder, hvilket er en profil, der ikke passer, eller en blokeret indre protokol og ikke en dårlig adgangskode. En udtrykkelig godkendelsesafvisning er det modsatte tilfælde: linket kom op, og den ene side afviste oplysningerne. En IPCP-timeout efter vellykket godkendelse peger på adressepuljer eller serverpolitik. Hver af dem har en anden ejer og en anden reparation, og derfor betyder fasen mere end den endelige fejltekst.

Gem loguddraget sammen med fasenavnet i sagen. En indsat hale uden fasegrænsen inviterer den næste læser til at gætte, og gætteri her koster en time.

Enighed mellem klienten og serveren

Begge ender skal acceptere den samme godkendelsesmetode, og en gemt profil kan anmode om en, som serveren pensionerede i sidste kvartal. Administrerede installationer skjuler også serversiden, hvor afvisningsårsagen normalt registreres på brugeren frem for enheden.

Aktivér én understøttet metode i stedet for hver ældre mulighed, fordi en klient, der tilbyder fem metoder, slører hvilken der fejlede. Bed administratoren om serversidens politik og den præcise afvisning, hvilket ikke kræver, at nogen offentliggør en adgangskode. En ældre metode, der aktiveres for at redde én klient, har tendens til at sprede sig til enhver profil, der kopierer filen.

Kontrollér adressen, ikke login

Et fuldført login er ikke en brugbar session. IPCP forhandler den indre adresse, og en udtømt pulje eller en politik, der afviser klienten, kan stadig efterlade en tilsluttet tunnel uden noget at route.

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

Kontrollér den indre adresse først, derefter ruten og resolveren for den ressource, du faktisk har brug for. En indre adresse er ikke den offentlige udgang, en hjemmeside rapporterer, og at forveksle de to sender folk på jagt efter en læk, der ikke er der. Test den private ressource på adressen, før du tester på navnet, så en DNS-fejl ikke forveksles med en routingfejl.

Skriv fasen, metoden og adressen i et enkelt notat, og datér det. Hvis den samme konto fejler igen om en måned, er notatet forskellen mellem et femminutters tjek og en ny undersøgelse. Fejl i forskellige faser er forskellige hændelser, selv når klienten viser én dialog.