L'adreça del pare canvia a mig camí de la sessió: què fa float a OpenVPN

El portàtil passa del Wi-Fi de l'oficina a un punt d'accés del mòbil, el túnel aguanta uns quants segons més i llavors el trànsit s'atura mentre la interfície continua dient que està connectada. Al servidor, la llista d'estat continua mostrant l'adreça pública antiga. Aquesta és la situació per a la qual existeix float, i també és la situació en què la gent espera que faci molt més del que fa. Encertar la frontera converteix una aturada confusa o bé en un canvi de configuració d'una línia o bé en una investigació completament diferent.

Què relaxa float i què no relaxa mai

Normalment una sessió continua parlant amb l'adreça exterior i el port amb què va començar, i els paquets que arriben de qualsevol altre lloc s'ignoren. L'opció float elimina aquesta vinculació estricta un cop el pare ja ha demostrat qui és, de manera que un mapatge d'origen canviat pot continuar la mateixa sessió en lloc de ser descartat. Res de les comprovacions criptogràfiques no canvia: les claus, els certificats i qualsevol protecció HMAC queden exactament com estan configurats.

És una decisió per paquet, no una política sobre qui es pot connectar. Una màquina desconeguda que envia un paquet des d'una adreça nova no ha demostrat res, i el seu paquet es descarta com qualsevol altre trànsit no autenticat. Només el trànsit que supera l'autenticació pròpia de la sessió pot moure l'adreça del pare enregistrada, i per això és segur deixar float activat en entorns on els clients es mouen.

També no diu res sobre el túnel interior. Una adreça exterior moguda no reassigna cap adreça de túnel, no canvia el pool ni dona al pare accés a res de nou. Dins del túnel, la mateixa identitat i les mateixes rutes empenyades s'apliquen abans i després del moviment. Un desplaçament tampoc no renegocia el canal de dades, així que el xifratge i les claus negociats continuen.

El paquet que mou una sessió s'ha d'autenticar

Inicieu una sessió de la manera habitual contra el remot configurat, i float s'encarrega del que passa quan el mapatge canvia. Un operador mòbil que renumera a mig flux, una passarel·la NAT que reescriu el seu mapatge de port o un portàtil que canvia d'enllaç ascendent produeixen la mateixa forma: paquets autenticats d'una tupla nova, que arriben a una sessió que encara creu en la vella.

Quan us pregunten si float funciona, l'evidència útil és un handshake completat seguit d'un canvi d'origen acceptat, no una línia de registre sobre l'adreça sola. Relacioneu les adreces exteriors vella i nova amb la sessió que va romandre viva, i després confirmeu que el trànsit va continuar realment pel túnel.

Si la sessió mor en lloc de moure's, el paquet que va arribar de l'adreça nova probablement va fallar l'autenticació o no va arribar mai. Els dos casos semblen idèntics des del client. Al servidor, una captura a la interfície pública us diu quin teniu abans de tocar cap configuració.

El descobriment és un mecanisme completament a part

float no resol noms amb un temporitzador ni segueix un registre DNS dinàmic. Si el nom d'amfitrió del servidor comença a resoldre's a una adreça nova, un client inactiu no té cap motiu per adonar-se'n ni cap paquet del punt final nou per autenticar. Aquest problema pertany a la lògica de reconnexió, al comportament de reintent del propi client i al DNS, no a float.

Afegir l'opció una vegada més no pot compensar no tenir ruta cap a l'adreça nova. Tampoc no ajuda quan el pare calla, perquè un pare silenciós no envia mai el paquet autenticat que mouria res.

El tallafoc subjacent també hi té vot. Una regla que només permet el punt final exterior antic bloqueja l'adreça canviada abans que OpenVPN la vegi, i cap configuració del costat del client ho arregla. Reviseu el cicle de vida de les adreces permeses com una tasca pròpia; ampliar la regla a qualsevol origen canvia un problema petit per un de gran.

Quan NetworkManager és l'amo del perfil

Un perfil de línia d'ordres i una connexió importada són configuracions separades, i editar-ne una no toca l'altra. Abans de suposar que l'opció no és compatible, establiu quin tipus de connector fa servir realment el perfil desat i on viuen els seus valors. L'UUID del perfil és l'identificador que importa quan inspeccioneu o modifiqueu qualsevol cosa.

Inspeccioneu la connexió desada en lloc del fitxer d'importació original. Una línia que sobreviu en un fitxer .ovpn no demostra res si el gestor actiu no l'aplicà mai, i un editor sense casella per a una opció concreta tampoc no demostra res sobre les capacitats del protocol.

No pedaceu un connector empaquetat per afegir el comportament, sobretot no amb un diff escrit per a una versió històrica d'un component no relacionat. Si la integració instal·lada genuïnament no pot expressar el paràmetre, el moviment correcte és un perfil compatible o un camí de client diferent aprovat per qui posseeix el desplegament.

Demostreu la transició en lloc de suposar-la

Executeu la prova tal com passa la fallada. Connecteu-vos, verifiqueu el trànsit pel túnel, forceu l'adreça exterior a canviar i després comproveu tres coses: la sessió encara existeix, l'adreça del pare enregistrada s'ha mogut i una petició real encara arriba a la seva destinació. Qualsevol cosa menys que les tres és una resposta parcial.

Mantingueu l'accés de recuperació disponible mentre proveu, perquè els experiments d'itinerància tenen el costum d'encallar la màquina des de la qual treballeu. Una consola sèrie o una ruta fora de banda converteix una prova fallida en una recuperació de cinc minuts en lloc d'una visita al lloc.

Finalment, descriviu només el cas que heu exercitat. Un canvi d'adreça reeixit durant una sessió no és evidència que les migracions de DNS, una altra implementació de client o un perfil reconstruït es comportin igual. La documentació de link-options exposa l'abast de l'opció amb precisió; el vostre registre de prova hauria de dir quina part d'aquest abast heu cobert realment.