EAP përmes një portali VPN: kush e përfundon metodën

Tiketat e ndihmës përshkruajnë një hyrje VPN të dështuar dhe një politikë RADIUS që kërkon një metodë më të fortë sikur të ishte i njëjti problem, dhe nuk është. Portali ose pranon kredencialet dhe i përcjell, ose mban një bisedë EAP midis klientit dhe serverit të vërtetimit. Cila prej tyre ndodh vendos nëse një ndryshim në anën e serverit mund të rregullojë gjë. Lexoni shkëmbimin përpara se të redaktoni grupin e serverit.

Dy rrugë vërtetimi që duken njësoj në regjistër

Në rrugën e parë portali VPN mbledh një emër përdoruesi dhe një fjalëkalim dhe dërgon një RADIUS Access-Request me një atribut fjalëkalimi. Serveri i vërtetimit e krahason me depon e vet dhe përgjigjet prano ose refuzo. Klienti nuk ekzekuton kurrë një metodë EAP, sepse asgjë nuk ia kërkoi.

Në rrugën e dytë klienti dhe serveri i vërtetimit ekzekutojnë metodën EAP nga fillimi në fund, dhe portali përcjell atribute EAP-Message midis tyre. Portali vazhdon të përfundojë bisedën e jashtme RADIUS, por logjika e metodës jeton në dy skajet.

Të dyja rrugët prodhojnë një rresht në regjistër që thotë se vërtetimi dështoi. Vetëm e dyta mund të ndikohet nga metoda EAP që preferon serveri, dhe vetëm e para nga mënyra se si portali e lexon fjalëkalimin. T'i trajtosh si të këmbyeshme është arsyeja pse ekipet kalojnë një ditë duke ndryshuar grupe serveri për një klient që nuk do të fliste kurrë PEAP.

Ku ekzekutohet në të vërtetë metoda

RFC 3579 përcakton skemën e përcjelljes: NAS mban paketa EAP në atribute RADIUS dhe nuk ka nevojë për kod specifik të metodës për çdo lloj EAP. Prandaj një portal mund të mbështesë PEAP dhe EAP-TLS pa zbatuar asnjërën.

Një portal që dërgon një fjalëkalim nuk mban PEAP, edhe sikur backend-i të pranonte PEAP nga një klient tjetër. Aktivizimi i PEAP në politikën e serverit nuk shton një metodë për një klient që nuk ofroi kurrë një të tillë.

Cilësimet e vërtetimit PPP i përkasin shërbimit PPP. Ato nuk rikonfigurojnë në heshtje çdo rrugë IPsec ose XAuth të vjetër që përdor të njëjtin server AAA, kështu që një ndryshim që funksionon për një lloj aksesi mund ta lërë tjetrin të paprekur.

Çfarë duhet të mbështesë NAS

Përcjellja e zhvendos kërkesën nga kodi i metodës te mbështetja e bartësit. Portali duhet të mund të mbajë EAP përmes protokollit të vet VPN, dhe klienti RADIUS mbi të duhet të mund të dërgojë e të marrë atribute EAP-Message të madhësive përkatëse.

Për IKEv2, EAP është pjesë e një rrjedhe të përcaktuar vërtetimi, dhe kontrollet e identitetit e të besimit të serverit vijnë nga ajo rrjedhë. Një etiketë PEAP e huazuar nga një vendosje 802.1X nuk transferohet automatikisht, sepse negociimi rreth saj është i ndryshëm.

Edhe ana e klientit ka kërkesa. Duhet të jetë konfiguruar për metodën, t'i besojë certifikatës së serverit që paraqet metoda dhe të ketë kredenciale që metoda mund t'i përdorë. Një metodë e bazuar në certifikata pa certifikatë klienti dështon përpara se RADIUS të shohë gjë, dhe ky është problem furnizimi, jo i politikës së serverit.

Lexoni një tentativë përpara se të ndryshoni politikën

Kapni një tentativë të aprovuar të vetme në portal dhe në serverin e vërtetimit. Kërkoni atribute EAP-Message në kërkesën RADIUS. Prania e tyre thotë se rruga e përcjelljes është në përdorim; mungesa e tyre të drejton te një shkëmbim kredencialesh.

Në një portal Linux, një kapje në portën RADIUS tregon cilat atribute janë në tel:

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

Pastaj krahasoni pikën e refuzimit. Një dështim në portal përpara çdo pakete RADIUS do të thotë që klienti dhe portali nuk u morën vesh për metodën. Një refuzim RADIUS që mban atribute EAP do të thotë që skajet ekzekutuan metodën dhe njëri prej tyre e refuzoi rezultatin.

Planifikoni migrimin si një ndryshim të vetëm nga fillimi në fund

Ndryshimi i metodës do të thotë të ndryshohen bashkë konfigurimi i klientit, mbështetja e bartësit në portal, politika e metodës në server dhe depoja e kredencialeve. Bëjeni në atë rend dhe mbani një rrugë funksionale derisa ajo e reja të provohet. Një ndryshim vetëm në anën e serverit është hamendësim dhe zakonisht prish klientët që punonin. Përgatisni ndryshimin në një identitet prove përpara se të prekni grupin.

Shkruani kombinimin që funksionon: protokolli VPN, bartësi EAP, metoda e palës tjetër, metoda e serverit, lloji i kredencialeve dhe kontrolli i identitetit të serverit.

Mbajeni AAA-në e hyrjes administrative të ndarë nga vërtetimi VPN, përveç rasteve kur detyra i përfshin shprehimisht të dyja. Një ndryshim i destinuar për akses në distancë nuk duhet t'ju marrë aftësinë për të administruar pajisjen që e përfundon atë.