L2TP-ontfoutlog leeg? Die fout is waarskynlik in die joernaal

Jy begin die L2TP-helper met ontfouting, kyk na die terminaal, en dit stop met niks nuttigs op die skerm nie. Dit is nie ’n gebreekte ontfoutvlag nie. ’n NetworkManager L2TP-verbinding is vier samewerkende prosesse, en net sommige daarvan skryf na die terminaal waarna jy kyk. Die res van die bewyse is in die joernaal, een filter weg.

Vier prosesse, twee logbestemmings

Die verbinding begin met IPsec, wat óf libreswan óf strongSwan is, afhangende van die installasie. Dan hardloop die L2TP-daemon, tradisioneel xl2tpd en in sommige boue kl2tpd, die tonnel. Laastens hanteer pppd authentisering en adressering daarbinne.

Die helperdiens koördineer daardie stukke en druk sy eie vordering. Die IPsec-daemon en pppd rapporteer gewoonlik deur die stelseljoernaal, en daarom wys die terminaal ’n verbinding wat misluk terwyl die rede in ’n lêer sit wat jy nog nie oopgemaak het nie.

Daardie skeiding verduidelik ook waarom ’n PSK-fout en ’n wagwoordfout van die lessenaar af dieselfde lyk: albei lewer ’n generiese ontkoppeling, en die stadium wat misluk het, is net in die per-proses-uitvoer sigbaar. Dit is die hele rede waarom die joernaal hier saak maak. Een generiese boodskap op die lessenaar, vier moontlike outeurs daar agter.

Versamel een poging, lees dan die volgorde

Reproduseer een keer, met ’n bekende profiel en ’n bekende tyd, en lees dan ’n smal venster eerder as die hele selflaai. Herhaalde pogings terwyl jy instellings verander, maak die log ’n mengsel wat nie geïnterpreteer kan word nie.

Hierdie opdragte kies die deelnemende prosesse vir die huidige selflaai, en dit is die moeite werd om die inprop-pad op jou verspreiding te bevestig:

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 velde in een opdrag kies die vereniging van daardie prosesse, wat die volgorde in tydsorde hou. Op ’n Debian-gebaseerde stelsel is die ekwivalente navraag dpkg -L; die punt is om te vind waar die helper werklik woon voordat jy dit met die hand probeer hardloop.

Drie voorwaardes wat die volgende stap bepaal

Lees die eerste mislukte stadium en kies dan dienooreenkomstig. As IPsec ’n voorstel- of eweknie-verifikasiefout rapporteer, het die tonnel nooit gevorm nie, en om die PPP-wagwoord te verander kan nie help nie.

As die tonnel gevorm het en pppd die aanmelding verwerp het, was die gedeelde geheim reeds reg en is die geloofsbriefprobleem een laag hoër. As pppd ’n adres onderhandel het en die fout later verskyn, werk albei van daardie dinge en is die oorblywende probleem roetering, DNS of die bediener se eie beleid.

Daardie drie takke dek byna elke generiese ontkoppeling, en hulle word bepaal deur watter proses die laaste fout gelog het eerder as deur watter foutboodskap die meeste alarm maak.

Dit is ook die moeite werd om te bevestig watter IPsec-agterkant geïnstalleer is voordat jy aan ’n ontfoutinstelling raak. ’n Logopsie wat vir strongSwan geskryf is, doen niks wanneer libreswan loop nie, en die verbinding sal op dieselfde plek bly misluk terwyl jy ’n lêer redigeer wat niks lees nie.

Ontfoutmodus laat lêers agter

Die stroomop-ontfoutwerkvloei hardloop die diens met die hand met ’n ontfoutvlag, en daardie modus kan gegenereerde runtime-konfigurasielêers laat staan wanneer die verbinding eindig.

Daardie lêers bevat verifikasie-materiaal: die vooraf gedeelde sleutel, geloofsbriewe of albei. ’n Gegenereerde konfigurasie wat in ’n kletsvenster gekopieer is, is ’n openbaarmaking van geloofsbriewe, nie ’n log-uittreksel nie. Verwyder die geheime reëls voordat jy enigiets deel, en skrap die gids wanneer die ondersoek eindig. Behandel hulle as geheime, onttrek die spesifieke reëls wat jy vir ’n verslag nodig het, en skrap hulle daarna eerder as om ’n gids in ’n kaartjie te plak.

Die handmatige instansie moet ook met die normale een gekoördineer word. Om ’n ontfoutkopie te begin terwyl die diens reeds die inprop besit, lewer twee eienaars en ’n log wat albei meng, wat erger is as geen ontfoutuitvoer hoegenaamd nie.

Herstel daarna die normale helper

Wanneer die ondersoek eindig, stop die handmatige instansie, verwyder die behoue runtime-lêers en koppel weer via die normale pad sodat die volgende persoon ’n konfigurasie sien wat by die werklikheid pas.

Verifieer dan die resultaat by die laag wat misluk het, nie by die lessenaar-ikoon nie:

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

’n Sessie wat authentiseer, ’n adres ontvang en na die beoogde bestemming roeteer, is die uitkoms waarvoor jy ontfout het. ’n Stille terminaal tydens ’n mislukte poging sê net vir jou waar die uitvoer nie geskryf is nie.