Er L2TP-feilsøkingsloggen tom? Feilen ligg truleg i journalen

Du startar L2TP-hjelparen med feilsøking, ser på terminalen, og han stoppar utan noko nyttig på skjermen. Det er ikkje eit øydelagt feilsøkingsflagg. Ei NetworkManager L2TP-tilkopling er fire samarbeidande prosessar, og berre nokre av dei skriv til terminalen du ser på. Resten av prova ligg i journalen, éin filteravstand unna.

Fire prosessar, to loggmål

Tilkoplinga byrjar med IPsec, som er anten libreswan eller strongSwan avhengig av installasjonen. Deretter køyrer L2TP-demonen, tradisjonelt xl2tpd og i nokre bygg kl2tpd, tunnelen. Til slutt handterer pppd autentisering og adressering inni han.

Hjelpartenesta koordinerer desse delane og skriv ut si eiga framdrift. IPsec-demonen og pppd rapporterer vanlegvis gjennom systemjournalen, og difor viser terminalen ei tilkopling som feilar medan årsaka ligg i ei fil du ikkje har opna.

Denne delinga forklarer òg kvifor ein PSK-feil og ein passordfeil ser like ut frå skrivebordet: begge gir ei generisk fråkopling, og trinnet som feila er berre synleg i utdataen per prosess. Det er heile grunnen til at journalen er viktig her. Éi generisk melding på skrivebordet, fire moglege forfattarar bak henne.

Samle eitt forsøk, og les deretter rekkjefølgja

Reproduser éin gong, med ein kjend profil og eit kjend tidspunkt, og les deretter eit smalt vindauge i staden for heile oppstarten. Gjentekne forsøk medan du endrar innstillingar gjer loggen til ei blanding som ikkje kan tolkast.

Desse kommandoane vel dei deltakande prosessane for gjeldande oppstart, og det er verdt å stadfeste 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

Gjentekne felt i eitt kall vel foreininga av desse prosessane, noko som held rekkjefølgja i tidsorden. På eit Debian-basert system er den tilsvarande spørjinga dpkg -L; poenget er å finne ut kvar hjelparen faktisk bur før du prøver å køyre han manuelt.

Tre vilkår avgjer neste trekk

Les det første trinnet som feilar, og vel deretter. Viss IPsec rapporterer ein feil i forslaget eller i peer-autentiseringa, vart tunnelen aldri danna, og det hjelper ikkje å endre PPP-passordet.

Viss tunnelen vart danna og pppd avviste innlogginga, var den delte løyndomen allereie i orden, og legitimasjonsproblemet ligg eitt lag høgare. Viss pppd forhandla om ei adresse og feilen først viser seg seinare, verkar begge, og det gjenverande problemet er ruting, DNS eller den eigne policyen til tenaren.

Desse tre greinene dekkjer nesten kvar generisk fråkopling, og dei blir avgjorde av kva prosess som logga den siste feilen, ikkje av kva feilmelding som ser mest alarmerande ut.

Det er òg verdt å stadfeste kva IPsec-backend som er installert før du rører ei feilsøkingsinnstilling. Eit loggalternativ skrive for strongSwan gjer ingenting når libreswan køyrer, og tilkoplinga vil halde fram med å feile på same staden medan du redigerer ei fil ingen les.

Feilsøkingsmodus etterlèt filer

Den opphavlege feilsøkingsarbeidsflyten køyrer tenesta manuelt med eit feilsøkingsflagg, og den modusen kan etterlètje genererte runtime-konfigurasjonsfiler på plass når tilkoplinga blir avslutta.

Desse filene inneheld autentiseringsmateriale: den førehandsdelte nøkkelen, legitimasjon eller begge delar. Ein generert konfigurasjon kopiert inn i eit chatvindauge er ei avsløring av legitimasjon, ikkje eit loggutdrag. Fjern dei hemmelege linjene før du deler noko, og slett katalogen når undersøkinga er ferdig. Handsame dei som løyndomar, trekk ut dei spesifikke linjene du treng for ein rapport, og slett dei etterpå i staden for å lime ein katalog inn i ei sak.

Den manuelle instansen må òg koordinerast med den normale. Å starte ein feilsøkingskopi medan tenesta allereie eig plugin-modulen gir to eigarar og ein logg som blandar begge, noko som er verre enn ingen feilsøkingsutdata i det heile.

Gjenopprett den normale hjelparen etterpå

Når undersøkinga er ferdig, stopp den manuelle instansen, fjern dei behaldne runtime-filene og kople til igjen via den normale vegen, slik at neste person ser ein konfigurasjon som svarar til røynda.

Stadfest deretter resultatet i laget som feila, ikkje ved skrivebordsikonet:

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

Ei økt som autentiserer, mottek ei adresse og rutar til den tiltenkte destinasjonen, er resultatet du feilsøkte. Ein stille terminal under eit mislukka forsøk fortel deg berre kvar utdataen ikkje vart skriven.