Tuščias L2TP derinimo žurnalas? Klaida greičiausiai yra journal

Paleidžiate L2TP pagalbinę programą su derinimu, žiūrite į terminalą, ir ji sustoja ekrane neturėdama nieko naudingo. Tai ne sugadinta derinimo vėliavėlė. NetworkManager L2TP ryšys yra keturi bendradarbiaujantys procesai, ir tik kai kurie jų rašo į terminalą, kurį stebite. Likę įrodymai yra journal, per vieną filtrą.

Keturi procesai, dvi žurnalo vietos

Ryšys prasideda IPsec, kuris priklausomai nuo diegimo yra libreswan arba strongSwan. Tada L2TP tarnaitė, tradiciškai xl2tpd, o kai kuriuose surinkimuose kl2tpd, valdo tunelį. Galiausiai pppd tvarko autentifikavimą ir adresavimą jo viduje.

Pagalbinė tarnyba koordinuoja tas dalis ir spausdina savo eigą. IPsec tarnaitė ir pppd paprastai praneša per sistemos journal, todėl terminalas rodo nepavykusį ryšį, o priežastis yra faile, kurio neatidarėte.

Šis atskyrimas taip pat paaiškina, kodėl PSK klaida ir slaptažodžio klaida iš darbalaukio atrodo vienodai: abi sukelia bendrą atsijungimą, o nepavykęs etapas matomas tik kiekvieno proceso išvestyje. Tai ir yra visa priežastis, kodėl journal čia svarbus. Vienas bendras pranešimas darbalaukyje, keturi galimi autoriai už jo.

Surinkite vieną bandymą, tada skaitykite tvarką

Atkurkite vieną kartą su žinomu profiliu ir žinomu laiku, tada skaitykite siaurą langą, o ne visą įkrovimą. Bandymų kartojimas keičiant nustatymus paverčia žurnalą mišiniu, kurio neįmanoma interpretuoti.

Šios komandos parenka dabartinio įkrovimo dalyvaujančius procesus, o papildinio kelią verta patvirtinti savo distribucijoje:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

Pasikartojantys laukai viename iškvietime parenka tų procesų sąjungą, o tai išlaiko seką laiko tvarka. Debian pagrindu veikiančioje sistemoje atitinkama užklausa yra dpkg -L; esmė yra rasti, kur pagalbinė programa iš tikrųjų gyvena, prieš bandant ją paleisti rankiniu būdu.

Kitas žingsnis priklauso nuo trijų sąlygų

Perskaitykite pirmą nepavykusį etapą, tada pasirinkite atitinkamai. Jei IPsec praneša apie pasiūlymo ar partnerio autentifikavimo gedimą, tunelis niekada nebuvo suformuotas, o PPP slaptažodžio keitimas negali padėti.

Jei tunelis buvo suformuotas ir pppd atmetė prisijungimą, bendra paslaptis jau buvo tvarkinga, o kredencialų problema yra vienu sluoksniu aukščiau. Jei pppd derėjosi dėl adreso, o gedimas pasirodo vėliau, abu veikia, o likusi problema yra maršrutizavimas, DNS arba paties serverio politika.

Šios trys šakos apima beveik kiekvieną bendrą atsijungimą, ir jas lemia tai, kuris procesas užregistravo paskutinę klaidą, o ne tai, kuri klaidos žinutė atrodo labiausiai kelianti nerimą.

Taip pat verta patvirtinti, kuri IPsec sistema įdiegta, prieš liesdami derinimo nustatymą. Žurnalo parinktis, parašyta strongSwan, nieko nedaro, kai veikia libreswan, ir ryšys toliau nepavyks toje pačioje vietoje, kol redaguosite failą, kurio niekas neskaito.

Derinimo režimas palieka failus

Pradinis derinimo darbo srautas paleidžia tarnybą rankiniu būdu su derinimo vėliavėle, ir šis režimas gali palikti sugeneruotus vykdymo konfigūracijos failus vietoje, kai ryšys baigiasi.

Šiuose failuose yra autentifikavimo medžiagos: iš anksto bendrinamas raktas, kredencialai arba abu. Sugeneruota konfigūracija, nukopijuota į pokalbio langą, yra kredencialų atskleidimas, o ne žurnalo ištrauka. Pašalinkite slaptas eilutes prieš ką nors bendrindami ir ištrinkite katalogą, kai tyrimas baigsis. Traktuokite juos kaip paslaptis, ištraukite konkrečias eilutes, kurių jums reikia ataskaitai, ir po to jas ištrinkite, o ne įklijuokite katalogą į bilietą.

Rankinė kopija taip pat turi būti suderinta su įprasta. Derinimo kopijos paleidimas, kai tarnyba jau valdo papildinį, sukuria du savininkus ir žurnalą, kuriame jie sumaišyti, o tai blogiau nei visai jokios derinimo išvesties.

Po to atkurkite įprastą pagalbinę programą

Kai tyrimas baigsis, sustabdykite rankinę kopiją, pašalinkite išsaugotus vykdymo failus ir vėl prisijunkite įprastu keliu, kad kitas žmogus matytų konfigūraciją, atitinkančią tikrovę.

Tada patikrinkite rezultatą tame sluoksnyje, kuris nepavyko, o ne darbalaukio piktogramoje:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

Sesija, kuri autentifikuojasi, gauna adresą ir maršrutizuojama į numatytą paskirties vietą, yra rezultatas, kurį derinote. Tylus terminalas nepavykusio bandymo metu tik pasako kur išvestis nebuvo įrašyta.