Nola iristen da VPN saio-hasiera RADIUSera eta zure identitate-hornitzailearengana
Jarraitu VPN saio-hasiera bat bezeroarengandik atebidearen RADIUS eskaerara, haren atzeko identitate-hornitzaileara eta onarpenaren ondoren aplikatzen den politikara.
Joan den astean erabiltzaile batek VPNan saioa hasi zuen eta, hala ere, ezer ebazten ez zen sare batera iritsi zen. Bezeroak konektatuta zioen, atebidearen erregistroak Access-Accept zioen eta identitate-taldeak kontua ondo zegoela zioen. Saio-hasierak funtzionatu zuen; haren atzeko baimenak ez. VPN saio-hasierak huts egiten duenean, eskaerak benetan egiten duen bidea jarraitzen dut — bezeroa, atebidea, RADIUS zerbitzaria, identitate-hornitzailea — eta hurrengoarekin bat ez datorren lehen jauzian gelditzen naiz.
Bezeroak ez du inoiz RADIUS hitz egiten
Eramangarriko aplikazioak zer erakusten duen ere, haren lehen jauzia VPN protokoloa da: IKEv2, OpenVPN, WireGuard edo TLSn oinarritutako bezeroa. RADIUS ez da truke horretan agertzen. Bezeroa atebidearen aurrean autentifikatzen da ziurtagiri batekin, erabiltzaile-izen eta pasahitz batekin edo tunelaren konfigurazioaren barruan eramaten den EAP metodo batekin.
Hori garrantzitsua da erregistroak irakurtzean, erabiltzaileak ikusten duen autentifikazio-errore orokorra atebideak sortzen duelako, dagoeneko beste zerbaiti hitz egin ondoren. Bezeroa inoiz atebidera iristen ez bada, ez dago arazteko RADIUS eskaerarik, eta RADIUS zerbitzarian emandako ordu bat alferrik galtzen da. Egiaztatu tunela behintzat altxatu zela backendari ukitu aurretik.
Atebidea da RADIUS bezeroa
Tunelaren konfigurazioa kredentzialak egiaztatu behar diren puntura iristen denean, atebidea sareko sarbide zerbitzari bihurtzen da. Access-Request bat eraikitzen du: User-Name, pasahitz edo EAP karga bat, NAS-IP-Address edo NAS-Identifier, eta Message-Authenticator bat metodoak eskatzen duenean. Eskaera UDP 1812ra doa lehenespenez, eta kontabilitatea 1813ra. Instalazio zaharrek oraindik 1645 eta 1646 erabiltzen dituzte, beraz bikote baterako idatzitako suebaki arauak isilpeko hutsegite asko azaltzen ditu.
Bi aldeek sekretu bat partekatzen dute, eta ez da erabiltzaile kredentziala. Trukea sinatzen du, eta erantzun bakoitza haren aurka egiaztatzen da. Konfiguratu sekretua desberdin bi aldeetan eta zerbitzariak ez du sekretu txarrarekin erantzuten — eskaera baztertzen du edo erantzunak egiaztapena huts egiten du, eta atebideak denbora-muga jakinarazten du. Sekretu okerra eta zerbitzari hila berdinak dirudite atebidetik, horregatik jauzia bezero tresna batekin probatzen dut direktorioa erruduntzat jo aurretik.
Protokoloa txikia eta zaharra da — RFC 2865-ek autentifikazio trukea definitzen du —, baina daramatzan atributuak VPN politikaren zatirik handiena oinarritzen dena dira.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS zerbitzaria identitate-hornitzailearen aurrealdea baino ez izan daiteke
Jendeak RADIUS eta identitate-hornitzailea kaxa bera balira bezala hitz egiten du. Askotan ez dira. RADIUS zerbitzariak Access-Request jasotzen du eta gero beste zerbaiti galdetzen dio — Active Directory LDAP edo Kerberosen bidez, tokiko erabiltzaile fitxategi bat edo kanpoko zerbitzu bat — erantzun aurretik. FreeRADIUS LDAP edo krb5 moduluarekin, Windows NPS eta Cisco ISE denak posizio horretan daude.
Bereizketak erabakitzen du non begiratu. Baztertutako pasahitz bat RADIUSek birbidaltzen duen identitate-hornitzailearen erantzuna da. Denbora-muga normalean RADIUSetik direktorioko tartea da: iraungitako bind kontua, iristezin den direktorioa edo backend okerreko eskaera. Erabiltzaile-izenak domeinu atzizki bat badu, zerbitzariak horren arabera bidera dezake, eta CORP\alice eta [email protected] gisa bidalitako kontu bera leku desberdinetan amaitu daiteke. Windows NPSn, Security erregistroak 6272 idazten du emateko eta 6273 ukatzeko, eta horrek esaten dizu erabakia NPSetik etorri zen ala ez.
Irakurri hutsegitea sortu zuen jauzian
Konektatu-ezin mezu bakar batek lau hutsegite desberdin estaltzen ditu. Ezer aldatu aurretik, lotu sintoma sortu zuen jauziarekin.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
Azken errenkada da jendea talde okerrengana bidaltzen duena. Access-Acceptek kredentzialak onartu zirela esan nahi du; ez du esan nahi atebideak erabiltzailea pool egokian jarri zuenik edo bideak bultzatu zituenik. Talde atributuek garrantzia dute atebidearen politikak irakurtzen baditu. Saio-hasiera zuzen bat gonbidatu pool batean erortzen ikusi dut, talde-mapa RADIUS aldean atebideak aztertzen duenaren atributu desberdin baterako konfiguratuta zegoelako.
Jarraitu saio-hasiera bat hasieratik amaierara
Aukeratu probako kontu bat eta atebide bat, eta gero ikusi saiakera bera lau puntuetan. Hasi arazketa exekuzio bat RADIUS aldean — freeradius -Xek eskaera eta ukitzen duen modulu bakoitza inprimatzen du — jarraitu atebidearen autentifikazio erregistroa eta exekutatu tcpdump UDP trukerako. Konektatu behin eta irakurri lau aztarnak ordenan.
Ikusi nahi duzuna adostasuna da: atebideak espero zenuen erabiltzailearen berri galdetu zuen, RADIUS zerbitzariak espero zenuen backend aukeratu zuen, backend horrek erabaki bat itzuli zuen, eta erantzuneko atributuak atebideak aplikatzen duen politikarekin bat datoz. Aztarnak bat ez datozen lehen tokia zure hutsegite-lerroa da. Erantzunak ez badu talde atributurik eramaten, arazoa RADIUS aldean dago, ez VPN profilean; atributua han badago eta atebideak alde batera uzten badu, atebidearen politika da arazoa.
Segurtasun ohar bat han zauden bitartean. Sekretu partekatuak trukea babesten du, baina ez ditu atributu gehienak zifratzen. Atebidea eta RADIUS zerbitzaria segmentu desberdinetan badaude, jarri jauzi hori RADIUSen TLS gainean edo bide pribatu batean. Erabiltzaile tunel zifratuak ez du ezer esaten backend estekari buruz.
Tiketa itxi aurretik, egiaztatu lau gauza. Atebidea RADIUS zerbitzarira irits daiteke benetan konfiguratuta dagoen atakara. Sekretu partekatua bi aldeetan bat dator. RADIUS zerbitzariak atebideak bidaltzen duen erabiltzaile-izenaren forma zehatza ebazten du. Onarpenak atebidearen politikak behar dituen atributuak daramatza. Lauak betetzen direnean, oraindik huts egiten duen saio-hasiera bat atebidearen politikaren arazoa da, ez autentifikazioarena.