¿La configuración VPN pública dejó de funcionar? Lee la etapa de fallo

El perfil funcionaba el martes, y el viernes el cliente gira durante treinta segundos y se rinde. Nada ha cambiado en tu máquina. Esa es exactamente la cuestión: una configuración descargada describe un host en un momento dado, y el operador del otro extremo no tiene obligación de mantener veraz esa descripción. La tentación es empezar a editar ajustes de seguridad hasta que el túnel vuelva. Ese instinto es la razón por la que la gente acaba ejecutando un perfil con la verificación de certificados desactivada, lo cual es peor que no tener ningún túnel.

El archivo describe un momento, no un contrato

Un archivo de configuración es un conjunto de aserciones: este nombre de host escucha en este puerto con este protocolo, presenta un certificado que coincide con este nombre y acepta estas credenciales. Cuando cualquiera de ellas deja de ser cierta, el archivo está obsoleto y la solución corresponde al lado del operador de la frontera, no a tus ajustes.

Las listas de nodos públicas lo hacen explícito por su propia naturaleza. Los nodos los gestionan voluntarios, aparecen y desaparecen, las direcciones se reciclan y los puertos los bloquea la red en la que estén. La lista es una instantánea que se regenera, y la copia de tu disco es una fotografía de una instantánea más antigua.

Los servicios comerciales cambian más despacio, pero no nunca. Las autoridades de certificación rotan, un escucha pasa de una dirección compartida a una dedicada, un protocolo antiguo se retira y llega una nueva lista de cifrados. Cada uno de esos cambios es invisible hasta que tu cliente intenta conectar y recibe una respuesta distinta de la que el archivo espera.

Lee la etapa de fallo antes de tocar un ajuste

El mensaje de error dice qué aserción falló, y cada aserción tiene una reparación completamente distinta. Editar cifrados cuando el nombre de host ya no resuelve desperdicia una tarde y no enseña nada a nadie.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

La línea central separa una ruta bloqueada de un saludo roto, y la tercera muestra el emisor y las fechas de validez del certificado que se presenta realmente. Si ese emisor no es el que fijó el perfil, el certificado ha cambiado, y ninguna opción del cliente hará que la fijación antigua vuelva a ser correcta.

Los cambios de certificado e identidad son los silenciosos

La mayoría de los fallos se anuncian. Los cambios de identidad no, porque un cliente que fija un nombre de certificado rechazará un certificado nuevo perfectamente bueno con un mensaje que mucha gente lee como un error del programa. El túnel está bien. La fijación está obsoleta.

Busca las opciones de identidad antes de concluir nada:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Si el perfil lleva una CA incrustada y el operador ha rotado a una autoridad nueva, el archivo antiguo no puede validar el servidor nuevo. Sustituir el bloque de CA por el publicado por el operador es una reparación legítima. Borrar la directiva de verificación no lo es, y son las mismas pulsaciones con un resultado muy distinto.

Una actualización del cliente puede producir el mismo síntoma sin ningún cambio del operador. Opciones que se toleraban en silencio ahora se rechazan, o se retira un protocolo obsoleto. Es un límite de compatibilidad de tu software, y merece la pena probar un segundo perfil con el mismo cliente antes de culpar al servidor.

Solo el operador puede publicar un reemplazo válido

Cuando un nodo desaparece, el reemplazo tiene que venir de la misma fuente que publicó el original. Un perfil que llega por mensaje directo porque «usa el mismo nombre de servidor» es una configuración no verificada de una parte desconocida, e importarlo le da a esa parte el control de tu enrutamiento.

La comprobación es barata. Descarga el archivo actual de la ubicación publicada, compara el extremo y el protocolo con la lista y confirma la huella del material de CA en lugar de fiarte del nombre del archivo:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Si los dos hashes difieren solo en espacios, tienes un cambio de formato. Si difieren en los extremos, el operador ha movido algo y el archivo publicado es la autoridad. Si el archivo publicado es más antiguo que el que tienes, probablemente estás mirando una caché, y la respuesta obsoleta te enviará en la dirección equivocada.

Retira la entrada antigua y registra qué ocurrió

Una vez verificado un reemplazo funcional, borra el perfil antiguo en lugar de guardarlo como respaldo. Una entrada obsoleta que conecta a medias es una trampa: se elegirá durante una caída, fallará despacio, y quien depure pasará los primeros diez minutos con el archivo equivocado.

Lleva un registro breve fuera de la configuración: la fecha, el extremo antiguo, la etapa de fallo y qué lo sustituyó. Los nodos públicos cambian, y seis semanas después la misma pregunta llega con otra persona. Una línea en un archivo de notas la responde en segundos.

Si desde una red todos los nodos fallan de la misma forma y desde otra no falla ninguno, deja de editar perfiles y mira la ruta local. Un portal cautivo, un rango de puertos filtrado o un proxy interceptor producirán errores idénticos en proveedores no relacionados, y ese patrón es la única señal de que el problema nunca fue el archivo.