Prazen dnevnik razhroščevanja L2TP? Napaka je verjetno v journalu

Zaženete pomožni program L2TP z razhroščevanjem, gledate v terminal in se ustavi brez česar koli uporabnega na zaslonu. To ni pokvarjena zastavica za razhroščevanje. Povezava NetworkManager L2TP je štiri sodelujoči procesi in le nekateri od njih pišejo v terminal, ki ga opazujete. Ostali dokazi so v journalu, en filter stran.

Štirje procesi, dve namembni mesti dnevnika

Povezava se začne z IPsec, ki je glede na namestitev libreswan ali strongSwan. Nato tunel vodi demon L2TP, tradicionalno xl2tpd in v nekaterih sestavih kl2tpd. Na koncu pppd v njem skrbi za preverjanje pristnosti in naslavljanje.

Pomožna storitev usklajuje te dele in izpisuje svoj napredek. Demon IPsec in pppd običajno poročata prek sistemskega journala, zato terminal prikazuje povezavo, ki ne uspe, medtem ko razlog leži v datoteki, ki je niste odprli.

Ta delitev pojasnjuje tudi, zakaj sta napaka PSK in napaka gesla z namizja videti enako: obe povzročita splošno prekinitev, stopnja, ki je spodletela, pa je vidna le v izhodu posameznega procesa. To je ves razlog, zakaj je journal tukaj pomemben. Eno splošno sporočilo na namizju, štirje možni avtorji za njim.

Zberite en poskus in nato preberite vrstni red

Enkrat ponovite z znanim profilom in znanim časom, nato preberite ozko okno namesto celotnega zagona. Ponavljanje poskusov ob spreminjanju nastavitev spremeni dnevnik v mešanico, ki je ni mogoče razložiti.

Ti ukazi izberejo sodelujoče procese za trenutni zagon, pot do vtičnika pa velja potrditi v svoji distribuciji:

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

Ponovljena polja v enem klicu izberejo unijo teh procesov, kar ohrani zaporedje v časovnem redu. V sistemu, ki temelji na Debianu, je enakovredna poizvedba dpkg -L; bistvo je najti, kje pomožni program v resnici živi, preden ga poskusite zagnati ročno.

Naslednjo potezo določajo trije pogoji

Preberite prvo stopnjo, ki spodleti, in izberite ustrezno. Če IPsec poroča o napaki predloga ali preverjanja pristnosti nasprotne strani, tunel ni nikoli nastal, in spreminjanje gesla PPP ne more pomagati.

Če je tunel nastal in je pppd zavrnil prijavo, je bila skupna skrivnost že v redu, težava s poverilnicami pa je eno plast višje. Če se je pppd pogajal o naslovu in se napaka pojavi pozneje, oboje deluje, preostala težava pa je usmerjanje, DNS ali lastna politika strežnika.

Te tri veje pokrivajo skoraj vsako splošno prekinitev, in o njih odloča to, kateri proces je zabeležil zadnjo napako, ne pa to, katero sporočilo o napaki se zdi najbolj alarmantno.

Velja tudi potrditi, katera zaledna rešitev IPsec je nameščena, preden se dotaknete nastavitve razhroščevanja. Možnost beleženja, napisana za strongSwan, ne naredi ničesar, ko teče libreswan, in povezava bo še naprej spodletela na istem mestu, medtem ko urejate datoteko, ki je nihče ne bere.

Način razhroščevanja pušča datoteke

Prvotni potek razhroščevanja zažene storitev ročno z zastavico za razhroščevanje, in ta način lahko ob koncu povezave pusti ustvarjene konfiguracijske datoteke izvajalnega časa na svojem mestu.

Te datoteke vsebujejo gradivo za preverjanje pristnosti: vnaprej deljeno ključ ali poverilnice ali oboje. Ustvarjena konfiguracija, kopirana v okno klepeta, je razkritje poverilnic, ne izvleček dnevnika. Odstranite vrstice s skrivnostmi, preden karkoli delite, in izbrišite mapo, ko se preiskava konča. Obravnavajte jih kot skrivnosti, izvlecite določene vrstice, ki jih potrebujete za poročilo, in jih nato izbrišite, namesto da prilepite mapo v zahtevek.

Tudi ročni primerek je treba uskladiti z običajnim. Zagon kopije za razhroščevanje, ko storitev že ima vtičnik, ustvari dva lastnika in dnevnik, ki meša oba, kar je slabše kot nobenega izhoda razhroščevanja.

Nato obnovite običajni pomožni program

Ko se preiskava konča, ustavite ročni primerek, odstranite shranjene datoteke izvajalnega časa in se znova povežite po običajni poti, da bo naslednja oseba videla konfiguracijo, ki ustreza resničnosti.

Nato preverite rezultat v plasti, ki je spodletela, ne pri ikoni na namizju:

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

Seja, ki se preveri, prejme naslov in je usmerjena na predvideni cilj, je rezultat, ki ste ga razhroščevali. Tih terminal med neuspešnim poskusom vam pove le kje izhod ni bil zapisan.