L2TP/IPsec feiler: isoler IPsec, tunnelautentisering eller PPP-innlogging

Tre ting autentiseres inne i én L2TP/IPsec-tilkobling, og bare én av dem involverer personen som ringer opp. IPsec beviser tunnelendepunktene, L2TP-kontrollforbindelsen kan bevise partene på nytt med sin egen hemmelighet, og PPP beviser deretter brukerkontoen inne i økten. En feil i hvilket som helst steg ser ut som en generisk innloggingsfeil i klientdialogen og ser helt annerledes ut i en serverlogg. Gå gjennom stegene i rekkefølge og stopp ved det første som feiler, fordi hvert steg under et uutprøvd steg også er uutprøvd.

Tre autentiseringssteg, tre forskjellige identiteter

IPsec beviser hvem som eier endepunktene, ved hjelp av en forhåndsdelt nøkkel eller et sertifikat. Den identiteten tilhører maskiner eller gatewayer, aldri mennesket ved tastaturet. Når partene ikke blir enige i dette steget, utveksles ingen L2TP-pakker i det hele tatt.

L2TP-kontrollforbindelsen kan legge til en andre, separat utfordring-respons-utveksling drevet av en felles hemmelighet som begge ender må ha.

RFC 2661 gjør denne autentiseringen av kontrollforbindelsen valgfri, noe som forklarer hvorfor samme feil gir ulike symptomer på to servere. En utrulling som aldri konfigurerte en tunnelhemmelighet hopper over steget helt; en som konfigurerte den bare på én side, feiler før PPP i det hele tatt tilbys. PPP autentiserer deretter brukeren med PAP, CHAP eller MSCHAPv2 og overlater navnet til et kontolager som kan være lokalt, i chap-secrets eller på RADIUS. Et feil passord på det punktet lar deg fortsatt sitte igjen med en fungerende tunnel og en mislykket økt.

Les stoppunktet før du redigerer en konfigurasjon

Start med ipsec --version så du vet om statusutskriften tilhører strongSwan eller Libreswan. Les deretter serverloggen, ikke klientdialogen, fordi serveren registrerer hvilket steg som nektet.

Én linje avgjør vanligvis saken: en klage på IKE eller forslag er første steg, en melding om kontrollforbindelsen er andre steg, og en avvisning av PPP-metode eller konto er tredje steg. Kopier den linjen inn i saken med tidsstemplet. Gjetting fra klientsiden kaster bort det eneste beviset du allerede har.

Hold nøkkelmateriale og passord utenfor den innlimingen; stegnavnet styrer arbeidet, og en lekket forhåndsdelt nøkkel åpner saken på nytt med verre konsekvenser.

Første steg: har IPsec en assosiasjon?

Kjør ipsec statusall på strongSwan eller ipsec whack --status på Libreswan og se etter en etablert barneassosiasjon med tellere som ikke er null. ip xfrm state viser kjernevisningen på begge. Et installert SA-par med stigende tellere betyr at første steg er ferdig, og du kan gå videre.

Helt fravær av assosiasjon peker på partens adresse, forslagssettet eller den forhåndsdelte nøkkelen, og av og til på en enhet som skriver om UDP 500 mens den slipper UDP 4500. En assosiasjon som etableres og deretter forsvinner etter noen sekunder, er vanligvis et levetidsavvik mellom de to endene og ikke et legitimasjonsproblem. Sjekk om begge sider lister de samme krypterings- og hashforslagene før du skriver noe på nytt. Hvis ikke, vil ingen nøkkel noen gang virke.

Stopp mens assosiasjonen mangler. Å redigere PPP-valg på det punktet endrer ingenting og skjuler den virkelige feilen for neste person.

Andre steg: autentiserte L2TP-kontrollforbindelsen seg?

Når IPsec er oppe, følg med på L2TP-demonen etter en kontrollforbindelse som når etablert tilstand, siden PPP ikke kan begynne før det. En nektelse på kontrollforbindelsen betyr at tunnelhemmeligheten er forskjellig mellom endene, eller at den ene enden krever en hemmelighet den andre aldri sender. Klienter viser ofte ett felt merket shared secret, og det tilhører vanligvis IPsec og ikke L2TP. Å fylle det ut konfigurerer ikke tunnelhemmeligheten, og å tømme det deaktiverer den ikke.

Hvis ingen av sidene har konfigurert en tunnelhemmelighet, hopp over dette steget og behandle feilen på kontrollforbindelsen som et tilgjengelighetsproblem i stedet. Bekreft at UDP 1701 når demonen og at begge ender er enige om samme innkapsling. En brannmurregel skrevet for én av disse to betingelsene er en vanlig årsak til en tilkobling som åpnes halvveis.

Bare en økt som begynner å forhandle PPP, har faktisk passert tunnellsteget.

Tredje steg: avviser PPP kontoen?

En PPP-feil ser annerledes ut utenfra: tunnelen er etablert, økten starter, og demonen logger feil på autentiseringsmetode eller kontonektelse. Les metoden som er navngitt i den meldingen. PAP og CHAP feiler av ulike grunner, og en server som avviser den ene, vil avvise en klient som bare tilbyr den.

På en Linux-server, undersøk valgfilen demonen gir til PPP, vanligvis /etc/ppp/options.xl2tpd, og bekreft hvilke metoder som godtas og hvor kontoer løses opp. Et navn som finnes i RADIUS men ikke i den lokale hemmelighetsfilen, feiler rent og ser ut som et dårlig passord. Sjekk deretter at klienten tilbyr en metode serveren godtar, og ikke en sterkere som serveren nekter å forhandle om. Å endre den forhåndsdelte nøkkelen for å reparere dette steget kaster bort en ettermiddag og endrer ingenting.

Når økten endelig kommer opp, adressetildeling, DNS og ruter er ennå ikke kontrollert, og hver av dem feiler stille på sin egen måte. Hold de tre lagene atskilt i notatene dine: en riktig nøkkel med feil konto feiler alltid, og å reparere ett lag reparerer aldri et annet.