EAP attraverso un gateway VPN: chi termina il metodo

I ticket descrivono un accesso VPN fallito e una policy RADIUS che richiede un metodo più forte come se fossero lo stesso problema, e non lo sono. Il gateway accetta le credenziali e le inoltra, oppure porta una conversazione EAP tra il client e il server di autenticazione. Quale dei due accade decide se un cambiamento lato server può risolvere qualcosa. Leggi lo scambio prima di modificare il gruppo di server.

Due percorsi di autenticazione che nel log sembrano uguali

Nel primo percorso il gateway VPN raccoglie nome utente e password e invia una RADIUS Access-Request con un attributo password. Il server di autenticazione la confronta con il proprio archivio e risponde accetta o rifiuta. Il client non esegue mai un metodo EAP perché nulla glielo ha chiesto.

Nel secondo percorso il client e il server di autenticazione eseguono il metodo EAP da un capo all'altro, e il gateway inoltra gli attributi EAP-Message tra loro. Il gateway termina ancora la conversazione RADIUS esterna, ma la logica del metodo vive ai due estremi.

Entrambi i percorsi producono una riga di log che dice che l'autenticazione è fallita. Solo il secondo può dipendere dal metodo EAP preferito dal server, e solo il primo da come il gateway legge la password. Trattarli come intercambiabili è il motivo per cui i team passano una giornata a cambiare gruppi di server per un client che non avrebbe mai parlato PEAP.

Dove viene eseguito davvero il metodo

RFC 3579 definisce lo schema di transito: il NAS trasporta i pacchetti EAP in attributi RADIUS e non ha bisogno di codice specifico per ogni tipo EAP. Per questo un gateway può supportare PEAP ed EAP-TLS senza implementare nessuno dei due.

Un gateway che invia una password non trasporta PEAP, anche se il backend accetterebbe PEAP da un altro client. Abilitare PEAP nella policy del server non aggiunge un metodo a un client che non ne ha mai offerto uno.

Le impostazioni di autenticazione PPP appartengono al servizio PPP. Non riconfigurano in silenzio ogni percorso IPsec o XAuth legacy che usa lo stesso server AAA, quindi un cambiamento che funziona per un tipo di accesso può lasciare intatto l'altro.

Cosa deve supportare il NAS

Il transito sposta il requisito dal codice del metodo al supporto del trasporto. Il gateway deve poter trasportare EAP sul proprio protocollo VPN, e il client RADIUS su di esso deve poter inviare e ricevere attributi EAP-Message delle dimensioni in gioco.

In IKEv2 EAP fa parte di un flusso di autenticazione definito, e i controlli di identità e fiducia del server derivano da quel flusso. Un'etichetta PEAP presa da una distribuzione 802.1X non si trasferisce automaticamente perché la negoziazione attorno è diversa.

Anche il lato client ha requisiti. Deve essere configurato per il metodo, fidarsi del certificato server presentato dal metodo e avere credenziali che il metodo possa usare. Un metodo basato su certificati senza certificato client fallisce prima che RADIUS veda qualcosa, ed è un problema di provisioning e non di policy del server.

Leggi un tentativo prima di cambiare policy

Cattura un singolo tentativo approvato sul gateway e sul server di autenticazione. Cerca attributi EAP-Message nella richiesta RADIUS. La loro presenza indica che si usa il percorso di transito; l'assenza rimanda a uno scambio di credenziali.

Su un gateway Linux una cattura sulla porta RADIUS mostra quali attributi sono sul filo:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Poi confronta il punto di rifiuto. Un errore sul gateway prima di qualsiasi pacchetto RADIUS significa che client e gateway non erano d'accordo sul metodo. Un rifiuto RADIUS con attributi EAP significa che gli estremi hanno eseguito il metodo e uno di loro ha rifiutato il risultato.

Pianifica la migrazione come un unico cambiamento end-to-end

Cambiare metodo significa cambiare insieme la configurazione del client, il supporto del trasporto sul gateway, la policy del metodo sul server e l'archivio delle credenziali. Fallo in quest'ordine e mantieni un percorso funzionante finché il nuovo non è provato. Un cambiamento solo lato server è una congettura e di solito rompe i client che funzionavano. Prepara il cambiamento su un'identità di test prima di toccare il gruppo.

Annota la combinazione che funziona: protocollo VPN, trasporto EAP, metodo del peer, metodo del server, tipo di credenziale e controllo di identità del server.

Tieni l'AAA di accesso amministrativo separato dall'autenticazione VPN, a meno che il compito includa esplicitamente entrambi. Un cambiamento pensato per l'accesso remoto non deve toglierti la capacità di gestire il dispositivo che lo termina.