L2TP/IPsec fejler: isolér IPsec, tunnelgodkendelse eller PPP-login

Inde i én L2TP/IPsec-forbindelse godkendes tre ting, og kun én af dem involverer personen, der ringer op. IPsec beviser tunnellens endepunkter, L2TP-kontrolforbindelsen kan bevise parterne igen med sin egen hemmelighed, og derefter beviser PPP brugerkontoen inde i sessionen. En fejl på et hvilket som helst trin ser ud som en generel loginfejl i klientdialogen og ser helt anderledes ud i en serverlog. Gå trinnene igennem i rækkefølge, og stop ved det første, der fejler, fordi hvert trin under et utestet trin også er utestet.

Tre godkendelsestrin, tre forskellige identiteter

IPsec beviser, hvem der ejer endepunkterne, ved hjælp af en forudelt nøgle eller et certifikat. Den identitet tilhører maskiner eller gateways, aldrig mennesket ved tastaturet. Når parterne ikke kan blive enige på dette trin, udveksles der slet ingen L2TP-pakke.

L2TP-kontrolforbindelsen kan tilføje en anden, separat udfordring-svar-udveksling drevet af en fælles hemmelighed, som begge ender skal have.

RFC 2661 gør den kontrolforbindelsesgodkendelse valgfri, hvilket forklarer, hvorfor den samme fejl giver forskellige symptomer på to servere. En installation, der aldrig har konfigureret en tunnelhemmelighed, springer trinnet helt over; en, der har konfigureret den på kun én side, fejler, før PPP overhovedet tilbydes. Derefter godkender PPP brugeren med PAP, CHAP eller MSCHAPv2 og giver navnet videre til et kontolager, der kan være lokalt, i chap-secrets eller på RADIUS. En forkert adgangskode på det punkt efterlader dig stadig med en fungerende tunnel og en mislykket session.

Læs stoppunktet, før du redigerer en konfiguration

Begynd med ipsec --version, så du ved, om statusoutputtet tilhører strongSwan eller Libreswan. Læs derefter serverloggen, ikke klientdialogen, fordi serveren registrerer, hvilket trin der afviste.

Én linje afgør som regel sagen: en klage over IKE eller forslagene er trin et, en meddelelse om kontrolforbindelsen er trin to, og en afvisning af PPP-metode eller konto er trin tre. Kopiér den linje ind i sagen sammen med tidsstemplet. At gætte fra klientsiden spilder det ene bevis, du allerede har.

Hold nøglemateriale og adgangskoder ude af den indsættelse; trinnets navn styrer arbejdet, og en lækket forudelt nøgle genåbner sagen med værre konsekvenser.

Trin et: har IPsec en association?

Kør ipsec statusall på strongSwan eller ipsec whack --status på Libreswan, og se efter en etableret underordnet association med tællere, der ikke er nul. ip xfrm state viser kernens billede på begge. Et installeret SA-par med stigende tællere betyder, at trin et er klaret, og du kan gå videre.

Slet ingen association peger på partnens adresse, forslagssættet eller den forudelte nøgle og indimellem på en enhed, der omskriver UDP 500, mens den dropper UDP 4500. En association, der etableres og derefter forsvinder efter få sekunder, er normalt en levetidsuoverensstemmelse mellem de to ender og ikke et legitimationsproblem. Kontrollér, om begge sider angiver de samme krypterings- og hashforslag, før du skriver noget om. Hvis ikke, vil ingen nøgle nogensinde virke.

Stop, mens associationen mangler. At redigere PPP-indstillinger på det punkt ændrer intet og skjuler den rigtige fejl for den næste person.

Trin to: godkendte L2TP-kontrolforbindelsen sig?

Når IPsec er oppe, hold øje med L2TP-dæmonen for en kontrolforbindelse, der når en etableret tilstand, fordi PPP ikke kan begynde før det. En afvisning på kontrolforbindelsen betyder, at tunnelhemmeligheden er forskellig mellem enderne, eller at den ene ende kræver en hemmelighed, som den anden aldrig sender. Klienter viser ofte et enkelt felt mærket fælles hemmelighed, og det hører normalt til IPsec og ikke til L2TP. At udfylde det konfigurerer ikke tunnelhemmeligheden, og at rydde det deaktiverer den ikke.

Hvis ingen af siderne har en tunnelhemmelighed konfigureret, spring dette trin over, og behandl en fejl på kontrolforbindelsen som et tilgængelighedsproblem i stedet. Bekræft, at UDP 1701 når dæmonen, og at begge ender er enige om den samme indkapsling. En firewallregel skrevet til en af disse to betingelser er en hyppig årsag til en forbindelse, der kun åbner halvt.

Kun en session, der begynder at forhandle PPP, har faktisk passeret tunnellaget.

Trin tre: afviser PPP kontoen?

En PPP-fejl ser anderledes ud udefra: tunnelen er etableret, sessionen starter, og dæmonen logger en fejl i godkendelsesmetoden eller en afvisning af kontoen. Læs den metode, der nævnes i den meddelelse. PAP og CHAP fejler af forskellige grunde, og en server, der afviser den ene, vil afvise en klient, der kun tilbyder den.

På en Linux-server skal du gennemgå den indstillingsfil, dæmonen giver videre til PPP, typisk /etc/ppp/options.xl2tpd, og bekræfte, hvilke metoder der accepteres, og hvor konti slås op. Et navn, der findes i RADIUS men ikke i den lokale hemmelighedsfil, fejler rent og ligner en dårlig adgangskode. Kontrollér derefter, at klienten tilbyder en metode, som serveren accepterer, i stedet for en stærkere, som serveren nægter at forhandle om. At ændre den forudelte nøgle for at reparere dette trin spilder en eftermiddag og ændrer intet.

Når sessionen endelig kommer op, er tildeling af adresser, DNS og ruter stadig ikke kontrolleret, og hver af dem fejler lydløst på sin egen måde. Hold de tre lag adskilt i dine noter: en korrekt nøgle med en forkert konto fejler altid, og at reparere ét lag reparerer aldrig et andet.