Hvernig VPN-innskráning berst til RADIUS og auðkennisveitandans þíns

Í síðustu viku gat notandi skráð sig inn á VPN og lenti samt á neti þar sem ekkert leystist. Biðlarinn sagði tengt, log gáttarinnar sagði Access-Accept og auðkennisteymið sagði að reikningurinn væri í lagi. Innskráningin hafði virkað; heimildin bak við hana ekki. Þegar VPN-innskráning mistekst fer ég leiðina sem beiðnin fer í raun — biðlari, gátt, RADIUS-þjónn, auðkennisveitandi — og stöðva við fyrsta stökkið þar sem svarið stemmir ekki við það næsta.

Biðlarinn talar aldrei RADIUS

Hvað sem appið á fartölvunni sýnir er fyrsta stökkið VPN-samskiptareglan: IKEv2, OpenVPN, WireGuard eða TLS-undirstaða biðlari. RADIUS kemur ekki fyrir í þeim skiptum. Biðlarinn auðkennir sig við gáttina með skírteini, notandanafni og lykilorði eða EAP-aðferð sem borin er inni í uppsetningu göngunnar.

Það skiptir máli þegar log eru lesin, því almenna auðkenningarvillan sem notandinn sér er framleidd af gáttinni eftir að hún hefur þegar talað við eitthvað annað. Ef biðlarinn nær aldrei að gáttinni er engin RADIUS-beiðni til að kemba, og klukkustund á RADIUS-þjóninum er eyðsla. Staðfestu að göngin hafi yfirhöfuð risið áður en þú snertir bakendann.

Gáttin er RADIUS-biðlarinn

Um leið og uppsetning ganganna nær þeim punkti þar sem auðkenni verða að vera athuguð verður gáttin að netaðgangsþjóni. Hún byggir Access-Request: User-Name, lykilorð eða EAP-farm, NAS-IP-Address eða NAS-Identifier og Message-Authenticator þegar aðferðin krefst þess. Beiðnin fer sjálfgefið á UDP 1812 og bókhaldið á 1813. Eldri uppsetningar nota enn 1645 og 1646, svo eldveggjarregla skrifuð fyrir eitt par útskýrir marga hljóðlausa mistök.

Báðir aðilar deila leyndarmáli og það er ekki notandaauðkenni. Það undirritar skiptin og hvert svar er staðfest gegn því. Stilltu leyndarmálið ólíkt á báðum hliðum og þjónninn svarar ekki með slæmu leyndarmáli — hann hendir beiðninni eða svarið stenst ekki staðfestinguna, svo gáttin tilkynnir tímaútrun. Rangt leyndarmál og dauður þjónn líta eins út frá gáttinni, þess vegna prófa ég stökkið með biðlaratæki áður en ég kenni skránni um.

Samskiptareglan er lítil og gömul — RFC 2865 skilgreinir auðkenningarskiptin — en eiginleikarnir sem hún ber eru undirstaðan sem mest VPN-stefna byggir á.

# 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-þjónninn gæti aðeins verið framhlið auðkennisveitandans

Fólk talar um RADIUS og auðkennisveitanda eins og þeir séu sami kassinn. Oft eru þeir það ekki. RADIUS-þjónninn tekur við Access-Request og spyr svo eitthvað annað — Active Directory um LDAP eða Kerberos, staðbundna notendaskrá eða ytri þjónustu — áður en hann svarar. FreeRADIUS með LDAP- eða krb5-einingunni, Windows NPS og Cisco ISE standa öll á þessum stað.

Munurinn ræður því hvar þú leitar. Hafnað lykilorð er svar auðkennisveitandans sem RADIUS miðlar. Tímaútrun er venjulega kaflinn RADIUS-til-skrár: útrunnið bind-reikningur, óaðgengileg skrá eða beiðni beint á rangan bakenda. Ef notandanafnið ber léna viðskeyti getur þjónninn beint eftir því, og sami reikningur sendur sem CORP\alice og [email protected] getur lent á mismunandi stöðum. Í Windows NPS skráir Security-log 6272 fyrir veitingu og 6273 fyrir synjun, sem segir þér hvort ákvörðunin kom yfirhöfuð frá NPS.

Lestu mistökin á því stökki sem framleiddi þau

Ein skilaboð um að geta ekki tengst ná yfir fjögur mismunandi mistök. Áður en þú breytir einhverju skaltu para einkennin við stökkið sem framleiddi þau.

Síðasta röðin er sú sem sendir fólk til ranga teymisins. Access-Accept þýðir að auðkennin voru samþykkt; það þýðir ekki að gáttin hafi sett notandann í rétta laugina eða ýtt leiðum. Hópaeiginleikar skipta máli aðeins ef stefna gáttarinnar les þá. Ég hef séð rétta innskráningu lenda í gestalaug vegna þess að hópavörpun var stillt á RADIUS-hliðinni fyrir annan eiginleika en þann sem gáttin skoðar.

Fylgdu einni innskráningu frá upphafi til enda

Veldu einn prófunarreikning og eina gátt og fylgstu svo með sömu tilraun á öllum fjórum punktum. Byrjaðu kembingu á RADIUS-hliðinni — freeradius -X prentar beiðnina og hverja einingu sem hún snertir — fylgdu auðkenningarlogi gáttarinnar og keyrðu tcpdump fyrir UDP-skiptin. Tenging einu sinni og lestu fjögur sporin í röð.

Það sem þú vilt sjá er samkomulag: gáttin spurði um notandann sem þú bjóst við, RADIUS-þjónninn valdi bakendann sem þú bjóst við, sá bakendi skilaði ákvörðun og eiginleikarnir í svarinu samræmast stefnunni sem gáttin beitir. Fyrsti staðurinn þar sem spornin greinir á er bilunarlínan þín. Ef svarið ber engan hópaeiginleika er vandamálið á RADIUS-hliðinni, ekki í VPN-sniðinu; ef eiginleikinn er þar og gáttin hunsar hann er stefna gáttarinnar vandamálið.

Ein öryggisathugasemd meðan þú ert þar. Sameiginlega leyndarmálið verndar skiptin en það dulkóðar ekki flesta eiginleika. Ef gáttin og RADIUS-þjónninn eru á mismunandi hlutum skaltu setja það stökk á RADIUS yfir TLS eða einkaleið. Dulkóðuð notendagöng segja ekkert um bakendatenginguna.

Áður en þú lokar miðanum skaltu staðfesta fjóra hluti. Gáttin nær að RADIUS-þjóninum á þeirri gátt sem hún er í raun stillt á. Sameiginlega leyndarmálið stemmir á báðum hliðum. RADIUS-þjónninn leysir nákvæma mynd notandanafnsins sem gáttin sendir. Samþykkið ber eiginleikana sem stefna gáttarinnar þarf. Þegar allir fjórir standast er innskráning sem mistekst ennþá vandamál í stefnu gáttarinnar, ekki auðkenningar.