O enderezo do par cambia a metade de sesión: que fai float en OpenVPN

O portátil pasa do Wi-Fi da oficina ao punto de acceso dun móbil, o túnel aguanta uns segundos máis e despois o tráfico detense mentres a interface segue afirmando que está conectada. No servidor, a lista de estado segue mostrando o enderezo público antigo. Esta é a situación para a que existe float, e tamén é a situación na que a xente espera del moito máis do que fai. Acertar coa fronteira converte un bloqueo confuso nun cambio de configuración dunha liña ou nunha investigación completamente distinta.

Que relaxa float e que non relaxa nunca

Normalmente unha sesión segue falando co enderezo exterior e o porto cos que comezou, e os paquetes que chegan de calquera outro sitio ignóranse. A opción float elimina esa vinculación estrita unha vez que o par xa demostrou quen é, de xeito que unha asignación de orixe cambiada pode continuar a mesma sesión en lugar de ser descartada. Nada das comprobacións criptográficas cambia: as claves, os certificados e calquera protección HMAC permanecen exactamente como se configuraron.

É unha decisión por paquete, non unha política sobre quen pode conectarse. Unha máquina descoñecida que envía un paquete desde un enderezo novo non demostrou nada, e o seu paquete descártase como calquera outro tráfico non autenticado. Só o tráfico que supera a autenticación propia da sesión pode mover o enderezo do par rexistrado, e por iso é seguro deixar float activado en contornos onde os clientes se desprazan.

Tampouco di nada sobre o túnel interior. Un enderezo exterior movido non reasigna un enderezo de túnel, non cambia o conxunto nin concede ao par acceso a algo novo. Dentro do túnel, a mesma identidade e as mesmas rutas empurradas aplícanse antes e despois do movemento. Un desprazamento tampouco renegocia a canle de datos, así que o cifrado e as claves negociados continúan.

O paquete que move unha sesión ten que autenticarse

Inicie unha sesión do xeito habitual contra o remoto configurado, e float encárgase do que ocorre cando cambia a asignación. Un operador móbil que renumera a metade de fluxo, unha pasarela NAT que reescribe a súa asignación de porto ou un portátil que cambia de enlace ascendente producen a mesma forma: paquetes autenticados dunha tupla nova, que chegan a unha sesión que aínda cre na vella.

Cando lle preguntan se float funciona, a evidencia útil é un handshake completado seguido dun cambio de orixe aceptado, non unha liña de rexistro sobre o enderezo soa. Correlacione os enderezos exteriores vello e novo coa sesión que seguiu viva e despois confirme que o tráfico continuou realmente polo túnel.

Se a sesión morre en lugar de moverse, o paquete que chegou desde o enderezo novo probablemente fallou a autenticación ou non chegou nunca. Ambos os casos vense idénticos desde o cliente. No servidor, unha captura na interface pública dille cal dos dous ten antes de tocar calquera configuración.

O descubrimento é un mecanismo completamente á parte

float non resolve nomes cun temporizador nin segue un rexistro DNS dinámico. Se o nome de host do servidor comeza a resolverse a un enderezo novo, un cliente inactivo non ten motivo para notalo nin paquete do novo extremo que autenticar. Ese problema pertence á lóxica de reconexión, ao comportamento de reintento do propio cliente e ao DNS, non a float.

Engadir a opción unha vez máis non pode compensar non ter ruta cara ao enderezo novo. Tampouco axuda cando o par está en silencio, porque un par silencioso nunca envía o paquete autenticado que movería algo.

A devasa subxacente tamén ten voto. Unha regra que só permite o extremo exterior antigo bloquea o enderezo cambiado antes de que OpenVPN chegue a vela, e ningunha configuración do lado do cliente o arranxa. Revise o ciclo de vida dos enderezos permitidos como unha tarefa propia; ampliar a regra a calquera orixe cambia un problema pequeno por un grande.

Cando NetworkManager é o dono do perfil

Un perfil de liña de ordes e unha conexión importada son configuracións separadas, e editar unha non toca a outra. Antes de supoñer que a opción non é compatible, estableza que tipo de complemento usa realmente o perfil gardado e onde viven os seus valores. O UUID do perfil é o identificador que importa cando inspecciona ou modifica algo.

Inspeccione a conexión gardada en lugar do ficheiro de importación orixinal. Unha liña que sobrevive nun ficheiro .ovpn non demostra nada se o xestor activo nunca a aplicou, e un editor sen caixa para unha opción concreta tampouco demostra nada sobre as capacidades do protocolo.

Non parche un complemento empaquetado para engadir o comportamento, e menos cun diff escrito para unha versión histórica dun compoñente non relacionado. Se a integración instalada realmente non pode expresar o axuste, o movemento correcto é un perfil compatible ou unha ruta de cliente distinta aprobada por quen é dono do despregamento.

Demostre a transición en lugar de supoñela

Execute a proba tal como ocorre o fallo. Conéctese, verifique o tráfico polo túnel, force o cambio do enderezo exterior e despois comprobe tres cousas: a sesión segue existindo, o enderezo do par rexistrado moveuse e unha petición real segue chegando ao seu destino. Calquera cousa menos que as tres é unha resposta parcial.

Manteña dispoñible o acceso de recuperación mentres proba, porque os experimentos de itinerancia teñen o costume de deixar varada a máquina desde a que traballa. Unha consola serie ou unha ruta fóra de banda converte unha proba fallada nunha recuperación de cinco minutos en lugar dunha visita ao sitio.

Por último, describa só o caso que exercitou. Un cambio de enderezo correcto durante unha sesión non é evidencia de que as migracións de DNS, outra implementación de cliente ou un perfil reconstruído se vaian comportar igual. A documentación de link-options expón o alcance da opción con precisión; o seu rexistro de proba debería indicar que parte dese alcance cubriu realmente.