EAP tra VPN-enirejo: kiu finas la metodon

Subtenaj biletoj priskribas malsukcesan VPN-ensaluton kaj RADIUS-politikon, kiu postulas pli fortan metodon, kvazaŭ temas pri la sama problemo, sed ne temas. La enirejo aŭ akceptas akreditilon kaj plusendas ĝin, aŭ ĝi portas EAP-konversacion inter la kliento kaj la aŭtentiga servilo. Kiu el tiuj okazas decidas, ĉu ŝanĝo ĉe la servila flanko povas entute ion ripari. Legu la interŝanĝon antaŭ ol vi redaktos la servilan grupon.

Du aŭtentigaj vojoj, kiuj aspektas same en protokolo

En la unua vojo la VPN-enirejo kolektas uzantnomon kaj pasvorton kaj sendas RADIUS Access-Request kun pasvorta atributo. La aŭtentiga servilo komparas ĝin kun sia akreditila konservejo kaj respondas per akcepto aŭ rifuzo. La kliento neniam rulas EAP-metodon, ĉar nenio petis tion.

En la dua vojo la kliento kaj la aŭtentiga servilo rulas la EAP-metodon de komenco ĝis fino, kaj la enirejo plusendas atributojn EAP-Message inter ili. La enirejo ankoraŭ finas la eksteran RADIUS-konversacion, sed la logiko de la metodo loĝas ĉe la du finpunktoj.

Ambaŭ vojoj produktas linion en protokolo, kiu diras, ke aŭtentigo malsukcesis. Nur la dua povas esti tuŝita de tio, kiun EAP-metodon la servilo preferas, kaj nur la unua de tio, kiel la enirejo legas la pasvorton. Trakti ilin kiel interŝanĝeblaj estas kial teamoj pasigas tagon ŝanĝante servilajn grupojn por kliento, kiu neniam parolus PEAP.

Kie la metodo efektive rulas

RFC 3579 difinas la trapasan aranĝon: la NAS portas EAP-paketojn en RADIUS-atributoj kaj ne bezonas metod-specifan kodon por ĉiu EAP-tipo. Tial enirejo povas subteni PEAP kaj EAP-TLS sen efektivigi iun ajn.

Enirejo, kiu sendas pasvorton, ne portas PEAP, eĉ se la malantaŭa sistemo akceptus PEAP de alia kliento. Ŝalti PEAP en la servila politiko ne aldonas metodon al kliento, kiu neniam proponis unu.

PPP-aŭtentigaj agordoj apartenas al la PPP-servo. Ili ne silenteme reagordas ĉiun IPsec- aŭ malnovan XAuth-vojon, kiu uzas la saman AAA-servilon, do ŝanĝo, kiu funkcias por unu alirtipo, povas lasi la alian netuŝita.

Kion la NAS devas subteni

Trapaso movas la postulon de metodkodo al portila subteno. La enirejo devas povi porti EAP tra sia VPN-protokolo, kaj la RADIUS-kliento sur ĝi devas povi sendi kaj ricevi atributojn EAP-Message de la koncernaj grandecoj.

Por IKEv2 EAP estas parto de difinita aŭtentiga fluo, kaj la kontroloj de identeco kaj fido de la servilo venas de tiu fluo. Etikedo PEAP pruntita el 802.1X-a deplojo ne transiĝas aŭtomate, ĉar la intertraktado ĉirkaŭ ĝi malsamas.

Ankaŭ la klienta flanko havas postulojn. Ĝi devas esti agordita por la metodo, fidi la servilan atestilon, kiun la metodo prezentas, kaj havi akreditilojn, kiujn la metodo povas uzi. Atestila metodo sen klienta atestilo paneas antaŭ ol RADIUS vidas ion ajn, kio estas proviza problemo, ne servila politiko.

Legu unu provon antaŭ ol ŝanĝi politikon

Kaptu unu aprobitan provon ĉe la enirejo kaj ĉe la aŭtentiga servilo. Serĉu atributojn EAP-Message en la RADIUS-peto. Ilia ĉeesto diras, ke la trapasa vojo estas uzata; ilia foresto indikas akreditilan interŝanĝon.

Ĉe Linux-enirejo kapto sur la RADIUS-pordo montras, kiuj atributoj estas sur la drato:

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

Poste komparu la rifuzan punkton. Malsukceso ĉe la enirejo antaŭ iu ajn RADIUS-paketo signifas, ke la kliento kaj la enirejo ne interkonsentis pri la metodo. RADIUS-rifuzo kun EAP-atributoj signifas, ke la finpunktoj rulis la metodon kaj unu el ili rifuzis la rezulton.

Planu la migradon kiel unu ŝanĝon de komenco ĝis fino

Ŝanĝi la metodon signifas ŝanĝi kune la klientan agordon, la portilan subtenon de la enirejo, la metodan politikon de la servilo kaj la akreditilan konservejon. Faru tion en tiu ordo kaj tenu funkciantan vojon, ĝis la nova estos pruvita. Ŝanĝo nur ĉe la servila flanko estas konjekto, kaj ĝi kutime rompas la klientojn, kiuj funkciis. Preparu la ŝanĝon sur unu testa identeco antaŭ ol tuŝi la grupon.

Notu la kombinon, kiu funkcias: VPN-protokolo, EAP-portilo, metoda de la partnero, servila metodo, tipo de akreditilo kaj kontrolo de servila identeco.

Tenu administran AAA-ensaluton aparte de VPN-aŭtentigo, krom se la tasko eksplicite inkluzivas ambaŭ. Ŝanĝo celanta malproksiman aliron ne devus forpreni vian kapablon administri la aparaton, kiu ĝin finas.