Framed-IP-Address RADIUS per un indirizzo client VPN stabile

RADIUS può rispondere con un indirizzo per un determinato utente; se il tunnel lo riceva davvero dipende dal gateway. È proprio in questo divario tra restituito e applicato che falliscono la maggior parte dei piani di indirizzo stabile. Un attributo in una risposta di test dimostra che il server può inviarlo, non che il servizio di accesso remoto lo applichi. La sequenza seguente controlla entrambe le metà prima che l'indirizzo finisca nelle regole del firewall.

Decidi quale livello possiede l'indirizzo

I gateway di accesso remoto di solito hanno un pool locale, e molti possono anche accettare un indirizzo dalla risposta di autenticazione. Quale dei due vince dipende dalla piattaforma, dal protocollo e dalla configurazione del servizio, quindi leggi la regola di precedenza per la versione esatta in uso. Dove il pool locale ha la priorità, l'attributo è decorazione e il client finisce comunque su un indirizzo casuale. Annota la decisione, incluso se un valore restituito debba stare dentro l'intervallo del pool o possa caderne fuori.

RFC 2865 definisce Framed-IP-Address come l'indirizzo da configurare per l'utente, e non dice nulla sulla disponibilità di un particolare gateway a rispettarlo. La documentazione del fornitore è l'autorità sulla precedenza, non la definizione dell'attributo.

Invia una richiesta di test e leggi la risposta

Testa prima il server in isolamento, così un attributo mancante non viene scambiato per un problema del gateway. radtest invia una Access-Request e stampa gli attributi che tornano.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Cerca Framed-IP-Address nella Access-Accept e conferma che il valore sia quello previsto e non un indirizzo del pool da una regola di riserva. Quando l'attributo è assente, la voce utente o la politica di autorizzazione non corrispondono, e la messa a punto del gateway non può fornire ciò che il server non ha mai inviato. Ripeti la richiesta mentre il server è in modalità debug se la risposta è difficile da ricondurre a una regola specifica. Tieni il segreto condiviso fuori dalla cronologia della shell e dai ticket, perché il segnaposto qui sopra non è una credenziale.

Conferma che il gateway abbia rispettato il valore

Una risposta corretta è solo metà del contratto. L'indirizzo che appare sull'interfaccia del tunnel è l'osservazione che conta, e va letto sul client invece che dedotto dalla configurazione del gateway.

ip -4 addr show tun0

Confronta quell'indirizzo con l'attributo della Access-Accept. Una discrepanza significa che il gateway ha ignorato o riscritto il valore, il che riapre la questione della precedenza della prima sezione. Riconnetti ancora una volta, perché una prenotazione che funziona solo al primo tentativo di solito indica una sessione obsoleta o un lease ancora detenuto dalla connessione precedente. Registra la versione del gateway e il protocollo accanto al risultato, così la persona successiva può capire se il comportamento dipende dalla versione.

Pianifica concorrenza e revoca

Un solo nome utente su due dispositivi non può corrispondere a un solo indirizzo a meno che il gateway distingua le sessioni con qualcosa oltre al login. Decidi se la mappatura appartiene a una persona, a un dispositivo registrato o a un'identità certificata, e rendi esplicita questa scelta nell'archivio delle politiche. Prova un secondo client simultaneo e confronta i due indirizzi assegnati, perché una collisione qui riappare più tardi come errore di routing. La stessa cura serve nel piano di revoca, perché un indirizzo riassegnato mentre le vecchie regole del firewall lo citano ancora diventa un bug di autorizzazione.

L'indirizzamento stabile semplifica regole e log, ma non dimostra mai chi ha generato un pacchetto. Autenticazione e autorizzazione della destinazione contano ancora quando quell'indirizzo passa poi a un'altra sessione.