L2TP koplar til, men PPP-forhandlinga feilar: kva fase?

IPsec-tunnelen vert etablert, klienten viser ein verna partnar, og deretter døyr sambandet før noko når det private subnettet. Denne sprekka er PPP som gjer sin eigen jobb: lenkeval, brukarautentisering og adressetildeling skjer alt etter at den krypterte tunnelen finst. Ingenting ved ei vellukka utveksling i første fase gjev eit passord eller ei indre adresse. Les fasane i rekkjefølgje, og feilen namngjev som regel seg sjølv.

Tunnelen er berre det første laget

L2TP ber PPP-rammer inne i ein IPsec-verna tunnel, noko som tyder at to sjølvstendige forhandlingar må lukkast før ein pakke kan rutast. Den ytre provar at begge endar er samde om nøklar og identitetar. Den indre avgjer lenkjeparameterar, om brukaren autentiserer seg og kva adresse klienten får.

Ein feil inne i PPP ser ut som ein broten tunnel i kvar klient som berre viser eitt statuslys. Vert han handsama som eit tunnelproblem, fører det til ny nøkkelutveksling, omstart av tenester og til slutt utskifting av ein delt løyndom som aldri var feil. Den nyttige skilnaden er billeg: om utvekslinga med partnaren vart fullført og klienten gjekk vidare til ei brukarnamn-førespurnad eller ein autentiseringsfase, er tunnelen i orden. Alt etter det punktet høyrer til PPP.

Les den siste fasen som lukkast

Gå gjennom loggen framover og stopp ved den første fasen som ikkje vart fullført. LCP kjem først, deretter autentisering, deretter IPCP for IPv4-parameterar.

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

Eit LCP-tidsavbrot tyder at dei to endane aldri vart samde om grunnleggjande lenkeval, noko som er ein profil som ikkje passar eller ein blokkert indre protokoll, ikkje eit dårleg passord. Ei uttrykkeleg autentiseringsavvising er det motsette tilfellet: lenka kom opp, og den eine sida avviste påloggingsdetaljane. Eit IPCP-tidsavbrot etter vellukka autentisering peikar på adressepølar eller serverpolitikk. Kvar av dei har ein annan eigar og ei anna reparasjon, difor tyder fasen meir enn den endelege feilteksten.

Ta vare på loggutdraget saman med fasenamnet i saka. Ein limt inn hale utan fasegrensa inviterer neste lesar til å gjette, og gjetting kostar her ein time.

Semje mellom klienten og serveren

Begge endar må godta same autentiseringsmetode, og ein lagra profil kan be om ein som serveren avvikla i førre kvartal. Styrte utrullingar løyner også serversida, der avvisingsårsaka vanlegvis vert registrert på brukaren i staden for eininga.

Slå på éin støtta metode i staden for kvart eldre alternativ, fordi ein klient som tilbyr fem metodar tilslører kva som feila. Be administratoren om politikken på serversida og den nøyaktige avvisinga, noko som ikkje krev at nokon publiserer eit passord. Ein eldre metode som vert slått på for å redde éin klient, har ein tendens til å spreie seg til kvar profil som kopierer fila.

Kontroller adressa, ikkje pålogginga

Ei fullført pålogging er ikkje ei brukande økt. IPCP forhandlar den indre adressa, og ein tom pøl eller ein politikk som avviser klienten kan framleis late att ein tilkopla tunnel utan noko å rute.

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

Kontroller den indre adressa først, deretter ruta og resolveren for ressursen du faktisk treng. Ei indre adresse er ikkje den offentlege utgangen ei nettside rapporterer, og å blande dei to sender folk på jakt etter ein lekkasje som ikkje finst. Test den private ressursen på adresse før du testar på namn, slik at ein DNS-feil ikkje vert forveksla med ein rutefeil.

Skriv fasen, metoden og adressa i eitt notat og datér det. Om same konto feilar igjen om ein månad, er notatet skilnaden mellom ein femminutts sjekk og ei ny undersøking. Feil i ulike fasar er ulike hendingar, sjølv når klienten viser éin dialog.