L2TP/IPsec eșuează: izolați IPsec, autentificarea tunelului sau autentificarea PPP

Trei lucruri se autentifică într-o singură conexiune L2TP/IPsec, iar doar unul dintre ele îl implică pe omul care formează numărul. IPsec dovedește capetele tunelului, conexiunea de control L2TP poate dovedi din nou partenerii cu propriul secret, iar apoi PPP dovedește contul de utilizator din interiorul sesiunii. O defecțiune la orice etapă arată ca o eroare generică de autentificare în fereastra clientului și arată complet diferit în jurnalul serverului. Parcurgeți etapele în ordine și opriți-vă la prima care eșuează, pentru că fiecare etapă de sub una netestată este și ea netestată.

Trei etape de autentificare, trei identități diferite

IPsec dovedește cine deține capetele, folosind o cheie prepartajată sau un certificat. Acea identitate aparține mașinilor sau gateway-urilor, niciodată omului de la tastatură. Când partenerii nu se pot înțelege la această etapă, nu se schimbă deloc niciun pachet L2TP.

Conexiunea de control L2TP poate adăuga un al doilea schimb provocare-răspuns, separat, condus de un secret comun pe care trebuie să îl aibă ambele capete.

RFC 2661 face acea autentificare a conexiunii de control opțională, ceea ce explică de ce aceeași greșeală produce simptome diferite pe două servere. O implementare care nu a configurat niciodată un secret de tunel sare peste etapă complet; una care l-a configurat doar pe o parte eșuează înainte ca PPP să fie oferit. Apoi PPP autentifică utilizatorul cu PAP, CHAP sau MSCHAPv2 și predă numele unui depozit de conturi care poate fi local, în chap-secrets sau pe RADIUS. O parolă greșită în acel punct vă lasă totuși cu un tunel funcțional și o sesiune eșuată.

Citiți punctul de oprire înainte de a edita o configurație

Începeți cu ipsec --version ca să știți dacă ieșirea de stare aparține strongSwan sau Libreswan. Apoi citiți jurnalul serverului, nu fereastra clientului, pentru că serverul notează care etapă a refuzat.

O singură linie rezolvă de obicei tichetul: o plângere despre IKE sau propuneri este etapa unu, un mesaj despre conexiunea de control este etapa doi, iar o respingere a metodei PPP sau a contului este etapa trei. Copiați acea linie în tichet împreună cu marcajul de timp. Ghiceala din partea clientului irosește singura dovadă pe care o aveți deja.

Țineți materialul de cheie și parolele în afara acelei lipiri; numele etapei direcționează munca, iar o cheie prepartajată scursă redeschide tichetul cu consecințe mai rele.

Etapa unu: are IPsec o asociere?

Rulați ipsec statusall pe strongSwan sau ipsec whack --status pe Libreswan și căutați o asociere copil stabilită, cu contoare diferite de zero. ip xfrm state arată viziunea nucleului pe ambele. O pereche de SA instalată cu contoare care urcă înseamnă că etapa unu este gata și puteți merge mai departe.

Absența totală a asocierii indică adresa partenerului, setul de propuneri sau cheia prepartajată, și uneori un dispozitiv care rescrie UDP 500 dar aruncă UDP 4500. O asociere care se stabilește și apoi dispare după câteva secunde este de obicei o nepotrivire a duratei de viață între cele două capete, nu o problemă de acreditări. Verificați dacă ambele părți listează aceleași propuneri de criptare și hash înainte de a tasta ceva din nou. Dacă nu, nicio cheie nu va funcționa vreodată.

Opriți-vă cât timp asociația lipsește. Editarea opțiunilor PPP în acel punct nu schimbă nimic și ascunde defectul real de următoarea persoană.

Etapa doi: s-a autentificat conexiunea de control L2TP?

După ce IPsec este sus, urmăriți daemonul L2TP pentru o conexiune de control care atinge starea stabilită, fiindcă PPP nu poate începe înainte de asta. Un refuz pe conexiunea de control înseamnă că secretul tunelului diferă între capete sau că un capăt cere un secret pe care celălalt nu îl trimite niciodată. Clienții expun adesea un singur câmp etichetat shared secret, iar acesta aparține de obicei IPsec și nu L2TP. Completarea lui nu configurează secretul tunelului, iar ștergerea lui nu îl dezactivează.

Dacă niciuna dintre părți nu a configurat un secret de tunel, săriți peste această etapă și tratați eșecul conexiunii de control ca o problemă de accesibilitate. Confirmați că UDP 1701 ajunge la daemon și că ambele capete sunt de acord asupra aceleiași încapsulări. O regulă de firewall scrisă pentru una dintre aceste două condiții este o cauză obișnuită a unei conexiuni care se deschide pe jumătate.

Doar o sesiune care începe să negocieze PPP a trecut cu adevărat de etapa tunelului.

Etapa trei: PPP respinge contul?

O defecțiune PPP arată altfel din exterior: tunelul este stabilit, sesiunea începe, iar daemonul înregistrează o eroare a metodei de autentificare sau o respingere a contului. Citiți metoda numită în acel mesaj. PAP și CHAP eșuează din motive diferite, iar un server care refuză una va refuza un client care oferă doar aceea.

Pe un server Linux, inspectați fișierul de opțiuni pe care daemonul îl dă PPP, de obicei /etc/ppp/options.xl2tpd, și confirmați ce metode sunt acceptate și unde sunt rezolvate conturile. Un nume care există în RADIUS dar nu în fișierul local de secrete eșuează curat și arată ca o parolă greșită. Apoi verificați că clientul oferă o metodă acceptată de server, nu una mai puternică pe care serverul refuză să o negocieze. Schimbarea cheii prepartajate pentru a repara această etapă irosește o după-amiază și nu schimbă nimic.

Când sesiunea urcă în sfârșit, atribuirea adreselor, DNS și rutele nu au fost încă verificate, și fiecare eșuează în liniște în felul ei. Țineți cele trei straturi separate în notițele voastre: o cheie corectă cu un cont greșit eșuează întotdeauna, iar repararea unui strat nu o repară niciodată pe alta.