EAP caur VPN vārteju: kas pabeidz metodi

Atbalsta pieteikumi apraksta neizdevušos VPN pieteikšanos un RADIUS politiku, kas prasa spēcīgāku metodi, it kā tā būtu viena problēma, bet tā nav. Vārteja vai nu pieņem akreditācijas datus un pārsūta tos, vai arī vada EAP sarunu starp klientu un autentifikācijas serveri. Tas, kurš no abiem notiek, nosaka, vai servera puses izmaiņas vispār var kaut ko salabot. Izlasiet apmaiņu pirms servera grupas rediģēšanas.

Divi autentifikācijas ceļi, kas žurnālā izskatās vienādi

Pirmajā ceļā VPN vārteja savāc lietotājvārdu un paroli un nosūta RADIUS Access-Request ar paroles atribūtu. Autentifikācijas serveris salīdzina to ar savu krātuvi un atbild pieņemt vai noraidīt. Klients nekad neizpilda EAP metodi, jo neviens to nav prasījis.

Otrajā ceļā klients un autentifikācijas serveris izpilda EAP metodi no sākuma līdz beigām, un vārteja pārsūta EAP-Message atribūtus starp tiem. Vārteja joprojām pabeidz ārējo RADIUS sarunu, bet metodes loģika mīt abos galos.

Abi ceļi žurnālā rada rindu, ka autentifikācija nav izdevusies. Tikai otro var ietekmēt tas, kuru EAP metodi serveris dod priekšroku, un tikai pirmo – tas, kā vārteja nolasa paroli. Uzskatīt tos par aizvietojamiem ir iemesls, kāpēc komandas pavada dienu, mainot servera grupas klientam, kurš nekad neplānoja runāt PEAP.

Kur metode faktiski darbojas

RFC 3579 definē caurejošo kārtību: NAS pārnēsā EAP paketes RADIUS atribūtos un tam nav vajadzīgs metodei specifisks kods katram EAP tipam. Tāpēc vārteja var atbalstīt PEAP un EAP-TLS, neieviešot nevienu no tiem.

Vārteja, kas iesniedz paroli, nepārnēsā PEAP, pat ja aizmugures sistēma pieņemtu PEAP no cita klienta. PEAP iespējošana servera politikā nepievieno metodi klientam, kurš nekad nav to piedāvājis.

PPP autentifikācijas iestatījumi pieder PPP pakalpojumam. Tie klusām nepārkonfigurē katru IPsec vai veco XAuth ceļu, kas izmanto to pašu AAA serveri, tāpēc izmaiņas, kas darbojas vienam piekļuves veidam, var atstāt otru neskartu.

Kas NAS ir jāatbalsta

Caureja pārvieto prasību no metodes koda uz nesēja atbalstu. Vārtejai ir jāspēj pārnēsāt EAP pa savu VPN protokolu, un RADIUS klientam uz tās – sūtīt un saņemt attiecīgā izmēra EAP-Message atribūtus.

IKEv2 gadījumā EAP ir daļa no definētas autentifikācijas plūsmas, un servera identitātes un uzticamības pārbaudes nāk no šīs plūsmas. PEAP etiķete, kas aizgūta no 802.1X ieviešanas, automātiski nepārnesas, jo sarunas ap to atšķiras.

Arī klienta pusei ir prasības. Tam jābūt konfigurētam metodei, jāuzticas servera sertifikātam, ko metode uzrāda, un jābūt akreditācijas datiem, ko metode var izmantot. Uz sertifikātiem balstīta metode bez klienta sertifikāta neizdodas, pirms RADIUS kaut ko ierauga, un tā ir nodrošināšanas, nevis servera politikas problēma.

Izlasiet vienu mēģinājumu pirms politikas maiņas

Ierakstiet vienu apstiprinātu mēģinājumu vārtejā un autentifikācijas serverī. Meklējiet EAP-Message atribūtus RADIUS pieprasījumā. To klātbūtne norāda, ka tiek izmantots caurejas ceļš; to trūkums norāda uz akreditācijas datu apmaiņu.

Linux vārtejā ieraksts RADIUS portā parāda, kuri atribūti ir uz līnijas:

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

Pēc tam salīdziniet noraidīšanas punktu. Neveiksme vārtejā pirms jebkura RADIUS paketes nozīmē, ka klients un vārteja nav vienojušies par metodi. RADIUS noraidījums ar EAP atribūtiem nozīmē, ka gali izpildīja metodi un viens no tiem noraidīja rezultātu.

Plānojiet migrāciju kā vienu izmaiņu no sākuma līdz beigām

Metodes maiņa nozīmē kopīgi mainīt klienta konfigurāciju, vārtejas nesēja atbalstu, servera metodes politiku un akreditācijas datu krātuvi. Dariet to šādā secībā un saglabājiet strādājošu ceļu, līdz jaunais ir pierādīts. Izmaiņas tikai servera pusē ir minējums, un tās parasti salauž klientus, kas strādāja. Sagatavojiet izmaiņas vienā testa identitātē pirms grupas aizskaršanas.

Pierakstiet kombināciju, kas darbojas: VPN protokols, EAP nesējs, partnera metode, servera metode, akreditācijas datu tips un servera identitātes pārbaude.

Turiet administratīvo AAA pieteikšanos atsevišķi no VPN autentifikācijas, ja vien uzdevums skaidri neietver abus. Attālinātai piekļuvei paredzētām izmaiņām nevajadzētu atņemt iespēju pārvaldīt ierīci, kas to pabeidz.