IP VPN fissa: Framed-IP-Address RADIUS o una prenotazione nel pool

Tre posti possono contenere un indirizzo interno fisso per un client VPN, e solo uno di essi dovrebbe possederlo. RADIUS può restituire l’indirizzo in un Access-Accept, il gateway può mantenere una mappatura statica per l’account, e l’adattatore del client può essere impostato a mano. I primi due sono politica e il terzo è una supposizione locale che il gateway è libero di ignorare o sovrascrivere. Scegliere tra i primi due è la vera decisione, e dipende da ciò che il server di accesso alla rete implementa davvero.

Tre posti in cui un indirizzo fisso può vivere

RADIUS possiede l’indirizzo quando la risposta porta Framed-IP-Address e il gateway applica quel valore alla sessione. Il gateway lo possiede quando un amministratore mappa l’account su un indirizzo statico dentro il pool. Il client non possiede nulla, anche quando il suo adattatore mostra un indirizzo manuale, perché il server assegna l’indirizzo interno durante la negoziazione e un’impostazione locale conta solo quando il server non ne invia nessuno. Tutti e tre sembrano identici su una connessione funzionante, ed è per questo che i conflitti emergono tardi. La differenza si vede alla riconnessione, su un secondo dispositivo e dopo un cambio di politica.

Due proprietari è la configurazione che si rompe. Una risposta RADIUS che assegna 172.28.4.77 mentre il gateway mantiene una mappatura statica per 172.28.4.90 restituisce il valore che il codice del fornitore controlla per primo, e il perdente viene scartato senza una riga di log. Lo stesso account su un secondo dispositivo riceve allora un indirizzo duplicato, e il sintomo si legge come un guasto di routing invece che come un conflitto di assegnazione. Decidete il proprietario prima di aggiungere il secondo meccanismo.

L’opzione lato client vale la pena di nominarla solo per poterla escludere. Un indirizzo manuale dell’adattatore è una preferenza che il sistema operativo può mostrare, non una prenotazione, e non può impedire a un’altra sessione di ricevere lo stesso indirizzo.

Cosa può promettere la risposta RADIUS e cosa no

RFC 2865definisce Framed-IP-Address come l’indirizzo IPv4 da configurare per l’utente, e appartiene ad Access-Accept. Lo stesso attributo in Access-Request è solo un suggerimento che il server può ignorare, e questo conta quando un client o un gateway propone un indirizzo preferito. Nulla nel protocollo obbliga il gateway a rispettare la risposta, perché il server di accesso alla rete è il componente che la applica alla sessione.

Il supporto è una questione di prodotto e non di protocollo. Alcuni gateway applicano gli indirizzi incorniciati per impostazione predefinita, altri hanno bisogno di un interruttore a livello di gruppo attivato prima di farlo, e altri accettano l’attributo e non lo usano mai per le sessioni di accesso remoto. Quest’ultimo caso è quello pericoloso, perché il record di contabilità può mostrare la risposta mentre il client riceve un indirizzo dal pool. Confermate il comportamento sul modello esatto di gateway e sul firmware che eseguite, non sulla documentazione di un prodotto gemello.

Una risposta che il gateway ignora sembra esattamente una risposta che non è mai stata inviata. Leggere l’Access-Accept e l’indirizzo della sessione fianco a fianco è l’unico modo per separare i due casi.

Prenotate l’indirizzo dentro il pool che già instradate

Scegliete l’indirizzo fisso dalla sottorete del pool che il gateway già instrada e di cui il firewall già si fida. Un indirizzo fuori da quell’intervallo trasforma un cambio di politica in un progetto di routing, e la VPN salirà mentre nulla dietro di essa potrà rispondere. Se esistono regole di accesso per indirizzo, aggiungete l’indirizzo fisso anche a quelle nello stesso cambiamento.

Decidete cosa deve fare una seconda sessione simultanea. Assegnare un indirizzo due volte non è gestione dei dispositivi, e la collisione risultante appare come connettività intermittente per entrambe le sessioni. O emettete identità distinte per dispositivo, o assegnazioni distinte, o imponete la simultaneità con un controllo supportato, come Simultaneous-Use, invece di sperare che il client non si riconnetta mai prima della scadenza della vecchia sessione.

Le rotte di ritorno meritano la stessa attenzione dell’assegnazione. Il gateway ha bisogno di una rotta verso il pool, i router interni hanno bisogno di una rotta di ritorno verso il gateway, e l’indirizzo fisso eredita entrambe. Un solo client che funziona mentre tutti gli altri falliscono di solito significa che la rotta del pool esiste ma la rotta host per l’indirizzo prenotato no.

Provate la risposta prima di fidarvi della prenotazione

Provate il lato AAA e il lato sessione separatamente, perché falliscono per motivi diversi. Un radtest locale mostra cosa restituisce il server per l’account senza coinvolgere il gateway, e la voce nel file users mostra con cosa il server dovrebbe corrispondere. Poi ricollegate il client e confrontate l’indirizzo ricevuto con l’attributo nella risposta.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Un Access-Accept senza l’attributo significa che il server non ha trovato la voce o che l’attributo non è stato applicato a quell’utente. Un Access-Accept con l’attributo e un client che riceve ancora un indirizzo dal pool significa che il gateway l’ha ignorato. Un Access-Reject vi rimanda alle credenziali o alla politica di gruppo, e nessuno di questi esiti dovrebbe essere diagnosticato modificando l’adattatore del client.

Ripetete il controllo dopo una riconnessione e dopo un secondo accesso da un altro dispositivo. Una prenotazione che tiene solo per la prima sessione è un conflitto di pool in attesa di accadere, ed è più economico trovarlo ora che durante un audit.

Scegliete un solo proprietario e scrivetelo

Se il gateway applica gli indirizzi incorniciati in modo affidabile, lasciate che RADIUS possieda l’assegnazione e rimuovete qualsiasi mappatura statica per lo stesso account. Se non lo fa, lasciate che la possieda il gateway e togliete l’attributo dalla risposta, così che le due fonti non possano discordare. Tenere entrambe perché ciascuna funziona quasi garantisce una sessione futura con l’indirizzo sbagliato e senza causa evidente.

Scrivete il proprietario scelto, l’indirizzo prenotato e il pool da cui proviene nel record dell’account. La persona successiva che aggiunge un dispositivo potrà vedere se l’indirizzo è una politica AAA o una mappatura del gateway prima di cambiare l’una o l’altra.