L2TP kobler til, men PPP-forhandlingen feiler: hvilken fase?

IPsec-tunnelen etableres, klienten viser en beskyttet peer, og deretter dør forbindelsen før noe når det private subnettet. Det gapet er PPP som gjør sin egen jobb: linkvalg, brukerautentisering og adressetildeling skjer alt etter at den krypterte tunnelen finnes. Ingenting ved en vellykket første-fase-utveksling gir et passord eller en indre adresse. Les fasene i rekkefølge, og feilen navngir som regel seg selv.

Tunnelen er bare det første laget

L2TP bærer PPP-rammer inne i en IPsec-beskyttet tunnel, som betyr at to uavhengige forhandlinger må lykkes før en pakke kan rutes. Den ytre beviser at begge ender er enige om nøkler og identiteter. Den indre avgjør lenkeparametere, om brukeren autentiseres og hvilken adresse klienten får.

En feil inne i PPP ser ut som en brutt tunnel i enhver klient som bare viser ett statuslys. Behandles den som et tunnelproblem, fører det til ny nøkkelutveksling, omstart av tjenester og til slutt utskifting av en delt hemmelighet som aldri var feil. Den nyttige forskjellen er billig: hvis utvekslingen med peeren ble fullført og klienten gikk videre til en brukernavnforespørsel eller en autentiseringsfase, er tunnelen i orden. Alt etter det punktet tilhører PPP.

Les den siste fasen som lyktes

Gå gjennom loggen forover og stopp ved den første fasen som ikke ble fullført. LCP kommer først, deretter autentisering, deretter IPCP for IPv4-parametere.

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-tidsavbrudd betyr at de to endene aldri ble enige om grunnleggende linkvalg, noe som er en profil som ikke passer eller en blokkert indre protokoll, ikke et dårlig passord. En uttrykkelig autentiseringsavvisning er det motsatte tilfellet: linken kom opp, og den ene siden avviste påloggingsdetaljene. En IPCP-tidsavbrudd etter vellykket autentisering peker på adressepooler eller serverpolicy. Hver av dem har en annen eier og en annen reparasjon, derfor betyr fasen mer enn den endelige feilteksten.

Ta vare på loggutdraget sammen med fasenavnet i saken. En limt inn hale uten fasegrensen inviterer neste leser til å gjette, og gjetting koster her en time.

Enighet mellom klienten og serveren

Begge ender må godta samme autentiseringsmetode, og en lagret profil kan be om en som serveren avviklet i forrige kvartal. Administrerte utplasseringer skjuler også serversiden, der avvisningsårsaken vanligvis registreres på brukeren i stedet for enheten.

Aktiver én støttet metode i stedet for hvert eldre alternativ, fordi en klient som tilbyr fem metoder tilslører hvilken som feilet. Be administratoren om serversidens policy og den nøyaktige avvisningen, noe som ikke krever at noen publiserer et passord. En eldre metode som aktiveres for å redde én klient, har en tendens til å spre seg til hver profil som kopierer filen.

Kontroller adressen, ikke påloggingen

En fullført pålogging er ikke en brukbar økt. IPCP forhandler den indre adressen, og en uttømt pool eller en policy som avviser klienten kan fortsatt etterlate en tilkoblet tunnel uten noe å rute.

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

Kontroller den indre adressen først, deretter ruten og resolveren for ressursen du faktisk trenger. En indre adresse er ikke den offentlige utgangen en nettside rapporterer, og å forveksle de to sender folk på jakt etter en lekkasje som ikke finnes. Test den private ressursen på adresse før du tester på navn, slik at en DNS-feil ikke forveksles med en rutefeil.

Skriv fasen, metoden og adressen i ett notat og datér det. Hvis samme konto feiler igjen om en måned, er notatet forskjellen mellom en femminutters sjekk og en ny undersøkelse. Feil i ulike faser er ulike hendelser, selv når klienten viser én dialog.