Kiel VPN-ensaluto atingas RADIUS kaj vian identecprovizanton
Spuru VPN-ensaluton de la kliento al la RADIUS-peto de la enirejo, la identecprovizanto malantaŭ ĝi, kaj la politiko aplikata post la akcepto.
Pasintsemajne uzanto povis ensaluti al la VPN kaj tamen alvenis en reto, kie nenio solviĝis. La kliento diris konektita, la protokolo de la enirejo diris Access-Accept, kaj la identeca teamo diris, ke la konto estas en ordo. La ensaluto funkciis; la rajtigo malantaŭ ĝi ne. Kiam VPN-ensaluto malsukcesas, mi sekvas la vojon, kiun la peto efektive prenas — kliento, enirejo, RADIUS-servilo, identecprovizanto — kaj haltas ĉe la unua salto, kies respondo malkongruas kun la sekva.
La kliento neniam parolas RADIUS
Kion ajn montras la aplikaĵo sur la tekkomputilo, ĝia unua salto estas la VPN-protokolo: IKEv2, OpenVPN, WireGuard aŭ TLS-bazita kliento. RADIUS ne aperas en tiu interŝanĝo. La kliento aŭtentikigas sin al la enirejo per atestilo, uzantnomo kaj pasvorto, aŭ per EAP-metodo portata ene de la tunela agordo.
Tio gravas kiam vi legas protokolojn, ĉar la ĝeneralan aŭtentikigan eraron, kiun la uzanto vidas, produktas la enirejo post kiam ĝi jam parolis kun io alia. Se la kliento neniam atingas la enirejon, ne ekzistas RADIUS-peto por sencimigi, kaj horo pasigita ĉe la RADIUS-servilo estas perdita. Konfirmu, ke la tunelo entute leviĝis, antaŭ ol tuŝi la malantaŭan parton.
La enirejo estas la RADIUS-kliento
Tuj kiam la tunela agordo atingas la punkton, kie oni devas kontroli akreditaĵojn, la enirejo fariĝas ret-aliroservilo. Ĝi konstruas Access-Request: User-Name, pasvorton aŭ EAP-ŝarĝon, NAS-IP-Address aŭ NAS-Identifier, kaj Message-Authenticator kiam la metodo postulas ĝin. La peto defaŭlte iras al UDP 1812, kaj la kontado al 1813. Pli malnovaj instaloj ankoraŭ uzas 1645 kaj 1646, do fajroŝirma regulo skribita por unu paro klarigas multajn silentajn malsukcesojn.
Ambaŭ flankoj kunhavas sekreton, kaj ĝi ne estas uzanta akreditaĵo. Ĝi subskribas la interŝanĝon, kaj ĉiu respondo estas kontrolata laŭ ĝi. Agordu la sekreton malsame ĉe la du flankoj kaj la servilo ne respondas per malbona sekreto — ĝi forĵetas la peton aŭ la respondo malsukcesas la kontrolon, do la enirejo raportas tempolimon. Malĝusta sekreto kaj mortinta servilo aspektas identaj de la enirejo, tial mi testas la salton per klienta ilo antaŭ ol kulpigi la dosierujon.
La protokolo estas malgranda kaj malnova — RFC 2865 difinas la aŭtentikigan interŝanĝon — sed la atributoj, kiujn ĝi portas, estas tio, sur kio baziĝas la plej granda parto de VPN-politiko.
# 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'La RADIUS-servilo eble estas nur la antaŭaĵo de la identecprovizanto
Homoj parolas pri RADIUS kaj identecprovizanto kvazaŭ ili estus la sama skatolo. Ofte ili ne estas. La RADIUS-servilo ricevas la Access-Request kaj poste demandas ion alian — Active Directory per LDAP aŭ Kerberos, lokan uzantan dosieron aŭ eksteran servon — antaŭ ol respondi. FreeRADIUS kun la LDAP- aŭ krb5-modulo, Windows NPS kaj Cisco ISE ĉiuj staras en ĉi tiu pozicio.
La distingo decidas, kie vi rigardu. Malakceptita pasvorto estas respondo de la identecprovizanto transdonita de RADIUS. Tempolimo kutime estas la parto de RADIUS al la dosierujo: eksvalidiĝinta bind-konto, neatingebla dosierujo aŭ peto direktita al la malĝusta malantaŭaĵo. Se la uzantnomo portas domajnan sufikson, la servilo povas rutigi laŭ ĝi, kaj la sama konto sendita kiel CORP\alice kaj [email protected] povas alveni en malsamaj lokoj. En Windows NPS, la protokolo Security registras 6272 por permeso kaj 6273 por rifuzo, kio diras al vi, ĉu la decido entute venis de NPS.
Legu la malsukceson ĉe la salto, kiu produktis ĝin
Unu mesaĝo pri neeblo konekti kovras kvar malsamajn malsukcesojn. Antaŭ ol ŝanĝi ion, kunordigu la simptomon kun la salto, kiu produktis ĝin.
| 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 |
La lasta vico estas tiu, kiu sendas homojn al la malĝusta teamo. Access-Accept signifas, ke la akreditaĵoj estis akceptitaj; ĝi ne signifas, ke la enirejo metis la uzanton en la ĝustan pool aŭ puŝis itinerojn. Grupaj atributoj gravas nur se la enireja politiko legas ilin. Mi vidis ĝustan ensaluton alteriĝi en gastan pool ĉar la grupa mapado estis agordita ĉe la RADIUS-flanko por atributo malsama ol tiu, kiun la enirejo ekzamenas.
Spuru unu ensaluton de komenco ĝis fino
Elektu unu testan konton kaj unu enirejon, poste observu la saman provon ĉe ĉiuj kvar punktoj. Startigu sencimigan kuradon ĉe la RADIUS-flanko — freeradius -X presas la peton kaj ĉiun modulon, kiun ĝi tuŝas — sekvu la aŭtentikigan protokolon de la enirejo, kaj rulu tcpdump por la UDP-interŝanĝo. Konektiĝu unufoje kaj legu la kvar spurojn laŭ ordo.
Kion vi volas vidi, estas interkonsento: la enirejo demandis pri la uzanto, kiun vi atendis, la RADIUS-servilo elektis la malantaŭaĵon, kiun vi atendis, tiu malantaŭaĵo redonis decidon, kaj la atributoj en la respondo kongruas kun la politiko, kiun la enirejo aplikas. La unua loko, kie la spuroj malkongruas, estas via panea linio. Se la respondo ne portas grupan atributon, la problemo estas ĉe la RADIUS-flanko, ne en la VPN-profilo; se la atributo estas tie kaj la enirejo ignoras ĝin, la enireja politiko estas la problemo.
Unu sekureca noto dum vi estas tie. La komuna sekreto protektas la interŝanĝon, sed ĝi ne ĉifras la plej multajn atributojn. Se la enirejo kaj la RADIUS-servilo troviĝas en malsamaj segmentoj, metu tiun salton sur RADIUS super TLS aŭ privatan vojon. Ĉifrita uzanta tunelo diras nenion pri la malantaŭa ligilo.
Antaŭ ol fermi la bileton, konfirmu kvar aferojn. La enirejo povas atingi la RADIUS-servilon sur la pordo, por kiu ĝi efektive agordiĝis. La komuna sekreto kongruas ĉe ambaŭ flankoj. La RADIUS-servilo solvas la ĝustan formon de uzantnomo, kiun la enirejo sendas. La akcepto portas la atributojn, kiujn la enireja politiko bezonas. Kiam ĉiuj kvar validas, ensaluto, kiu ankoraŭ malsukcesas, estas enireja politika problemo, ne aŭtentikiga.