Tukšs L2TP atkļūdošanas žurnāls? Kļūda, iespējams, ir journal

Jūs palaižat L2TP palīgprogrammu ar atkļūdošanu, skatāties uz termināli, un tā apstājas bez nekā noderīga ekrānā. Tas nav bojāts atkļūdošanas karodziņš. NetworkManager L2TP savienojums ir četri sadarbojošies procesi, un tikai daži no tiem raksta terminālī, kuru jūs vērojat. Pārējie pierādījumi ir journal, viena filtra attālumā.

Četri procesi, divas žurnāla vietas

Savienojums sākas ar IPsec, kas atkarībā no instalācijas ir libreswan vai strongSwan. Pēc tam L2TP dēmons, tradicionāli xl2tpd un dažās būvēs kl2tpd, vada tuneli. Visbeidzot pppd apstrādā autentifikāciju un adresāciju tā iekšienē.

Palīgpakalpojums koordinē šīs daļas un izdrukā savu gaitu. IPsec dēmons un pppd parasti ziņo caur sistēmas journal, tāpēc terminālis rāda neizdevušos savienojumu, kamēr iemesls ir failā, kuru jūs neesat atvēris.

Šī atdalīšana arī izskaidro, kāpēc PSK kļūda un paroles kļūda no galddatora izskatās vienādi: abas rada vispārīgu atvienošanu, un neizdevušais posms ir redzams tikai katra procesa izvadē. Tas ir viss iemesls, kāpēc journal šeit ir svarīgs. Viens vispārīgs ziņojums uz galddatora, četri iespējamie autori aiz tā.

Savāciet vienu mēģinājumu, tad lasiet secību

Atkārtojiet vienreiz ar zināmu profilu un zināmu laiku, tad lasiet šauru logu, nevis visu palaišanu. Mēģinājumu atkārtošana, mainot iestatījumus, pārvērš žurnālu maisījumā, kuru nevar interpretēt.

Šīs komandas izvēlas pašreizējās palaišanas dalībniekus procesus, un spraudņa ceļu ir vērts apstiprināt savā distribūcijā:

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

Atkārtoti lauki vienā izsaukumā izvēlas šo procesu apvienojumu, kas saglabā secību laika kārtībā. Debian balstītā sistēmā līdzvērtīgais vaicājums ir dpkg -L; būtība ir atrast, kur palīgprogramma patiešām dzīvo, pirms mēģināt to palaist manuāli.

Nākamo soli nosaka trīs nosacījumi

Izlasiet pirmo neizdevušos posmu, tad izvēlieties atbilstoši. Ja IPsec ziņo par priekšlikuma vai partnera autentifikācijas kļūmi, tunelis nekad netika izveidots, un PPP paroles maiņa nevar palīdzēt.

Ja tunelis tika izveidots un pppd noraidīja pieteikšanos, koplietotais noslēpums jau bija kārtībā, un akreditācijas datu problēma ir vienu slāni augstāk. Ja pppd vienojās par adresi un kļūme parādās vēlāk, abas darbojas, un atlikusī problēma ir maršrutēšana, DNS vai paša servera politika.

Šie trīs zari aptver gandrīz katru vispārīgu atvienošanu, un tos nosaka tas, kurš process reģistrēja pēdējo kļūdu, nevis tas, kura kļūdas ziņa izskatās visdraudīgākā.

Ir vērts arī apstiprināt, kura IPsec aizmugure ir instalēta, pirms pieskaraties atkļūdošanas iestatījumam. Žurnālēšanas opcija, kas rakstīta strongSwan, neko nedara, kad darbojas libreswan, un savienojums turpinās neizdoties tajā pašā vietā, kamēr jūs rediģējat failu, kuru neviens nelasa.

Atkļūdošanas režīms atstāj failus

Sākotnējā atkļūdošanas darbplūsma palaiž pakalpojumu manuāli ar atkļūdošanas karodziņu, un šis režīms var atstāt ģenerētos izpildlaika konfigurācijas failus savā vietā, kad savienojums beidzas.

Šie faili satur autentifikācijas materiālu: iepriekš koplietoto atslēgu, akreditācijas datus vai abus. Ģenerēta konfigurācija, kas kopēta tērzēšanas logā, ir akreditācijas datu atklāšana, nevis žurnāla izvilkums. Noņemiet slepenās rindas pirms kaut kā kopīgošanas un izdzēsiet direktoriju, kad izmeklēšana beidzas. Uzskatiet tos par noslēpumiem, izvelciet konkrētās rindas, kas nepieciešamas pārskatam, un pēc tam izdzēsiet tās, nevis ielīmējiet direktoriju biļetē.

Manuālā instance arī jāsaskaņo ar parasto. Atkļūdošanas kopijas palaišana, kamēr pakalpojums jau pārvalda spraudni, rada divus īpašniekus un žurnālu, kas sajauc abus, un tas ir sliktāk nekā vispār bez atkļūdošanas izvades.

Pēc tam atjaunojiet parasto palīgprogrammu

Kad izmeklēšana beidzas, apturiet manuālo instanci, noņemiet saglabātos izpildlaika failus un atkārtoti izveidojiet savienojumu parastajā ceļā, lai nākamā persona redzētu konfigurāciju, kas atbilst realitātei.

Pēc tam pārbaudiet rezultātu slānī, kas neizdevās, nevis galddatora ikonā:

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

Sesija, kas autentificējas, saņem adresi un maršrutē uz paredzēto galamērķi, ir rezultāts, kuru jūs atkļūdojāt. Kluss terminālis neizdevušā mēģinājuma laikā jums pasaka tikai kur izvade netika ierakstīta.