Tom L2TP-felsökningslogg? Felet ligger antagligen i journalen

Du startar L2TP-hjälparen med felsökning, tittar på terminalen, och den stannar utan något användbart på skärmen. Det är inte en trasig felsökningsflagga. En NetworkManager L2TP-anslutning är fyra samverkande processer, och bara några av dem skriver till terminalen du tittar på. Resten av bevisen finns i journalen, ett filter bort.

Fyra processer, två loggdestinationer

Anslutningen börjar med IPsec, som är antingen libreswan eller strongSwan beroende på installationen. Sedan kör L2TP-demonen, traditionellt xl2tpd och i vissa byggen kl2tpd, tunneln. Till sist hanterar pppd autentisering och adressering inuti den.

Hjälptjänsten samordnar dessa delar och skriver ut sin egen framdrift. IPsec-demonen och pppd rapporterar vanligtvis via systemjournalen, och därför visar terminalen en anslutning som misslyckas medan orsaken ligger i en fil du inte har öppnat.

Den uppdelningen förklarar också varför ett PSK-fel och ett lösenordsfel ser likadana ut från skrivbordet: båda ger en generisk frånkoppling, och steget som misslyckades syns bara i utdatan per process. Det är hela anledningen till att journalen spelar roll här. Ett generiskt meddelande på skrivbordet, fyra möjliga författare bakom det.

Samla ett försök och läs sedan ordningen

Reproducera en gång, med en känd profil och en känd tidpunkt, och läs sedan ett smalt fönster i stället för hela uppstarten. Upprepade försök medan du ändrar inställningar gör loggen till en blandning som inte går att tolka.

Dessa kommandon väljer de deltagande processerna för aktuell uppstart, och plugin-sökvägen är värd att bekräfta 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

Upprepade fält i ett anrop väljer föreningen av dessa processer, vilket håller ordningen i tidsordning. På ett Debian-baserat system är motsvarande fråga dpkg -L; poängen är att ta reda på var hjälparen faktiskt bor innan du försöker köra den för hand.

Tre villkor avgör nästa steg

Läs det första steget som misslyckas och välj därefter. Om IPsec rapporterar ett fel i förslaget eller i peer-autentiseringen bildades tunneln aldrig, och att ändra PPP-lösenordet kan inte hjälpa.

Om tunneln bildades och pppd avvisade inloggningen var den delade hemligheten redan i ordning, och problemet med inloggningsuppgifterna ligger ett lager högre. Om pppd förhandlade om en adress och felet först dyker upp senare fungerar båda, och det återstående problemet är routning, DNS eller serverns egen policy.

Dessa tre grenar täcker nästan varje generisk frånkoppling, och de avgörs av vilken process som loggade det senaste felet, inte av vilket felmeddelande som ser mest alarmerande ut.

Det är också värt att bekräfta vilken IPsec-backend som är installerad innan du rör en felsökningsinställning. Ett loggalternativ skrivet för strongSwan gör ingenting när libreswan körs, och anslutningen fortsätter att misslyckas på samma ställe medan du redigerar en fil som ingen läser.

Felsökningsläget lämnar filer efter sig

Det ursprungliga felsökningsarbetsflödet kör tjänsten för hand med en felsökningsflagga, och det läget kan lämna genererade runtime-konfigurationsfiler på plats när anslutningen avslutas.

Dessa filer innehåller autentiseringsmaterial: den fördelade nyckeln, inloggningsuppgifter eller båda. En genererad konfiguration som kopieras till ett chattfönster är ett avslöjande av inloggningsuppgifter, inte ett loggutdrag. Ta bort de hemliga raderna innan du delar något och radera katalogen när undersökningen är klar. Behandla dem som hemligheter, extrahera de specifika raderna du behöver för en rapport och radera dem efteråt i stället för att klistra in en katalog i ett ärende.

Den manuella instansen måste också samordnas med den normala. Att starta en felsökningskopia medan tjänsten redan äger plugin-modulen ger två ägare och en logg som blandar båda, vilket är värre än ingen felsökningsutdata alls.

Återställ sedan den normala hjälparen

När undersökningen är klar, stoppa den manuella instansen, ta bort de bevarade runtime-filerna och anslut igen via den normala vägen så att nästa person ser en konfiguration som stämmer med verkligheten.

Verifiera sedan resultatet i lagret som misslyckades, inte vid skrivbordsikonen:

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

En session som autentiserar, tar emot en adress och routar till den avsedda destinationen är resultatet du felsökte. En tyst terminal under ett misslyckat försök säger dig bara var utdatan inte skrevs.