L2TP ühendub, aga PPP läbirääkimine ebaõnnestub: mis faasis?

IPsec-tunnel luuakse, klient näitab kaitstud partnerit ja siis sureb ühendus, enne kui miski jõuab privaatsesse alamosasse. See vahe on PPP, mis teeb oma tööd: lingi valikud, kasutaja autentimine ja aadressi määramine toimuvad kõik pärast seda, kui krüptitud tunnel on olemas. Miski õnnestunud esimese faasi vahetuses ei anna parooli ega sisemist aadressi. Lugege faase järjest ja rike nimetab end tavaliselt ise.

Tunnel on ainult esimene kiht

L2TP kannab PPP kaadreid IPsec-kaitstud tunneli sees, mis tähendab, et enne paketi marsruutimist peavad õnnestuma kaks sõltumatut läbirääkimist. Väline tõestab, et mõlemad otsad on võtmetes ja identiteetides ühel meelel. Sisemine otsustab lingi parameetrid, kas kasutaja autenditakse ja millise aadressi klient saab.

PPP-sisene rike näeb igas kliendis, mis näitab vaid üht olekurulda, välja nagu katkine tunnel. Selle käsitlemine tunneli probleemina viib võtmete uuendamise, teenuste taaskäivitamise ja lõpuks jagatud saladuse väljavahetamiseni, mis ei olnud kunagi vale. Kasulik eristus on odav: kui vahetus partneriga lõppes ja klient liikus kasutajanime küsimuse või autentimiseetapi juurde, on tunnel korras. Kõik pärast seda punkti kuulub PPP-le.

Lugege viimast faasi, mis õnnestus

Liikuge logis edasi ja peatuge esimeses faasis, mis ei lõppenud. Kõigepealt tuleb LCP, siis autentimine, siis IPCP IPv4 parameetrite jaoks.

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

LCP ajalõpp tähendab, et kaks otsa ei jõudnud kunagi kokkuleppele lingi põhivalikutes, mis on sobimatu profiil või blokeeritud sisemine protokoll, mitte halb parool. Selgesõnaline autentimisest keeldumine on vastupidine juhtum: link tõusis ja üks pool keeldus volitustest. IPCP ajalõpp pärast õnnestunud autentimist viitab aadressikogumitele või serveripoliitikale. Igal neist on erinev omanik ja erinev parandus, seepärast on faas tähtsam kui lõplik veatekst.

Hoidke logi väljavõte koos faasi nimega piletil. Ilma faasipiirita kleepitud saba kutsub järgmist lugejat oletama, ja oletamine maksab siin tunni.

Kokkulepe kliendi ja serveri vahel

Mõlemad otsad peavad nõustuma sama autentimismeetodiga ja salvestatud profiil võib nõuda meetodit, mille server eelmisel kvartalil kasutusest kõrvaldas. Hallatud juurutused varjavad ka serveripoolt, kus keeldumise põhjus registreeritakse tavaliselt kasutaja, mitte seadme kohta.

Lubage üks toetatud meetod, mitte iga pärandvalik, sest viit meetodit pakkuv klient varjab, milline ebaõnnestus. Küsige administraatorilt serveripoolset poliitikat ja täpset keeldumist, mis ei nõua, et keegi parooli avaldaks. Ühe kliendi päästmiseks lubatud pärandmeetod kipub levima igasse profiili, mis faili kopeerib.

Kontrollige aadressi, mitte sisselogimist

Lõpetatud sisselogimine ei ole kasutatav sessioon. IPCP läbiräägib sisemise aadressi ja ammendunud kogum või klienti keelav poliitika võib ikkagi jätta ühendatud tunneli, millel pole midagi marsruutida.

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

Kontrollige esmalt sisemist aadressi, seejärel marsruuti ja lahendajat ressursi jaoks, mida tegelikult vajate. Sisemine aadress ei ole avalik väljapääs, millest veebileht teatab, ja nende kahe segamini ajamine saadab inimesi otsima leket, mida pole. Testige privaatset ressurssi aadressi järgi enne nime järgi testimist, et DNS-i riket ei peetaks marsruutimisriikeks.

Kirjutage faas, meetod ja aadress ühte märkmesse ja dateerige see. Kui sama konto ebaõnnestub kuu aja pärast uuesti, on see märge erinevus viie minuti kontrolli ja uue uurimise vahel. Riiked erinevates faasides on erinevad juhtumid, isegi kui klient näitab üht dialoogi.