L2TP maak verbinding, maar PPP-onderhandeling misluk: watter fase?

Die IPsec-tonnel kom tot stand, die kliënt wys 'n beskermde eweknie, en dan sterf die verbinding voordat iets die private subnet bereik. Daardie gaping is PPP wat sy eie werk doen: skakelopsies, gebruikersverifikasie en adrestoewysing gebeur alles nadat die versleutelde tonnel bestaan. Niks aan 'n suksesvolle fase-een-uitruiling lewer 'n wagwoord of 'n binnesadres nie. Lees die fases in volgorde en die fout noem gewoonlik homself.

Die tonnel is net die eerste laag

L2TP dra PPP-rame binne 'n IPsec-beskermde tonnel, wat beteken twee onafhanklike onderhandelinge moet slaag voordat 'n pakket gerouteer kan word. Die buitenste een bewys dat beide kante oor sleutels en identiteite saamstem. Die binneste een bepaal skakelparameters, of die gebruiker verifieer, en watter adres die kliënt ontvang.

'n Fout binne PPP lyk soos 'n gebreekte tonnel in elke kliënt wat net een statusliggie wys. Om dit as 'n tonnelprobleem te behandel lei tot hernuwing van sleutels, herbegin van dienste en uiteindelik die vervanging van 'n gedeelde geheim wat nooit verkeerd was nie. Die nuttige onderskeiding is goedkoop: as die eweknie-uitruiling voltooi is en die kliënt het na 'n gebruikersnaam-vraag of 'n verifikasiestap oorgegaan, is die tonnel reg. Alles ná daardie punt behoort aan PPP.

Lees die laaste fase wat geslaag het

Lees die log vorentoe en stop by die eerste fase wat nie voltooi is nie. LCP kom eerste, dan verifikasie, dan IPCP vir IPv4-parameters.

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

'n LCP-tydsverloop beteken die twee kante het nooit oor basiese skakelopsies ooreengekom nie, wat 'n profielwanpassing of 'n geblokkeerde binneprotokol is eerder as 'n slegte wagwoord. 'n Duidelike verifikasie-verwerping is die teenoorgestelde geval: die skakel het opgekom en een kant het die geloofsbriewe geweier. 'n IPCP-tydsverloop ná suksesvolle verifikasie dui op adrespoele of bedienerbeleid. Elkeen daarvan het 'n ander eienaar en 'n ander herstel, en daarom is die fase belangriker as die finale foutteks.

Hou die log-uittreksel saam met die fasenaam in die kaartjie. 'n Geplakte stert sonder die fasegrens nooi die volgende leser om te raai, en raai hier kos 'n uur.

Ooreenkoms tussen die kliënt en die bediener

Beide kante moet dieselfde verifikasiemetode aanvaar, en 'n gestoorde profiel kan een aanvra wat die bediener verlede kwartaal onttrek het. Bestuurde ontplooiings verberg ook die bedienerkant, waar die verwerpingsrede gewoonlik teen die gebruiker eerder as die toestel aangeteken word.

Aktiveer een ondersteunde metode eerder as elke ou opsie, want 'n kliënt wat vyf metodes aanbied verduister watter een gefaal het. Vra die administrateur vir die bedienerkant-beleid en die presiese verwerping, wat nie vereis dat iemand 'n wagwoord publiseer nie. 'n Ou metode wat geaktiveer word om een kliënt te red, versprei gewoonlik na elke profiel wat die lêer kopieer.

Verifieer die adres, nie die aanmelding nie

'n Voltooide aanmelding is nie 'n bruikbare sessie nie. IPCP onderhandel die binnesadres, en 'n uitgeputte poel of 'n beleid wat die kliënt weier kan steeds 'n gekoppelde tonnel laat met niks om te routeer nie.

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

Kontroleer eers die binnesadres, dan die roete en die oplosser vir die hulpbron wat jy werklik nodig het. 'n Binnesadres is nie die publieke uitgang wat 'n webwerf rapporteer nie, en om die twee te verwar laat mense jaag op 'n lek wat nie daar is nie. Toets die private hulpbron per adres voordat jy per naam toets, sodat 'n DNS-fout nie as 'n roeteerfout verstaan word nie.

Skryf die fase, die metode en die adres in een nota en dateer dit. As dieselfde rekening oor 'n maand weer faal, is daardie nota die verskil tussen 'n vyf-minute-kontrole en 'n nuwe ondersoek. Foute in verskillende fases is verskillende voorvalle, selfs wanneer die kliënt net een dialoog wys.