Perché una risposta RADIUS VLAN non fa nulla per un utente VPN

Aggiungete l’attributo VLAN alla policy NPS, l’utente VPN si connette e il portatile finisce ancora nel pool predefinito. Il server RADIUS restituisce ciò che avete richiesto, e questo fa sembrare il guasto un problema di cache. Di solito non lo è. Un Access-Accept porta indizi di autorizzazione, e solo il server di accesso alla rete che li ha ricevuti può trasformarne uno in un’assegnazione di rete.

Partite dal gateway, non dai criteri

Percorrete la catena dal client verso l’interno prima di cambiare qualsiasi cosa. Il client chiede una sessione al gateway, il gateway chiede a RADIUS se l’utente può averne una, e RADIUS risponde con un risultato e un insieme di attributi. Poi il gateway applica ciò che sa applicare.

Il vostro percorso inizia al quarto passo, ed è per questo che i primi tre sembrano sani. Nulla nello scambio obbliga il gateway a implementare un attributo che ha ricevuto. La risposta è una richiesta al gateway, non un fatto sul client.

Ciò che fa lo switch e che la VPN non può

Uno switch di accesso 802.1X è un autenticatore con porte, e l’assegnazione dinamica delle VLAN sposta una di quelle porte in una VLAN che lo switch già trasporta. Gli attributi di tunnel RADIUS descrivono quell’intento in una forma che lo switch comprende. Una VPN instradata termina tunnel, non porte di switch, e i suoi client ricevono di solito un indirizzo e una rotta anziché l’appartenenza a un dominio di broadcast. Non c’è alcuna porta da spostare, quindi lo stesso attributo non ha nulla su cui agire.

Questa è una differenza di modello, non un difetto del fornitore. Alcuni gateway aggiungono la propria policy di gruppo, la selezione del pool o un meccanismo di filtro che in uno screenshot sembra simile. Altri non ne implementano nulla, e l’attributo viene registrato e ignorato. Leggete la documentazione per la modalità di accesso remoto che avete realmente abilitato, non quella nello screenshot.

Leggete la risposta che il server ha realmente inviato

Verificate ciò che RADIUS ha restituito invece di ciò che mostra l’editor dei criteri. Una richiesta di prova con lo stesso nome utente e una password nota stampa gli attributi di risposta in forma leggibile, e questo risolve la questione in un passo.

radtest alice secret 10.0.0.10 0 testing123

Se gli attributi VLAN mancano in quella risposta, correggete prima la corrispondenza dei criteri. Se sono presenti, il server ha fatto la sua parte e il divario è più a valle.

Dimostrate prima la policy di sessione, poi la raggiungibilità

Ora osservate la sessione che il gateway ha costruito. L’elenco delle sessioni attive mostra il pool, l’indirizzo assegnato e qualsiasi policy di gruppo collegata dal gateway, e questa è l’unica prova che conta per l’applicazione. Confrontatela con ciò che l’utente può raggiungere, non con ciò che i criteri intendevano.

swanctl --list-sas

Poi provate dal client una risorsa consentita e una negata, perché un indirizzo del pool corretto non dimostra l’isolamento. Se il gateway non ha alcun meccanismo per l’assegnazione che volete, più copie dell’attributo non ne creeranno uno. Un indirizzo del pool atteso può coesistere con l’accesso completo a ogni altro pool. Scegliete un meccanismo di criterio supportato o cambiate di proposito la progettazione della rete.