Jurnalul de depanare L2TP este gol? Eroarea este probabil în journal

Porniți ajutorul L2TP cu depanare, priviți terminalul, și acesta se oprește fără nimic util pe ecran. Nu este un steag de depanare defect. O conexiune NetworkManager L2TP este formată din patru procese care cooperează, și doar unele dintre ele scriu în terminalul pe care îl urmăriți. Restul dovezilor se află în journal, la distanță de un filtru.

Patru procese, două destinații de jurnal

Conexiunea începe cu IPsec, care este libreswan sau strongSwan în funcție de instalare. Apoi demonul L2TP, în mod tradițional xl2tpd și în unele build-uri kl2tpd, conduce tunelul. La final pppd se ocupă de autentificare și adresare în interiorul acestuia.

Serviciul ajutător coordonează aceste piese și își tipărește propriul progres. Demonul IPsec și pppd raportează de obicei prin journalul sistemului, motiv pentru care terminalul arată o conexiune care eșuează în timp ce motivul se află într-un fișier pe care nu l-ați deschis.

Această separare explică și de ce o eroare PSK și o eroare de parolă arată la fel de pe desktop: ambele produc o deconectare generică, iar etapa care a eșuat este vizibilă doar în ieșirea fiecărui proces. Acesta este tot motivul pentru care journalul contează aici. Un mesaj generic pe desktop, patru autori posibili în spate.

Strângeți o singură încercare, apoi citiți ordinea

Reproduceți o dată, cu un profil cunoscut și o oră cunoscută, apoi citiți o fereastră îngustă în loc de întreaga pornire. Repetarea încercărilor în timp ce schimbați setările transformă jurnalul într-un amestec care nu poate fi interpretat.

Aceste comenzi selectează procesele participante pentru pornirea curentă, iar calea pluginului merită confirmată în distribuția dumneavoastră:

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

Câmpurile repetate într-un singur apel selectează uniunea acelor procese, ceea ce păstrează secvența în ordine temporală. Pe un sistem bazat pe Debian interogarea echivalentă este dpkg -L; ideea este să aflați unde trăiește de fapt ajutorul înainte de a încerca să îl rulați manual.

Trei condiții decid pasul următor

Citiți prima etapă care eșuează și alegeți în consecință. Dacă IPsec raportează o eroare de propunere sau de autentificare a partenerului, tunelul nu s-a format niciodată, iar schimbarea parolei PPP nu poate ajuta.

Dacă tunelul s-a format și pppd a respins autentificarea, secretul partajat era deja în regulă, iar problema acreditărilor este cu un nivel mai sus. Dacă pppd a negociat o adresă și eroarea apare mai târziu, ambele funcționează, iar problema rămasă este rutarea, DNS sau politica proprie a serverului.

Aceste trei ramuri acoperă aproape orice deconectare generică, și sunt decise de procesul care a înregistrat ultima eroare, nu de mesajul de eroare care pare cel mai alarmant.

Merită să confirmați și ce backend IPsec este instalat înainte de a atinge o setare de depanare. O opțiune de jurnalizare scrisă pentru strongSwan nu face nimic atunci când rulează libreswan, iar conexiunea va continua să eșueze în același loc în timp ce editați un fișier pe care nimeni nu îl citește.

Modul de depanare lasă fișiere în urmă

Fluxul original de depanare rulează serviciul manual cu un steag de depanare, iar acel mod poate lăsa fișierele de configurare de execuție generate la locul lor când conexiunea se încheie.

Acele fișiere conțin material de autentificare: cheia pre-partajată, acreditările sau ambele. O configurație generată copiată într-o fereastră de chat este o divulgare de acreditări, nu un fragment de jurnal. Eliminați liniile secrete înainte de a partaja ceva și ștergeți directorul când ancheta se termină. Tratați-le ca pe niște secrete, extrageți liniile precise de care aveți nevoie pentru un raport și ștergeți-le după aceea, în loc să lipiți un director într-un tichet.

Instanța manuală trebuie coordonată și cu cea normală. Pornirea unei copii de depanare în timp ce serviciul deține deja pluginul produce doi proprietari și un jurnal care le amestecă pe amândouă, ceea ce este mai rău decât deloc ieșire de depanare.

După aceea restabiliți ajutorul normal

Când ancheta se termină, opriți instanța manuală, eliminați fișierele de execuție păstrate și reconectați-vă pe calea normală, astfel încât următoarea persoană să vadă o configurație care corespunde realității.

Apoi verificați rezultatul în stratul care a eșuat, nu la pictograma de pe desktop:

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

O sesiune care se autentifică, primește o adresă și rutează către destinația dorită este rezultatul pe care îl depanați. Un terminal tăcut în timpul unei încercări eșuate vă spune doar unde ieșirea nu a fost scrisă.