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

Tre ting autentiserer seg inne i éi L2TP/IPsec-tilkopling, og berre éin av dei involverer personen som ringjer opp. IPsec provar tunnelendepunkta, L2TP-kontrolltilkoplinga kan prova partane på nytt med si eiga løyndom, og PPP provar deretter brukarkontoen inne i økta. Ein feil i kva som helst steg ser ut som ein generisk innloggingsfeil i klientdialogen og ser heilt annleis ut i ein serverlogg. Gå gjennom stega i rekkjefølgje og stopp ved det første som feilar, fordi kvart steg under eit uprøvd steg også er uprøvd.

Tre autentiseringssteg, tre ulike identitetar

IPsec provar kven som eig endepunkta, ved hjelp av ein førehandsdel nøkkel eller eit sertifikat. Den identiteten høyrer til maskinar eller gatewayar, aldri mennesket ved tastaturet. Når partane ikkje blir samde i dette steget, blir ingen L2TP-pakkar bytte i det heile.

L2TP-kontrolltilkoplinga kan leggje til ei andre, separat utfordring-respons-utveksling driven av ein felles løyndom som begge endar må ha.

RFC 2661 gjer denne autentiseringa av kontrolltilkoplinga valfri, noko som forklarer kvifor same feil gir ulike symptom på to servarar. Ei utrulling som aldri konfigurerte ein tunnelløyndom hoppar over steget heilt; ei som konfigurerte han berre på éi side, feilar før PPP i det heile blir tilbode. PPP autentiserer deretter brukaren med PAP, CHAP eller MSCHAPv2 og overlèt namnet til eit kontolager som kan vera lokalt, i chap-secrets eller på RADIUS. Eit feil passord på det punktet lèt deg framleis sitje att med ein fungerande tunnel og ei mislukka økt.

Les stoppunktet før du endrar ein konfigurasjon

Start med ipsec --version så du veit om statusutskrifta høyrer til strongSwan eller Libreswan. Les deretter serverloggen, ikkje klientdialogen, fordi serveren registrerer kva steg som nekta.

Éi linje avgjer vanlegvis saka: ei klage på IKE eller forslag er første steg, ei melding om kontrolltilkoplinga er andre steg, og ei avvising av PPP-metode eller konto er tredje steg. Kopier den linja inn i saka med tidsstempelet. Gjetting frå klientsida kastar bort det einaste beviset du allereie har.

Hald nøkkelmateriale og passord utanfor den innliminga; stegnamnet styrer arbeidet, og ein lekt førehandsdel nøkkel opnar saka på nytt med verre følgjer.

Første steg: har IPsec ein assosiasjon?

Køyr ipsec statusall på strongSwan eller ipsec whack --status på Libreswan og sjå etter ein etablert barneassosiasjon med teljarar som ikkje er null. ip xfrm state viser kjernevisninga på begge. Eit installert SA-par med stigande teljarar tyder på at første steg er ferdig, og du kan gå vidare.

Heilt fråvær av assosiasjon peikar på adressa til parten, forslagssettet eller den førehandsdeldte nøkkelen, og av og til på ein eining som skriv om UDP 500 medan ho slepp UDP 4500. Ein assosiasjon som blir etablert og deretter forsvinn etter nokre sekund, er vanlegvis eit levealdavvik mellom dei to endane og ikkje eit legitimasjonsproblem. Sjekk om begge sider listar dei same krypterings- og hashforslaga før du skriv noko på nytt. Viss ikkje, vil ingen nøkkel nokon gong verke.

Stopp medan assosiasjonen manglar. Å endre PPP-val på det punktet endrar ingenting og skjuler den verkelege feilen for neste person.

Andre steg: autentiserte L2TP-kontrolltilkoplinga seg?

Når IPsec er oppe, følg med på L2TP-demonen etter ei kontrolltilkopling som når etablert tilstand, sidan PPP ikkje kan byrje før det. Ei nekting på kontrolltilkoplinga tyder på at tunnelløyndomen er ulik mellom endane, eller at den eine enden krev ein løyndom den andre aldri sender. Klientar viser ofte eitt felt merkt shared secret, og det høyrer vanlegvis til IPsec og ikkje L2TP. Å fylle det ut konfigurerer ikkje tunnelløyndomen, og å tøme det deaktiverer han ikkje.

Viss ingen av sidene har konfigurert ein tunnelløyndom, hopp over dette steget og handsam feilen på kontrolltilkoplinga som eit tilgjengeproblem i staden. Stadfest at UDP 1701 når demonen og at begge endar er samde om same innkapsling. Ein brannmurregel skriven for éin av desse to vilkåra er ein vanleg årsak til ei tilkopling som opnar halvvegs.

Berre ei økt som byrjar å forhandle PPP, har faktisk passert tunnellsteget.

Tredje steg: avviser PPP kontoen?

Ein PPP-feil ser annleis ut utanfrå: tunnelen er etablert, økta byrjar, og demonen loggar feil på autentiseringsmetode eller kontonekting. Les metoden som er namngitt i den meldinga. PAP og CHAP feilar av ulike grunnar, og ein server som avviser den eine, vil avvise ein klient som berre tilbyr den.

På ein Linux-server, undersøk valfilen demonen gir til PPP, vanlegvis /etc/ppp/options.xl2tpd, og stadfest kva metodar som blir godtekne og kvar kontoar blir løyste opp. Eit namn som finst i RADIUS men ikkje i den lokale løyndomsfila, feilar reint og ser ut som eit dårleg passord. Sjekk deretter at klienten tilbyr ein metode serveren godtek, og ikkje ein sterkare som serveren nektar å forhandle om. Å endre den førehandsdeldte nøkkelen for å reparere dette steget kastar bort ein ettermiddag og endrar ingenting.

Når økta endeleg kjem opp, adressetildeling, DNS og ruter er enno ikkje kontrollerte, og kvar av dei feilar stille på sin eigen måte. Hald dei tre laga åtskilde i notata dine: ein riktig nøkkel med feil konto feilar alltid, og å reparere eitt lag reparerer aldri eit anna.