L2TP/IPsec ne uspijeva: izolirajte IPsec, autentifikaciju tunela ili PPP prijavu

Unutar jedne L2TP/IPsec veze autentificiraju se tri stvari, a samo jedna od njih uključuje osobu koja se javlja. IPsec dokazuje krajnje točke tunela, kontrolna veza L2TP može ponovno dokazati partnere vlastitom tajnom, a zatim PPP dokazuje korisnički račun unutar sesije. Neuspjeh u bilo kojoj fazi izgleda kao opća greška prijave u klijentskom dijalogu, a u serverskom dnevniku izgleda potpuno drugačije. Prođite kroz faze redom i zaustavite se na prvoj koja ne uspije, jer je svaka faza ispod neprovjerene također neprovjerena.

Tri faze autentifikacije, tri različita identiteta

IPsec dokazuje kome pripadaju krajnje točke, koristeći unaprijed dijeljeni ključ ili certifikat. Taj identitet pripada strojevima ili pristupnicima, nikada čovjeku za tipkovnicom. Kada se partneri ne mogu dogovoriti u ovoj fazi, nijedan L2TP paket se uopće ne razmjenjuje.

Kontrolna veza L2TP može dodati drugu, odvojenu razmjenu izazova i odgovora koju pokreće zajednička tajna i koju moraju imati oba kraja.

RFC 2661 čini tu autentifikaciju kontrolne veze opcionalnom, što objašnjava zašto ista greška daje različite simptome na dva servera. Postavka koja nikada nije konfigurirala tajnu tunela potpuno preskače fazu; ona koja ju je postavila samo na jednoj strani ne uspije prije nego što PPP uopće bude ponuđen. PPP zatim autentificira korisnika pomoću PAP, CHAP ili MSCHAPv2 i predaje ime spremištu računa koje može biti lokalno, u chap-secrets ili na RADIUS-u. Pogrešna lozinka u tom trenutku i dalje vas ostavlja s tunelom koji radi i sesijom koja nije uspjela.

Pročitajte točku zaustavljanja prije nego uredite konfiguraciju

Počnite s ipsec --version kako biste znali pripada li izlaz statusa strongSwanu ili Libreswanu. Zatim čitajte serverski dnevnik, a ne klijentski dijalog, jer server bilježi koja je faza odbila.

Jedna linija obično riješi tiket: pritužba na IKE ili na prijedloge je prva faza, poruka kontrolne veze je druga, a odbijanje PPP metode ili računa je treća. Kopirajte tu liniju u tiket s vremenskom oznakom. Pogađanje s klijentske strane troši jedini dokaz koji već imate.

Držite ključni materijal i lozinke izvan tog kopiranja; naziv faze usmjerava posao, a procurio unaprijed dijeljeni ključ ponovno otvara tiket s gorim posljedicama.

Prvi korak: ima li IPsec asocijaciju?

Pokrenite ipsec statusall na strongSwanu ili ipsec whack --status na Libreswanu i tražite uspostavljenu podređenu asocijaciju s brojačima različitim od nule. ip xfrm state prikazuje pogled jezgre na oba. Instalirani par SA s brojačima koji rastu znači da je prva faza gotova i da možete nastaviti.

Potpuno odsustvo asocijacije upućuje na adresu partnera, skup prijedloga ili unaprijed dijeljeni ključ, a ponekad na uređaj koji prepisuje UDP 500 dok odbacuje UDP 4500. Asocijacija koja se uspostavi i zatim nestane nakon nekoliko sekundi obično je nesklad u trajanju između dvaju krajeva, a ne problem s vjerodajnicama. Provjerite navode li obje strane iste prijedloge za šifriranje i sažimanje prije nego što bilo što prepišete. Ako ne navode, nijedan ključ nikada neće raditi.

Zaustavite se dok asocijacija nedostaje. Uređivanje PPP opcija u tom trenutku ne mijenja ništa i skriva pravi kvar od sljedeće osobe.

Drugi korak: je li se kontrolna veza L2TP autentificirala?

Kad IPsec bude podignut, promatrajte L2TP demon za kontrolnu vezu koja dosegne uspostavljeno stanje, jer PPP ne može početi prije toga. Odbijanje na kontrolnoj vezi znači da se tajna tunela razlikuje između krajeva ili jedan kraj traži tajnu koju drugi nikada ne šalje. Klijenti često izlažu jedno polje s oznakom zajednička tajna, a ono obično pripada IPsecu, a ne L2TP-u. Ispunjavanje tog polja ne konfigurira tajnu tunela, a brisanje je ne onemogućuje.

Ako nijedna strana nema konfiguriranu tajnu tunela, preskočite ovu fazu i neuspjeh kontrolne veze tretirajte kao dostupnost. Potvrdite da UDP 1701 stiže do demona i da se oba kraja slažu o istoj enkapsulaciji. Pravilo vatrozida napisano za jedan od tih dvaju uvjeta čest je uzrok veze koja se otvara napola.

Samo sesija koja počne pregovarati PPP doista je prošla fazu tunela.

Treći korak: odbija li PPP račun?

Neuspjeh PPP-a izvana izgleda drugačije: tunel je uspostavljen, sesija počinje, a demon bilježi neuspjeh metode autentifikacije ili odbijanje računa. Pročitajte metodu navedenu u toj poruci. PAP i CHAP ne uspijevaju iz različitih razloga, a server koji odbija jednu odbit će klijenta koji nudi samo nju.

Na Linux serveru pregledajte datoteku opcija koju demon predaje PPP-u, obično /etc/ppp/options.xl2tpd, i potvrdite koje se metode prihvaćaju i gdje se računi rješavaju. Ime koje postoji u RADIUS-u ali ne u lokalnoj datoteci tajni ne uspijeva čisto i izgleda kao loša lozinka. Zatim provjerite nudi li klijent metodu koju server prihvaća, a ne jaču koju server odbija pregovarati. Mijenjanje unaprijed dijeljenog ključa da bi se popravila ova faza gubi poslijepodne i ne mijenja ništa.

Kad se sesija konačno podigne, dodjela adresa, DNS i rute još su neprovjereni, i svaki od njih tiho ne uspijeva na svoj način. Držite tri sloja odvojeno u bilješkama: ispravan ključ s pogrešnim računom uvijek ne uspijeva, a popravak jednog sloja nikada ne popravlja drugi.