EAP printr-o poartă VPN: cine termină metoda

Tichetele de asistență descriu o conectare VPN eșuată și o politică RADIUS care cere o metodă mai puternică de parcă ar fi aceeași problemă, iar nu sunt. Poarta fie acceptă acreditările și le transmite, fie duce o conversație EAP între client și serverul de autentificare. Care dintre ele se întâmplă decide dacă o schimbare pe partea serverului poate repara ceva. Citiți schimbul înainte de a edita grupul de servere.

Două căi de autentificare care arată la fel în jurnal

Pe prima cale, poarta VPN colectează un nume de utilizator și o parolă și trimite un RADIUS Access-Request cu un atribut de parolă. Serverul de autentificare îl compară cu depozitul său și răspunde acceptat sau respins. Clientul nu rulează niciodată o metodă EAP, pentru că nimic nu i-a cerut asta.

Pe a doua cale, clientul și serverul de autentificare rulează metoda EAP de la un capăt la altul, iar poarta transmite atribute EAP-Message între ele. Poarta termină în continuare conversația RADIUS exterioară, dar logica metodei se află la cele două capete.

Ambele căi produc o linie în jurnal care spune că autentificarea a eșuat. Doar a doua poate fi afectată de metoda EAP preferată de server, iar doar prima de modul în care poarta citește parola. A le trata ca interschimbabile este motivul pentru care echipele petrec o zi schimbând grupuri de servere pentru un client care nu avea să vorbească niciodată PEAP.

Unde rulează de fapt metoda

RFC 3579 definește aranjamentul de trecere: NAS-ul poartă pachete EAP în atribute RADIUS și nu are nevoie de cod specific metodei pentru fiecare tip EAP. De aceea o poartă poate accepta PEAP și EAP-TLS fără să implementeze niciuna.

O poartă care trimite o parolă nu poartă PEAP, chiar dacă backend-ul ar accepta PEAP de la alt client. Activarea PEAP în politica serverului nu adaugă o metodă unui client care nu a oferit niciodată una.

Setările de autentificare PPP aparțin serviciului PPP. Ele nu reconfigurează în tăcere fiecare cale IPsec sau XAuth veche care folosește același server AAA, așa că o schimbare care funcționează pentru un tip de acces o poate lăsa pe cealaltă neatinsă.

Ce trebuie să accepte NAS-ul

Trecerea mută cerința de la codul metodei la suportul purtătorului. Poarta trebuie să poată purta EAP prin protocolul său VPN, iar clientul RADIUS de pe ea trebuie să poată trimite și primi atribute EAP-Message de dimensiunile respective.

În IKEv2, EAP face parte dintr-un flux de autentificare definit, iar verificările de identitate și încredere ale serverului vin din acel flux. O etichetă PEAP împrumutată dintr-o implementare 802.1X nu se transferă automat, pentru că negocierea din jurul ei este diferită.

Și partea clientului are cerințe. Trebuie să fie configurată pentru metodă, să aibă încredere în certificatul serverului pe care metoda îl prezintă și să aibă acreditări pe care metoda le poate folosi. O metodă bazată pe certificate fără certificat de client eșuează înainte ca RADIUS să vadă ceva, iar aceasta este o problemă de aprovizionare, nu de politică a serverului.

Citiți o încercare înainte de a schimba politica

Capturați o singură încercare aprobată la poartă și la serverul de autentificare. Căutați atribute EAP-Message în cererea RADIUS. Prezența lor spune că se folosește calea de trecere; absența lor indică un schimb de acreditări.

Pe o poartă Linux, o captură pe portul RADIUS arată ce atribute sunt pe fir:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Apoi comparați punctul de respingere. Un eșec la poartă înainte de orice pachet RADIUS înseamnă că clientul și poarta nu au fost de acord asupra metodei. O respingere RADIUS cu atribute EAP înseamnă că extremitățile au rulat metoda și una dintre ele a refuzat rezultatul.

Planificați migrarea ca o singură schimbare de la un capăt la altul

Schimbarea metodei înseamnă schimbarea împreună a configurației clientului, a suportului purtătorului la poartă, a politicii metodei pe server și a depozitului de acreditări. Faceți-o în această ordine și păstrați o cale funcțională până când cea nouă este dovedită. O schimbare doar pe partea serverului este o presupunere și de obicei strică clienții care funcționau. Pregătiți schimbarea pe o singură identitate de test înainte de a atinge grupul.

Notați combinația care funcționează: protocol VPN, purtător EAP, metoda partenerului, metoda serverului, tipul de acreditare și verificarea identității serverului.

Țineți AAA de conectare administrativă separat de autentificarea VPN, dacă sarcina nu le include explicit pe amândouă. O schimbare destinată accesului la distanță nu ar trebui să vă ia capacitatea de a administra dispozitivul care o termină.