El «File exists» de OpenVPN en una ruta no es un problema de archivos

Empiece donde aparece el mensaje. Un cliente se conecta, el túnel se levanta y entonces el registro informa de que el comando de añadir ruta de Linux falló con File exists. Nada en esa frase se refiere a un certificado, una clave o un archivo de configuración, aunque las palabras lo sugieran. El núcleo está describiendo su tabla de rutas, y el prefijo que pidió instalar ya tiene una entrada.

Siga la secuencia del propio cliente: qué pidió, qué contenía ya la tabla, quién puso esa entrada ahí y solo después qué cambiar. Cada paso elimina un posible propietario.

Qué estaba pidiendo realmente el cliente

Antes del fallo, el cliente registra la ruta que pretende añadir, normalmente como destino, máscara de red, puerta de enlace y a veces como métrica o tabla. Esa línea es la petición. El error que sigue es la respuesta del núcleo, y ambos deben leerse juntos.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Un estado de salida distinto de cero del asistente de rutas informa menos que el texto que hay debajo, porque distintas respuestas del núcleo producen un estado distinto de cero. Conserve el mensaje exacto; la distinción entre una entrada existente y una puerta de enlace inalcanzable decide cuál de las secciones siguientes se aplica.

Lea la ruta existente, no solo la dirección

Buscar en la tabla el mismo cuádruple con puntos no basta. Un objeto de ruta se identifica por su familia de direcciones, tabla, prefijo de destino, métrica, protocolo y dispositivo de salida, y las entradas que comparten un prefijo pueden coexistir legítimamente cuando esos atributos difieren. Lo que colisiona es el objeto entero, no el texto.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

El último comando responde a una pregunta distinta de las dos primeras: no qué existe, sino qué entrada elegiría el núcleo para ese destino ahora mismo. Ambas vistas son útiles, y discrepan con la suficiente frecuencia como para compararlas antes de concluir algo. La discrepancia entre ellas es el caso interesante, no un error de redondeo.

Anote el prefijo, la tabla, la métrica y el dispositivo junto a la petición fallida. Si la entrada existente tiene los mismos atributos y el mismo siguiente salto, tiene una instrucción duplicada y no un problema de enrutamiento.

Cuatro propietarios que puede tener un prefijo

Las rutas conectadas provienen de una dirección asignada y el sistema las recrea siempre que esa dirección existe. Un cliente DHCP o un gestor de conexiones instala rutas como parte de su propio ciclo de vida. Otro cliente VPN puede estar ya llevando el mismo prefijo. Y un gancho o script local puede añadir una que nada más conoce.

Cada propietario necesita una corrección distinta. Una ruta conectada no es suya para borrarla; eliminarla puede romper el acceso local antes de que el túnel sea utilizable, y el núcleo la volverá a poner. Una ruta propiedad de un gestor debe cambiarse a través de ese gestor, no con un ip route del manual que la próxima reconexión deshace.

Una interfaz retenida facilita la misma confusión. Cuando el dispositivo del túnel sobrevive a una reconexión, las rutas instaladas por código de configuración personalizado pueden seguir presentes en la segunda ejecución, así que un script que asume un estado limpio falla la segunda vez y funciona la primera. O bien limpia la entrada obsoleta a propósito o bien hace idempotente el código de configuración.

block-local responde a otra pregunta

Cuando un perfil envía todo el tráfico por el túnel, el cliente debe decidir qué ocurre con la red local. El indicador block-local cambia esa decisión al enrutar la LAN local por el túnel mientras mantiene la excepción documentada para la puerta de enlace de la LAN; es una elección de política de tráfico con consecuencias visibles para la conectividad.

No explica por qué añadir una ruta devolvió un error de entrada existente, y adoptarlo como reparación universal esconde el conflicto real tras un cambio de política. Si sus recursos locales dejan de ser accesibles tras editar un perfil, este indicador es una de las primeras cosas que inspeccionar; si añadir una ruta falla, no es la respuesta.

Trátelo como una decisión sobre qué destinos permanecen locales, tomada a propósito y escrita. No es un interruptor que probar cuando el registro parece alarmante.

Cierre el círculo: elimine el duplicado en su origen

Una vez que sepa qué propietario tiene la entrada, elimine la instrucción duplicada donde está definida. Puede ser una línea route en el perfil, un push del servidor o un gancho que ya no necesita ejecutarse.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Después reconecte y confirme tres cosas: el túnel se levanta, el destino previsto se resuelve hacia la ruta que quería, y el fallo desaparece sin que aparezca uno nuevo en su lugar. Un registro limpio con una ruta elegida incorrecta no es una corrección.

Si el prefijo significa la LAN local por un lado y una red remota por el otro, el problema es un solapamiento de direcciones y no un duplicado, y ninguna cantidad de borrado hará que ambos significados sean ciertos a la vez. Ese caso necesita un plan distinto para una de las dos redes. Decida qué lado se va a renumerar antes de tocar cualquiera de los dos.