L2TP/IPsec ne radi: izolirajte IPsec, autentikaciju tunela ili PPP prijavu

Tri se stvari autentificiraju unutar jedne L2TP/IPsec veze, a samo jedna uključuje osobu koja se spaja. IPsec dokazuje krajnje točke tunela, L2TP kontrolna veza može ponovno dokazati partnere vlastitom tajnom, a PPP zatim dokazuje korisnički račun unutar sesije. Neuspjeh u bilo kojoj fazi izgleda kao generička pogreška prijave u dijalogu klijenta, a u zapisu poslužitelja izgleda potpuno drugačije. Prođite faze redom i zaustavite se na prvoj koja ne uspije, jer je svaka faza ispod neprovjerene također neprovjerena.

Tri faze autentikacije, tri različita identiteta

IPsec dokazuje čije su 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 složiti u ovoj fazi, nijedan L2TP paket se uopće ne razmjenjuje.

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

RFC 2661 čini tu autentikaciju kontrolne veze neobveznom, što objašnjava zašto ista pogreška daje različite simptome na dva poslužitelja. Implementacija koja nikada nije konfigurirala tajnu tunela potpuno preskače fazu; ona koja ju je konfigurirala samo na jednoj strani pada prije nego što se PPP uopće ponudi. PPP zatim autentificira korisnika s 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 ipak vas ostavlja s ispravnim tunelom i neuspjelom sesijom.

Pročitajte točku zaustavljanja prije uređivanja konfiguracije

Počnite s ipsec --version kako biste znali pripada li izlaz statusa strongSwanu ili Libreswanu. Zatim čitajte zapis poslužitelja, a ne dijalog klijenta, jer poslužitelj bilježi koja je faza odbila.

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

Držite ključni materijal i lozinke izvan tog zalijepljenog teksta; naziv faze usmjerava posao, a procurjeli unaprijed dijeljeni ključ ponovno otvara zahtjev s gorim posljedicama.

Prva faza: ima li IPsec asocijaciju?

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

Potpuni izostanak asocijacije upućuje na adresu partnera, skup prijedloga ili unaprijed dijeljeni ključ, a povremeno i 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 trajanja između dvaju krajeva, a ne problem s vjerodajnicama. Provjerite navode li obje strane iste prijedloge šifriranja i hasha prije nego što išta ponovno upišete. Ako ne navode, nijedan ključ nikada neće raditi.

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

Druga faza: je li se L2TP kontrolna veza autentificirala?

Kad je IPsec aktivan, promatrajte L2TP daemon radi kontrolne veze 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 da jedan kraj traži tajnu koju drugi nikada ne šalje. Klijenti često izlažu jedno polje s oznakom shared secret, a ono obično pripada IPsecu, a ne L2TP-u. Ispunjavanje tog polja ne konfigurira tajnu tunela, a brisanje ga ne onemogućuje.

Ako nijedna strana nema konfiguriranu tajnu tunela, preskočite ovu fazu i neuspjeh kontrolne veze tretirajte kao problem dostupnosti. Potvrdite da UDP 1701 dolazi do daemona i da se oba kraja slažu o istom enkapsuliranju. Pravilo vatrozida napisano za jedan od tih dvaju uvjeta čest je uzrok veze koja se otvara napola.

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

Treća faza: odbija li PPP račun?

Neuspjeh PPP-a izvana izgleda drugačije: tunel je uspostavljen, sesija počinje, a daemon bilježi neuspjeh metode autentikacije ili odbijanje računa. Pročitajte metodu navedenu u toj poruci. PAP i CHAP padaju iz različitih razloga, a poslužitelj koji odbije jednu odbit će klijenta koji nudi samo tu.

Na Linux poslužitelju pregledajte datoteku opcija koju daemon 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, čisto pada i izgleda kao loša lozinka. Zatim provjerite nudi li klijent metodu koju poslužitelj prihvaća, a ne jaču koju poslužitelj odbija pregovarati. Promjena unaprijed dijeljenog ključa radi popravka ove faze troši poslijepodne i ništa ne mijenja.

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