Il portatile passa dal Wi-Fi dell'ufficio all'hotspot di un telefono, il tunnel resiste ancora qualche secondo, poi il traffico si ferma mentre l'interfaccia continua a dichiarare di essere connessa. Sul server, l'elenco di stato continua a mostrare il vecchio indirizzo pubblico. È la situazione per cui esiste float, ed è anche quella in cui le persone se ne aspettano molto più di quanto faccia. Inquadrare bene il confine trasforma uno stallo confuso in una modifica di configurazione di una riga o in un'indagine del tutto diversa.

Cosa allenta float e cosa non allenta mai

Di norma una sessione continua a parlare con l'indirizzo esterno e la porta con cui è iniziata, e i pacchetti che arrivano da qualsiasi altro posto vengono ignorati. L'opzione float rimuove quel legame rigido una volta che il peer si è già dimostrato, così una mappatura di origine cambiata può proseguire la stessa sessione invece di essere scartata. Nulla dei controlli crittografici cambia: chiavi, certificati e qualsiasi protezione HMAC restano esattamente come configurati.

È una decisione per pacchetto, non una politica su chi può connettersi. Una macchina sconosciuta che invia un pacchetto da un nuovo indirizzo non ha dimostrato nulla, e il suo pacchetto viene scartato come qualsiasi altro traffico non autenticato. Solo il traffico che supera l'autenticazione propria della sessione può spostare l'indirizzo del peer registrato, ed è per questo che è sicuro lasciare float attivo in ambienti in cui i client si spostano.

Non dice nulla nemmeno sul tunnel interno. Un indirizzo esterno spostato non riassegna un indirizzo di tunnel, non cambia il pool e non concede al peer accesso a qualcosa di nuovo. Dentro il tunnel valgono la stessa identità e le stesse rotte spinte prima e dopo lo spostamento. Un roaming non rinegozia nemmeno il canale dati, quindi la cifratura e le chiavi negoziate proseguono.

Il pacchetto che sposta una sessione deve autenticarsi

Avvia una sessione nel modo consueto verso il remoto configurato, e float gestisce ciò che accade quando la mappatura cambia. Un operatore mobile che rinumera a metà flusso, un gateway NAT che riscrive la sua mappatura di porta o un portatile che cambia uplink producono tutti la stessa forma: pacchetti autenticati da una nuova tupla, che arrivano a una sessione che crede ancora in quella vecchia.

Quando ti chiedono se float funziona, la prova utile è un handshake completato seguito da un cambio di origine accettato, non una riga di log sul solo indirizzo. Correla gli indirizzi esterni vecchio e nuovo con la sessione rimasta viva, poi conferma che il traffico è davvero proseguito attraverso il tunnel.

Se la sessione muore invece di spostarsi, il pacchetto arrivato dal nuovo indirizzo probabilmente ha fallito l'autenticazione o non è mai arrivato. Entrambi i casi sono identici dal lato del client. Sul server, una cattura sull'interfaccia pubblica ti dice quale dei due hai prima di toccare qualsiasi configurazione.

La scoperta è un meccanismo del tutto separato

float non risolve nomi a tempo e non segue un record DNS dinamico. Se il nome host del server inizia a risolversi verso un nuovo indirizzo, un client inattivo non ha motivo di accorgersene e nessun pacchetto dal nuovo endpoint da autenticare. Quel problema appartiene alla logica di riconnessione, al comportamento di nuovo tentativo del client stesso e al DNS, non a float.

Aggiungere l'opzione un'altra volta non compensa l'assenza di una rotta verso il nuovo indirizzo. Non aiuta nemmeno quando il peer tace, perché un peer silenzioso non invia mai il pacchetto autenticato che sposterebbe qualcosa.

Anche il firewall sottostante ha voce in capitolo. Una regola che consente solo il vecchio endpoint esterno blocca l'indirizzo cambiato prima che OpenVPN lo veda, e nessuna configurazione lato client lo risolve. Esamina il ciclo di vita degli indirizzi consentiti come un compito a sé; allargare la regola a qualsiasi origine scambia un problema piccolo con uno grande.

Quando NetworkManager possiede il profilo

Un profilo da riga di comando e una connessione importata sono configurazioni separate, e modificarne una non tocca l'altra. Prima di supporre che l'opzione non sia supportata, stabilisci quale tipo di plugin usa davvero il profilo salvato e dove vivono i suoi valori. L'UUID del profilo è l'identificatore che conta quando ispezioni o modifichi qualcosa.

Ispeziona la connessione salvata anziché il file di import originale. Una riga che sopravvive in un file .ovpn non dimostra nulla se il gestore attivo non l'ha mai applicata, e un editor senza casella per una data opzione non dimostra nulla nemmeno sulle capacità del protocollo.

Non correggere un plugin pacchettizzato per aggiungere il comportamento, tanto meno con un diff scritto per una versione storica di un componente non correlato. Se l'integrazione installata non riesce davvero a esprimere l'impostazione, la mossa corretta è un profilo supportato o un percorso client diverso approvato da chi possiede il deployment.

Dimostra la transizione invece di presumerla

Esegui il test come si verifica il guasto. Connettiti, verifica il traffico nel tunnel, forza il cambio dell'indirizzo esterno e poi controlla tre cose: la sessione esiste ancora, l'indirizzo del peer registrato si è spostato e una richiesta reale raggiunge ancora la sua destinazione. Qualcosa meno di tutte e tre è una risposta parziale.

Tieni a disposizione l'accesso di ripristino mentre provi, perché gli esperimenti di roaming hanno l'abitudine di lasciare la macchina da cui lavori bloccata. Una console seriale o una rotta fuori banda trasforma un test fallito in un recupero di cinque minuti invece di una visita in sede.

Infine, descrivi solo il caso che hai esercitato. Un cambio di indirizzo riuscito durante una sessione non è prova che migrazioni DNS, un'altra implementazione client o un profilo ricostruito si comportino allo stesso modo. La documentazione di link-options indica con precisione l'ambito dell'opzione; il tuo log di test dovrebbe dire quale parte di quell'ambito hai davvero coperto.

Articoli correlati