A VPN mudou: por que o teu cliente OpenVPN segue marcando o IP antigo

O provedor cambiou o teu enderezo público, actualizaches o rexistro DNS dinámico e o cliente aínda non pode conectar. Desde fóra parece que o rexistro non se propagou. A maioría das veces o rexistro está ben e o cliente marca o enderezo que resolveu antes do traslado, porque un túnel en marcha e un perfil gardado teñen cada un a súa propia idea de onde vive o servidor. Tres capas teñen que coincidir, e actualízanse con calendarios distintos.

Mira o que marca o perfil, non o que di o DNS

Abre a conexión que usas realmente e le a liña remote. Un enderezo numérico alí nunca segue unha actualización do nome de host, por correcto que chegue a ser o rexistro.

Despois comproba se o perfil que editaches é o que cargou o cliente. Os perfís importados son habituais: un administrador puido tomar unha copia hai meses e conservar a súa propia versión, así que o ficheiro do teu cartafol de descargas e a entrada da aplicación poden discrepar. Compara o extremo nos detalles de conexión do propio cliente antes de depurar o DNS sequera.

Dous ficheiros, un extremo: ese é o achado habitual aquí.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

Le o seguinte intento de conexión do cliente

Reinicia a conexión con rexistro detallado e le a liña onde se nomea o enderezo co que contactará. Ese valor é o que importa, non o que resolveu o teu navegador.

A caché do resolutor aínda pode conservar a resposta anterior, e algunhas redes gárdaa máis tempo do que pide o TTL do rexistro. Consulta o resolutor que o cliente usa realmente, non un público que probaches desde outro sitio.

Se o rexistro mostra o enderezo novo e a conexión segue fallando, o problema moveuse: o paquete vai a algún sitio e ninguén responde. É unha cuestión de escoita, cortafogos ou redirección de portos, e está do lado do servidor, non na ruta de resolución do cliente. Mantén separados eses dous fallos, porque tratar un escoita inalcanzable como un problema de DNS fai que deas dúas veces a mesma volta.

Sabe que reinicio estás a facer

Non todos os reinicios conservan o mesmo estado, e por iso un cambio de enderezo pode comportarse de forma distinta segundo como se recicle o proceso. Un reinicio suave provocado por un sinal conserva máis contexto da sesión anterior, mentres que unha parada e arranque completos volven comezar desde a configuración. Se estás probando se o cliente volve resolver, queres a ruta que parte da configuración.

Os axustes de persistencia tamén importan, porque están pensados para conservar o que se autenticou, non para perseguir enderezos novos.

A proba máis limpa é un arranque novo desde o perfil previsto, seguido dunha ollada á liña de rexistro que nomea o extremo. Todo o que aprendas dunha sesión conservada en parte é unha afirmación sobre esa sesión.

As catro opcións e as súas tarefas separadas

remote cun nome de host é o axuste que fai posible a resolución repetida; un enderezo literal nesa liña exclúeo. resolv-retry controla que ocorre cando falla unha consulta, e a 2.6 xa o pon en infinito por defecto. Engadilo, xa que logo, non cambia nada, e nunca programa unha comprobación periódica doutra resposta. Quen di que sondea enderezos novos confundiu a recuperación coa frescura.

persist-remote-ip trata de continuidade, non de frescura: reutiliza o extremo que se autenticou por última vez, a través dos reinicios suaves que admite. Mentres probas un traslado, iso é o contrario do que queres. Desactívao para a proba se a túa compilación o activa, e restáurao cando o novo extremo estea probado. Se o deixas activo, unha reconexión correcta pode non dicirche nada sobre o DNS.

float acepta un par autenticado cuxo enderezo cambiou a metade de sesión, e só en configuracións que o admiten. Non refresca o DNS e non seguirá un cambio de provedor por si só. Trátao como unha función de resistencia para pares que se desprazan, non como un mecanismo de enderezos dinámicos para servidores.

Confirma o extremo novo antes de culpar o cliente

Desde fóra da túa rede, comproba que o enderezo novo ten un escoita no porto configurado e que o reenvío do provedor apunta a el. Un rexistro A correcto para unha máquina sen porto aberto produce exactamente o síntoma que a xente atribúe á caché.

Despois reconecta e verifica dúas cousas: que o cliente se autenticou contra o certificado de servidor agardado e que a sesión alcanza o recurso que pretendías. Un cambio de enderezo non rebaixa os requisitos de identidade, e unha conexión que ten éxito cara ao extremo equivocado é peor que unha que falla. O manual de OpenVPN 2.6 enumera as catro opcións co seu propio alcance, e esa é a lista de comprobación que cómpre ter xunto ao perfil.

Mantén unha vía fóra de banda cara ao servidor antes de reiniciar o túnel que leva o teu acceso administrativo. Esa soa precaución evita a maioría dos incidentes que produce este escenario.