L2TP ferbynt, mar PPP-ûnderhanneling mislearret: hokker faze?

De IPsec-tunnel komt ta stân, de klant lit in beskerme partner sjen, en dan stjert de ferbining foardat eat it partikuliere subnet berikt. Dat gat is PPP dat syn eigen wurk docht: keppelingsopsjes, brûkersautentikaasje en adresopdracht barre allegear neidat de fersifere tunnel bestiet. Neat oan in slagge earste-faze-útwikseling leveret in wachtwurd of in ynterne adres. Lês de fazen yn folchoarder en de flater neamt himsels meastentiids.

De tunnel is allinnich de earste laach

L2TP ferfiert PPP-ramen yn in IPsec-beskerme tunnel, wat betsjut dat twa ûnôfhinklike ûnderhannelingen slagje moatte foardat in pakket rûte wurde kin. De bûtenste bewissiget dat beide einen it iens binne oer kaaien en identiteiten. De binnenste beslút oer keppelingsparameters, oft de brûker autentisearret en hokker adres de klant krijt.

In flater binnen PPP liket op in brutsen tunnel by elke klant dy't mar ien statuslampe sjen lit. Behandelje jo it as in tunnelprobleem, dan liedt dat ta nije kaaien, it opnij starten fan tsjinsten en úteinlik it ferfangen fan in dield geheim dat nea ferkeard wie. It brûkbere ûnderskie is goedkeap: as de útwikseling mei de partner dien is en de klant trochgiet nei in brûkersnamfraach of in autentikaasjefaze, is de tunnel goed. Alles nei dat punt heart by PPP.

Lês de lêste faze dy't slagge

Wannelje it logboek foarút en stop by de earste faze dy't net foltôge is. LCP komt earst, dan autentikaasje, dan IPCP foar de 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

In LCP-time-out betsjut dat de beide einen it nea iens wurden binne oer basale keppelingsopsjes, wat in net-passend profyl of in blokkearre ynterne protokol is en gjin min wachtwurd. In dúdlike autentikaasje-ôfwizing is it tsjinoerstelde gefal: de keppeling kaam omheech en ien kant wegere de legitimisaasjes. In IPCP-time-out nei in slagge autentikaasje wiist op adrespools of serverbelied. Elk dêrfan hat in oare eigner en in oare reparaasje, dêrom is de faze wichtiger as de definitive flatertekst.

Hâld it logboekútskaai by de fazenamme yn it ticket. In plakt sturt sûnder de fazegrins noadet de folgjende lêzer út om te rieden, en rieden kostet hjir in oere.

Iensumens tusken de klant en de server

Beide einen moatte deselde autentikaasjemetoade akseptearje, en in bewarre profyl kin ien freegje dy't de server ferline fearnsjier ôfskaft hat. Behearde ynstallaasjes ferbergje ek de serverkant, dêr't de reden fan ôfwizing meastentiids by de brûker yn stee fan it apparaat fêstlein wurdt.

Skeakelje ien stipe metoade yn yn stee fan elke âlde opsje, want in klant dy't fiif metoaden biedt, ferberget hokker mislearre. Freegje de behearder om it belied oan serverkant en de krekte ôfwizing, wat net freget dat immen in wachtwurd publisearret. In âlde metoade dy't ynskeakele wurdt om ien klant te rêden, ferspriedt him graach nei elk profyl dat it bestân kopiearret.

Kontrolearje it adres, net de oanmelding

In foltôge oanmelding is gjin brûkbere sesje. IPCP ûnderhannelet it ynterne adres, en in útdroege pool of in belied dat de klant wegert kin noch altyd in ferbûn tunnel efterlitte sûnder eat om te rûten.

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

Kontrolearje earst it ynterne adres, dan de rûte en de resolver foar de boarne dy't jo echt nedich hawwe. In ynterne adres is net de iepenbiere útgong dy't in webside meldt, en it trochinoar heljen fan dy beide stjoert minsken op syk nei in lek dat der net is. Test de partikuliere boarne op adres foardat jo op namme teste, sadat in DNS-flater net as in rûteflater sjoen wurdt.

Skriuw de faze, de metoade en it adres yn ien notysje en set der in datum by. As itselde akkount oer in moanne wer mislearret, is dy notysje it ferskil tusken in kontrôle fan fiif minuten en in nij ûndersyk. Flatners yn ferskillende fazen binne ferskillende foarfallen, sels as de klant mar ien dialoochfinster toant.