Er L2TP-fejlretningsloggen tom? Fejlen ligger sandsynligvis i journalen

Du starter L2TP-hjælpeprogrammet med fejlretning, kigger på terminalen, og det stopper uden noget brugbart på skærmen. Det er ikke et ødelagt fejlretningsflag. En NetworkManager L2TP-forbindelse er fire samarbejdende processer, og kun nogle af dem skriver til den terminal, du kigger på. Resten af beviserne ligger i journalen, én filterafstand væk.

Fire processer, to logdestinationer

Forbindelsen begynder med IPsec, som er enten libreswan eller strongSwan afhængigt af installationen. Derefter kører L2TP-dæmonen, traditionelt xl2tpd og i nogle builds kl2tpd, tunnelen. Til sidst håndterer pppd godkendelse og adressering indeni.

Hjælpetjenesten koordinerer de dele og udskriver sin egen fremdrift. IPsec-dæmonen og pppd rapporterer normalt gennem systemjournalen, og derfor viser terminalen en forbindelse, der fejler, mens årsagen ligger i en fil, du ikke har åbnet.

Den opdeling forklarer også, hvorfor en PSK-fejl og en adgangskodefejl ser ens ud fra skrivebordet: begge giver en generisk afbrydelse, og det trin, der fejlede, er kun synligt i outputtet for hver proces. Det er hele grunden til, at journalen er vigtig her. Én generisk meddelelse på skrivebordet, fire mulige forfattere bag den.

Saml ét forsøg, og læs så rækkefølgen

Genskab det én gang med en kendt profil og et kendt tidspunkt, og læs så et smalt vindue i stedet for hele opstarten. Gentagne forsøg, mens du ændrer indstillinger, gør loggen til en blanding, der ikke kan fortolkes.

Disse kommandoer vælger de deltagende processer for den aktuelle opstart, og det er værd at bekræfte plugin-stien på din distribution:

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

Gentagne felter i et kald vælger foreningen af disse processer, hvilket holder rækkefølgen i tidsorden. På et Debian-baseret system er den tilsvarende forespørgsel dpkg -L; pointen er at finde ud af, hvor hjælpeprogrammet faktisk bor, før du prøver at køre det manuelt.

Tre betingelser afgør det næste skridt

Læs det første trin, der fejler, og vælg derefter. Hvis IPsec rapporterer en fejl i forslaget eller i peer-godkendelsen, blev tunnelen aldrig dannet, og det hjælper ikke at ændre PPP-adgangskoden.

Hvis tunnelen blev dannet, og pppd afviste login, var den delte hemmelighed allerede fin, og legitimationsproblemet ligger et lag højere. Hvis pppd forhandlede en adresse, og fejlen først vises senere, virker begge dele, og det resterende problem er routing, DNS eller serverens egen politik.

Disse tre grene dækker næsten enhver generisk afbrydelse, og de afgøres af, hvilken proces der loggede den sidste fejl, ikke af, hvilken fejlmeddelelse der ser mest alarmerende ud.

Det er også værd at bekræfte, hvilken IPsec-backend der er installeret, før du rører en fejlretningsindstilling. En logindstilling skrevet til strongSwan gør intet, når libreswan kører, og forbindelsen vil fortsætte med at fejle samme sted, mens du redigerer en fil, ingen læser.

Fejlretningstilstand efterlader filer

Den oprindelige fejlretningsarbejdsgang kører tjenesten manuelt med et fejlretningsflag, og den tilstand kan efterlade genererede runtime-konfigurationsfiler på plads, når forbindelsen slutter.

Disse filer indeholder godkendelsesmateriale: den foruddelte nøgle, legitimationsoplysninger eller begge dele. En genereret konfiguration kopieret ind i et chatvindue er en afsløring af legitimationsoplysninger, ikke et loguddrag. Fjern hemmelighedslinjerne, før du deler noget, og slet mappen, når undersøgelsen slutter. Behandl dem som hemmeligheder, udtræk de specifikke linjer, du har brug for til en rapport, og slet dem bagefter i stedet for at indsætte en mappe i en ticket.

Den manuelle instans skal også koordineres med den normale. Start af en fejlretningskopi, mens tjenesten allerede ejer plugin’et, giver to ejere og en log, der blander begge, hvilket er værre end slet ingen fejlretningsoutput.

Gendan derefter det normale hjælpeprogram

Når undersøgelsen slutter, stop den manuelle instans, fjern de bevarede runtime-filer, og opret forbindelse igen ad den normale vej, så den næste person ser en konfiguration, der matcher virkeligheden.

Bekræft derefter resultatet i det lag, der fejlede, ikke ved skrivebordsikonet:

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

En session, der godkender, modtager en adresse og router til den tilsigtede destination, er det resultat, du fejlrettede. En tavs terminal under et mislykket forsøg fortæller dig kun hvor outputtet ikke blev skrevet.