Come un accesso VPN arriva a RADIUS e al tuo provider di identità
Segui un accesso VPN dal client alla richiesta RADIUS del gateway, al provider di identità dietro di essa e alla policy applicata dopo l'accept.
La settimana scorsa un utente è riuscito ad accedere alla VPN e comunque è finito su una rete dove non si risolveva nulla. Il client diceva connesso, il log del gateway diceva Access-Accept e il team identità diceva che l'account era a posto. L'accesso aveva funzionato; l'autorizzazione dietro no. Quando un accesso VPN fallisce, percorro il cammino che la richiesta segue davvero — client, gateway, server RADIUS, provider di identità — e mi fermo al primo salto la cui risposta non concorda con la successiva.
Il client non parla mai RADIUS
Qualunque cosa mostri l'app sul portatile, il suo primo salto è il protocollo VPN: IKEv2, OpenVPN, WireGuard o un client basato su TLS. RADIUS non compare in quello scambio. Il client si autentica al gateway con un certificato, un nome utente e una password, o un metodo EAP trasportato nella configurazione del tunnel.
Questo conta quando si leggono i log, perché l'errore di autenticazione generico che l'utente vede è prodotto dal gateway dopo che ha già parlato con qualcos'altro. Se il client non raggiunge mai il gateway, non esiste nessuna richiesta RADIUS da diagnosticare, e un'ora spesa sul server RADIUS è persa. Conferma che il tunnel sia salito prima di toccare il backend.
Il gateway è il client RADIUS
Appena la configurazione del tunnel arriva al punto in cui le credenziali vanno verificate, il gateway diventa un server di accesso alla rete. Costruisce una Access-Request: User-Name, una password o payload EAP, NAS-IP-Address o NAS-Identifier, e un Message-Authenticator quando il metodo lo richiede. La richiesta va a UDP 1812 per impostazione predefinita, e la contabilità a 1813. Le installazioni più vecchie usano ancora 1645 e 1646, quindi una regola del firewall scritta per una coppia spiega molti errori silenziosi.
Entrambi i lati condividono un segreto, e non è una credenziale utente. Firma lo scambio e ogni risposta viene verificata contro di esso. Configura il segreto in modo diverso sui due lati e il server non risponde con un segreto sbagliato: scarta la richiesta o la risposta non supera la verifica, quindi il gateway segnala un timeout. Un segreto sbagliato e un server morto sembrano identici dal gateway, per questo provo il salto con uno strumento client prima di dare la colpa alla directory.
Il protocollo è piccolo e vecchio — RFC 2865 definisce lo scambio di autenticazione — ma gli attributi che trasporta sono la base su cui è costruita la maggior parte delle policy 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'Il server RADIUS può essere solo la facciata del provider di identità
La gente parla di RADIUS e provider di identità come se fossero la stessa scatola. Spesso non lo sono. Il server RADIUS riceve la Access-Request e poi chiede qualcos'altro — Active Directory via LDAP o Kerberos, un file utenti locale o un servizio esterno — prima di rispondere. FreeRADIUS con il modulo LDAP o krb5, Windows NPS e Cisco ISE occupano tutti questa posizione.
La distinzione decide dove guardare. Una password rifiutata è una risposta del provider di identità inoltrata da RADIUS. Un timeout di solito è il tratto RADIUS-directory: un account di bind scaduto, una directory irraggiungibile o una richiesta instradata al backend sbagliato. Se il nome utente porta un suffisso di dominio, il server può instradare su di esso, e lo stesso account inviato come CORP\alice e [email protected] può finire in posti diversi. In Windows NPS il log Security registra 6272 per una concessione e 6273 per un rifiuto, il che dice se la decisione è arrivata da NPS.
Leggi il guasto al salto che l'ha prodotto
Un solo messaggio di impossibile connessione copre quattro guasti diversi. Prima di cambiare qualcosa, abbina il sintomo al salto che l'ha prodotto.
| 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 |
L'ultima riga è quella che manda le persone al team sbagliato. Access-Accept significa che le credenziali sono state accettate; non significa che il gateway abbia messo l'utente nel pool giusto o spinto rotte. Gli attributi di gruppo contano solo se la policy del gateway li legge. Ho visto un accesso corretto finire in un pool ospiti perché la mappatura dei gruppi era configurata sul lato RADIUS per un attributo diverso da quello che il gateway ispeziona.
Segui un accesso dall'inizio alla fine
Scegli un solo account di test e un gateway, poi osserva lo stesso tentativo nei quattro punti. Avvia un'esecuzione di debug sul lato RADIUS — freeradius -X stampa la richiesta e ogni modulo che tocca — segui il log di autenticazione del gateway ed esegui tcpdump per lo scambio UDP. Connettiti una volta e leggi le quattro tracce in ordine.
Quello che vuoi vedere è accordo: il gateway ha chiesto dell'utente che ti aspettavi, il server RADIUS ha scelto il backend che ti aspettavi, quel backend ha restituito una decisione e gli attributi nella risposta corrispondono alla policy che il gateway applica. Il primo punto in cui le tracce non concordano è la tua linea di guasto. Se la risposta non porta alcun attributo di gruppo, il problema è sul lato RADIUS, non nel profilo VPN; se l'attributo c'è e il gateway lo ignora, il problema è la policy del gateway.
Una nota di sicurezza mentre sei lì. Il segreto condiviso protegge lo scambio, ma non cifra la maggior parte degli attributi. Se il gateway e il server RADIUS sono su segmenti diversi, metti quel salto su RADIUS tramite TLS o su un percorso privato. Un tunnel utente cifrato non dice nulla sul collegamento al backend.
Prima di chiudere il ticket, conferma quattro cose. Il gateway riesce a raggiungere il server RADIUS sulla porta per cui è realmente configurato. Il segreto condiviso corrisponde su entrambi i lati. Il server RADIUS risolve la forma esatta del nome utente che il gateway invia. L'accept porta gli attributi di cui la policy del gateway ha bisogno. Quando tutte e quattro valgono, un accesso che fallisce ancora è un problema di policy del gateway, non di autenticazione.