Er L2TP-feilsøkingsloggen tom? Feilen ligger sannsynligvis i journalen

Du starter L2TP-hjelperen med feilsøking, ser på terminalen, og den stopper uten noe nyttig på skjermen. Det er ikke et ødelagt feilsøkingsflagg. En NetworkManager L2TP-tilkobling er fire samarbeidende prosesser, og bare noen av dem skriver til terminalen du ser på. Resten av bevisene ligger i journalen, én filteravstand unna.

Fire prosesser, to loggdestinasjoner

Tilkoblingen begynner med IPsec, som er enten libreswan eller strongSwan avhengig av installasjonen. Deretter kjører L2TP-demonen, tradisjonelt xl2tpd og i noen bygg kl2tpd, tunnelen. Til slutt håndterer pppd autentisering og adressering inni den.

Hjelpertjenesten koordinerer disse delene og skriver ut sin egen fremdrift. IPsec-demonen og pppd rapporterer vanligvis gjennom systemjournalen, og derfor viser terminalen en tilkobling som feiler mens årsaken ligger i en fil du ikke har åpnet.

Denne delingen forklarer også hvorfor en PSK-feil og en passordfeil ser like ut fra skrivebordet: begge gir en generisk frakobling, og trinnet som feilet er bare synlig i utdataen per prosess. Det er hele grunnen til at journalen er viktig her. Én generisk melding på skrivebordet, fire mulige forfattere bak den.

Samle ett forsøk, og les deretter rekkefølgen

Reproduser én gang, med en kjent profil og et kjent tidspunkt, og les deretter et smalt vindu i stedet for hele oppstarten. Gjentatte forsøk mens du endrer innstillinger gjør loggen til en blanding som ikke kan tolkes.

Disse kommandoene velger de deltakende prosessene for gjeldende oppstart, og det er verdt å bekrefte plugin-banen på distribusjonen din:

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

Gjentatte felt i ett kall velger foreningen av disse prosessene, noe som holder rekkefølgen i tidsorden. På et Debian-basert system er den tilsvarende spørringen dpkg -L; poenget er å finne ut hvor hjelperen faktisk bor før du prøver å kjøre den manuelt.

Tre betingelser avgjør neste trekk

Les det første trinnet som feiler, og velg deretter. Hvis IPsec rapporterer en feil i forslaget eller i peer-autentiseringen, ble tunnelen aldri dannet, og det hjelper ikke å endre PPP-passordet.

Hvis tunnelen ble dannet og pppd avviste innloggingen, var den delte hemmeligheten allerede i orden, og legitimasjonsproblemet ligger ett lag høyere. Hvis pppd forhandlet om en adresse og feilen først vises senere, virker begge, og det gjenværende problemet er ruting, DNS eller serverens egen policy.

Disse tre grenene dekker nesten enhver generisk frakobling, og de avgjøres av hvilken prosess som logget den siste feilen, ikke av hvilken feilmelding som ser mest alarmerende ut.

Det er også verdt å bekrefte hvilken IPsec-backend som er installert før du rører en feilsøkingsinnstilling. Et loggalternativ skrevet for strongSwan gjør ingenting når libreswan kjører, og tilkoblingen vil fortsette å feile på samme sted mens du redigerer en fil ingen leser.

Feilsøkingsmodus etterlater filer

Den opprinnelige feilsøkingsarbeidsflyten kjører tjenesten manuelt med et feilsøkingsflagg, og den modusen kan etterlate genererte runtime-konfigurasjonsfiler på plass når tilkoblingen avsluttes.

Disse filene inneholder autentiseringsmateriale: den forhåndsdelte nøkkelen, legitimasjon eller begge deler. En generert konfigurasjon kopiert inn i et chatvindu er en avsløring av legitimasjon, ikke et loggutdrag. Fjern de hemmelige linjene før du deler noe, og slett katalogen når undersøkelsen er ferdig. Behandle dem som hemmeligheter, trekk ut de spesifikke linjene du trenger for en rapport, og slett dem etterpå i stedet for å lime en katalog inn i en sak.

Den manuelle instansen må også koordineres med den normale. Å starte en feilsøkingskopi mens tjenesten allerede eier plugin-modulen gir to eiere og en logg som blander begge, noe som er verre enn ingen feilsøkingsutdata i det hele tatt.

Gjenopprett den normale hjelperen etterpå

Når undersøkelsen er ferdig, stopp den manuelle instansen, fjern de beholdte runtime-filene og koble til igjen via den normale veien, slik at neste person ser en konfigurasjon som samsvarer med virkeligheten.

Bekreft deretter resultatet i laget som feilet, 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 økt som autentiserer, mottar en adresse og ruter til den tiltenkte destinasjonen, er resultatet du feilsøkte. En stille terminal under et mislykket forsøk forteller deg bare hvor utdataen ikke ble skrevet.