L2TP-debuglog leeg? De fout zit waarschijnlijk in het journal

U start de L2TP-helper met debugging, kijkt naar de terminal, en hij stopt zonder iets bruikbaars op het scherm. Dat is geen kapotte debug-vlag. Een NetworkManager L2TP-verbinding bestaat uit vier samenwerkende processen, en alleen sommige daarvan schrijven naar de terminal die u bekijkt. De rest van het bewijs staat in het journal, één filter verwijderd.

Vier processen, twee logbestemmingen

De verbinding begint met IPsec, dat afhankelijk van de installatie libreswan of strongSwan is. Daarna draait de L2TP-daemon, traditioneel xl2tpd en in sommige builds kl2tpd, de tunnel. Ten slotte regelt pppd de authenticatie en adressering daarbinnen.

De helpdienst coördineert die onderdelen en print zijn eigen voortgang. De IPsec-daemon en pppd rapporteren meestal via het systeemjournal, en daarom toont de terminal een verbinding die mislukt terwijl de reden in een bestand staat dat u niet hebt geopend.

Die splitsing verklaart ook waarom een PSK-fout en een wachtwoordfout er vanaf de desktop hetzelfde uitzien: beide leveren een generieke verbreking, en de fase die mislukte is alleen zichtbaar in de uitvoer per proces. Dat is de hele reden waarom het journal hier belangrijk is. Eén generiek bericht op de desktop, vier mogelijke auteurs erachter.

Verzamel één poging en lees dan de volgorde

Reproduceer één keer, met een bekend profiel en een bekend tijdstip, en lees dan een smal venster in plaats van de hele opstart. Pogingen herhalen terwijl u instellingen wijzigt maakt van het log een mengsel dat niet te interpreteren is.

Deze opdrachten selecteren de deelnemende processen voor de huidige opstart, en het is de moeite waard het pluginpad op uw distributie te bevestigen:

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

Herhaalde velden in één aanroep selecteren de vereniging van die processen, wat de volgorde in tijdvolgorde houdt. Op een Debian-gebaseerd systeem is de equivalente query dpkg -L; het punt is te achterhalen waar de helper werkelijk woont voordat u hem met de hand probeert te draaien.

Drie voorwaarden bepalen de volgende stap

Lees de eerste mislukte fase en kies daarna. Als IPsec een fout in het voorstel of in de peer-authenticatie meldt, is de tunnel nooit gevormd, en het PPP-wachtwoord wijzigen kan niet helpen.

Als de tunnel is gevormd en pppd de aanmelding heeft geweigerd, was het gedeelde geheim al in orde en zit het probleem met de inloggegevens een laag hoger. Als pppd een adres heeft onderhandeld en de fout pas later verschijnt, werken beide en is het resterende probleem routing, DNS of het eigen beleid van de server.

Die drie takken dekken bijna elke generieke verbreking, en ze worden bepaald door welk proces de laatste fout logde, niet door welke foutmelding het meest alarmerend lijkt.

Het is ook de moeite waard te bevestigen welke IPsec-backend is geïnstalleerd voordat u een debuginstelling aanraakt. Een logoptie die voor strongSwan is geschreven doet niets wanneer libreswan draait, en de verbinding blijft op dezelfde plek mislukken terwijl u een bestand bewerkt dat niemand leest.

Debugmodus laat bestanden achter

De oorspronkelijke debugworkflow start de dienst handmatig met een debugvlag, en die modus kan bij het einde van de verbinding gegenereerde runtime-configuratiebestanden achterlaten.

Die bestanden bevatten authenticatiemateriaal: de vooraf gedeelde sleutel, inloggegevens of beide. Een gegenereerde configuratie die in een chatvenster wordt gekopieerd is een onthulling van inloggegevens, geen logfragment. Verwijder de geheime regels voordat u iets deelt, en verwijder de map wanneer het onderzoek eindigt. Behandel ze als geheimen, haal de specifieke regels eruit die u voor een rapport nodig hebt, en verwijder ze daarna in plaats van een map in een ticket te plakken.

De handmatige instantie moet ook met de normale worden afgestemd. Een debugkopie starten terwijl de dienst de plugin al bezit geeft twee eigenaren en een log dat beide mengt, wat erger is dan helemaal geen debuguitvoer.

Herstel daarna de normale helper

Wanneer het onderzoek eindigt, stop de handmatige instantie, verwijder de bewaarde runtime-bestanden en maak opnieuw verbinding via het normale pad, zodat de volgende persoon een configuratie ziet die bij de werkelijkheid past.

Controleer daarna het resultaat in de laag die mislukte, niet bij het bureaubladpictogram:

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

Een sessie die authenticeert, een adres ontvangt en naar de bedoelde bestemming routeert is het resultaat dat u aan het debuggen was. Een stille terminal tijdens een mislukte poging vertelt u alleen waar de uitvoer niet is geschreven.