L2TP prisijungia, bet PPP derybos nepavyksta: kuri fazė?

IPsec tunelis užmezgamas, klientas parodo apsaugotą partnerį, o tada ryšys nutrūksta dar niekam nepasiekus privataus potinklio. Ši spraga yra PPP, atliekantis savo darbą: jungties parinktys, naudotojo autentifikavimas ir adreso priskyrimas vyksta jau po to, kai užšifruotas tunelis egzistuoja. Niekas sėkmingame pirmosios fazės apsikeitime neduoda slaptažodžio ar vidinio adreso. Skaitykite fazes iš eilės, ir gedimas dažniausiai pats save įvardija.

Tunelis yra tik pirmasis sluoksnis

L2TP perduoda PPP kadrus IPsec apsaugotame tunelyje, o tai reiškia, kad prieš maršrutizuojant paketą turi pavykti dvi nepriklausomos derybos. Išorinė įrodo, kad abu galai sutaria dėl raktų ir tapatybių. Vidinė nusprendžia jungties parametrus, ar naudotojas autentifikuojamas ir kokį adresą gauna klientas.

Gedimas PPP viduje atrodo kaip sugedęs tunelis kiekviename kliente, rodančiame tik vieną būsenos lemputę. Jei tai laikoma tunelio problema, tenka iš naujo generuoti raktus, perkrauti paslaugas ir galiausiai pakeisti bendrą paslaptį, kuri niekada nebuvo neteisinga. Naudingas skirtumas pigus: jei apsikeitimas su partneriu baigtas ir klientas perėjo prie naudotojo vardo užklausos ar autentifikavimo etapo, tunelis tvarkingas. Viskas po šio taško priklauso PPP.

Perskaitykite paskutinę sėkmingą fazę

Eikite žurnalu į priekį ir sustokite prie pirmosios fazės, kuri nebuvo baigta. Pirmiausia ateina LCP, paskui autentifikavimas, paskui IPCP IPv4 parametrams.

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 skirtasis laikas reiškia, kad du galai niekada nesusitarė dėl pagrindinių jungties parinkčių, o tai yra profilio neatitikimas arba užblokuotas vidinis protokolas, o ne blogas slaptažodis. Aiškus autentifikavimo atmetimas yra priešingas atvejis: jungtis pakilo ir viena pusė atmetė prisijungimo duomenis. IPCP skirtasis laikas po sėkmingo autentifikavimo nurodo adresų telkinius arba serverio politiką. Kiekvienas jų turi kitą savininką ir kitą taisymą, todėl fazė svarbesnė už galutinį klaidos tekstą.

Laikykite žurnalo išrašą kartu su fazės pavadinimu biliete. Įklijuota uodega be fazės ribos kviečia kitą skaitytoją spėlioti, o spėliojimas čia kainuoja valandą.

Susitarimas tarp kliento ir serverio

Abu galai turi priimti tą patį autentifikavimo metodą, o išsaugotas profilis gali prašyti tokio, kurį serveris atšaukė praėjusį ketvirtį. Valdomos diegtys taip pat slepia serverio pusę, kur atmetimo priežastis paprastai registruojama naudotojui, o ne įrenginiui.

Įjunkite vieną palaikomą metodą, o ne kiekvieną seną parinktį, nes klientas, siūlantis penkis metodus, paslepia, kuris nepavyko. Paprašykite administratoriaus serverio pusės politikos ir tikslaus atmetimo, o tam nereikia, kad kas nors paskelbtų slaptažodį. Senas metodas, įjungtas gelbėti vieną klientą, linkęs plisti į kiekvieną profilį, kuris nukopijuoja failą.

Tikrinkite adresą, o ne prisijungimą

Baigtas prisijungimas dar nėra tinkama sesija. IPCP derasi dėl vidinio adreso, o išsekęs telkinys ar politika, atmetanti klientą, vis tiek gali palikti prijungtą tunelį be nieko maršrutizuoti.

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

Pirmiausia patikrinkite vidinį adresą, tada maršrutą ir sprendiklį resursui, kurio iš tikrųjų reikia. Vidinis adresas nėra viešoji išeitis, kurią praneša svetainė, ir sumaišius abu žmonės siunčiami ieškoti nuotėkio, kurio nėra. Išbandykite privatų resursą pagal adresą prieš bandydami pagal pavadinimą, kad DNS gedimas nebūtų palaikytas maršrutizavimo gedimu.

Užrašykite fazę, metodą ir adresą vienoje pastaboje ir pažymėkite datą. Jei ta pati paskyra po mėnesio vėl nepavyksta, ta pastaba yra skirtumas tarp penkių minučių patikros ir naujo tyrimo. Gedimai skirtingose fazėse yra skirtingi incidentai, net kai klientas rodo vieną dialogą.