Si arrin një hyrje VPN te RADIUS dhe te ofruesi juaj i identitetit

Javën e kaluar një përdorues mundi të hynte në VPN dhe gjithsesi përfundoi në një rrjet ku asgjë nuk zgjidhej. Klienti thoshte i lidhur, regjistri i portës thoshte Access-Accept, dhe ekipi i identitetit thoshte se llogaria ishte në rregull. Hyrja kishte funksionuar; autorizimi pas saj jo. Kur një hyrje VPN dështon, ndjek rrugën që kërkesa ndjek në të vërtetë — klient, portë, server RADIUS, ofrues identiteti — dhe ndalem në hapin e parë, përgjigjja e të cilit nuk përputhet me atë që vjen pas.

Klienti nuk flet kurrë RADIUS

Çfarëdo që shfaq aplikacioni në laptop, hapi i tij i parë është protokolli VPN: IKEv2, OpenVPN, WireGuard ose një klient i bazuar në TLS. RADIUS nuk shfaqet në atë shkëmbim. Klienti vërtetohet te porta me një certifikatë, një emër përdoruesi dhe fjalëkalim, ose një metodë EAP që transportohet në konfigurimin e tunelit.

Kjo ka rëndësi kur lexoni regjistrat, sepse gabimin e përgjithshëm të vërtetimit që sheh përdoruesi e prodhon porta pasi ka folur tashmë me diçka tjetër. Nëse klienti nuk arrin kurrë te porta, nuk ekziston asnjë kërkesë RADIUS për t'u korrigjuar, dhe një orë e kaluar në serverin RADIUS humbet. Konfirmoni që tuneli u ngrit fare përpara se të prekni backend-in.

Porta është klienti RADIUS

Sapo konfigurimi i tunelit arrin pikën ku duhet të kontrollohen kredencialet, porta bëhet një server aksesi rrjeti. Ndërton një Access-Request: User-Name, një fjalëkalim ose ngarkesë EAP, NAS-IP-Address ose NAS-Identifier, dhe një Message-Authenticator kur metoda kërkon një të tillë. Kërkesa shkon si parazgjedhje te UDP 1812, dhe kontabiliteti te 1813. Instalimet më të vjetra përdorin ende 1645 dhe 1646, prandaj një rregull firewalls i shkruar për një çift shpjegon shumë dështime të heshtura.

Të dyja palët ndajnë një sekret, dhe ai nuk është kredencial përdoruesi. Ai nënshkruan shkëmbimin, dhe çdo përgjigje verifikohet kundrejt tij. Konfiguroni sekretin ndryshe në të dyja palët dhe serveri nuk përgjigjet me sekret të gabuar — e hedh kërkesën ose përgjigjja dështon në verifikim, kështu që porta raporton skadim kohe. Një sekret i gabuar dhe një server i vdekur duken njësoj nga porta, prandaj e provoj hapin me një mjet klienti përpara se të fajësoj drejtorinë.

Protokolli është i vogël dhe i vjetër — RFC 2865 përcakton shkëmbimin e vërtetimit — por atributet që mbart janë baza mbi të cilën është ndërtuar pjesa më e madhe e politikës VPN.

# 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'

Serveri RADIUS mund të jetë vetëm pjesa e përparme e ofruesit të identitetit

Njerëzit flasin për RADIUS dhe ofruesin e identitetit sikur të ishin e njëjta kuti. Shpesh nuk janë. Serveri RADIUS merr Access-Request dhe më pas pyet diçka tjetër — Active Directory përmes LDAP ose Kerberos, një skedar lokal përdoruesish ose një shërbim të jashtëm — përpara se të përgjigjet. FreeRADIUS me modulin LDAP ose krb5, Windows NPS dhe Cisco ISE qëndrojnë të gjithë në këtë pozicion.

Dallimi vendos ku të shikoni. Një fjalëkalim i refuzuar është përgjigje e ofruesit të identitetit e përcjellë nga RADIUS. Skadimi i kohës është zakonisht segmenti RADIUS-drejtori: një llogari bind e skaduar, një drejtori e paarritshme ose një kërkesë e drejtuar te backend i gabuar. Nëse emri i përdoruesit mbart një prapashtesë domeni, serveri mund të routojë mbi të, dhe e njëjta llogari e dërguar si CORP\alice dhe [email protected] mund të përfundojë në vende të ndryshme. Në Windows NPS, regjistri Security shënon 6272 për një lejim dhe 6273 për një refuzim, që ju tregon nëse vendimi erdhi fare nga NPS.

Lexoni dështimin në hapin që e prodhoi

Një mesazh i vetëm nuk mund të lidhet mbulon katër dështime të ndryshme. Përpara se të ndryshoni diçka, përputhni simptomën me hapin që e prodhoi.

Rreshti i fundit është ai që dërgon njerëzit te ekipi i gabuar. Access-Accept do të thotë që kredencialet u pranuan; nuk do të thotë që porta e vendosi përdoruesin në grupin e duhur ose shtyu rrugë. Atributet e grupit kanë rëndësi vetëm nëse politika e portës i lexon ato. Kam parë një hyrje të saktë të përfundojë në një grup mysafirësh, sepse hartëzimi i grupeve ishte konfiguruar në anën RADIUS për një atribut të ndryshëm nga ai që inspekton porta.

Ndiqni një hyrje nga fillimi në fund

Zgjidhni një llogari testimi dhe një portë, pastaj vëzhgoni të njëjtin përpjekje në të katër pikat. Nisni një ekzekutim korrigjimi në anën RADIUS — freeradius -X printon kërkesën dhe çdo modul që prek — ndiqni regjistrin e vërtetimit të portës dhe ekzekutoni tcpdump për shkëmbimin UDP. Lidhuni një herë dhe lexoni katër gjurmët me radhë.

Ajo që doni të shihni është pajtimi: porta pyeti për përdoruesin që prisnit, serveri RADIUS zgjodhi backend-in që prisnit, ai backend ktheu një vendim, dhe atributet në përgjigje përputhen me politikën që zbaton porta. Vendi i parë ku gjurmët nuk pajtohen është linja juaj e defektit. Nëse përgjigjja nuk mbart atribut grupi, problemi është në anën RADIUS, jo në profilin VPN; nëse atributi është aty dhe porta e injoron, problemi është politika e portës.

Një shënim sigurie ndërsa jeni atje. Sekreti i përbashkët mbron shkëmbimin, por nuk kripton shumicën e atributeve. Nëse porta dhe serveri RADIUS janë në segmente të ndryshme, vendoseni atë hap në RADIUS përmes TLS ose një rruge private. Një tunel përdoruesi i kriptuar nuk thotë asgjë për lidhjen me backend-in.

Përpara se të mbyllni tiketën, konfirmoni katër gjëra. Porta arrin serverin RADIUS në portën për të cilën është konfiguruar vërtet. Sekreti i përbashkët përputhet në të dyja palët. Serveri RADIUS zgjidh formën e saktë të emrit të përdoruesit që dërgon porta. Pranimi mbart atributet që politika e portës ka nevojë. Kur të katër vlejnë, një hyrje që ende dështon është problem i politikës së portës, jo i vërtetimit.