O «File exists» de OpenVPN nunha ruta non é un problema de ficheiros

Empeza onde aparece a mensaxe. Un cliente conéctase, o túnel sobe e despois o rexistro informa de que a orde de engadir ruta de Linux fallou con File exists. Nada nesa frase se refire a un certificado, unha clave ou un ficheiro de configuración, aínda que as palabras o suxiran. O núcleo está a describir a súa táboa de rutas, e o prefixo que pediches instalar xa ten unha entrada.

Segue a secuencia do propio cliente: que pediu, que contiña xa a táboa, quen puxo esa entrada alí e só despois que cambiar. Cada paso elimina un posible propietario.

Que estaba pedindo realmente o cliente

Antes do fallo, o cliente rexistra a ruta que pretende engadir, normalmente como destino, máscara de rede, pasarela e ás veces como métrica ou táboa. Esa liña é a petición. O erro que segue é a resposta do núcleo, e ambos deben lerse xuntos.

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 saída distinto de cero do asistente de rutas informa menos que o texto de abaixo, porque distintas respostas do núcleo producen un estado distinto de cero. Conserva a mensaxe exacta; a distinción entre unha entrada existente e unha pasarela inalcanzable decide cal das seccións seguintes se aplica.

Le a ruta existente, non só o enderezo

Buscar na táboa o mesmo cuádruplo con puntos non abonda. Un obxecto de ruta identifícase pola súa familia de enderezos, táboa, prefixo de destino, métrica, protocolo e dispositivo de saída, e as entradas que comparten un prefixo poden coexistir lexitimamente cando eses atributos difiren. O que colisiona é o obxecto enteiro, non o 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

A última orde responde a unha pregunta distinta das dúas primeiras: non que existe, senón que entrada escollería o núcleo para ese destino agora mesmo. Ambas as vistas son útiles, e discrepan con suficiente frecuencia como para comparalas antes de concluír algo. A discrepancia entre elas é o caso interesante, non un erro de redondeo.

Anota o prefixo, a táboa, a métrica e o dispositivo xunto á petición fallida. Se a entrada existente ten os mesmos atributos e o mesmo seguinte salto, tes unha instrución duplicada e non un problema de encamiñamento.

Catro propietarios que pode ter un prefixo

As rutas conectadas proveñen dun enderezo asignado e o sistema recréaas sempre que ese enderezo existe. Un cliente DHCP ou un xestor de conexións instala rutas como parte do seu propio ciclo de vida. Outro cliente VPN pode estar xa levando o mesmo prefixo. E un gancho ou script local pode engadir unha que nada máis coñece.

Cada propietario precisa unha corrección distinta. Unha ruta conectada non é túa para borrala; eliminala pode romper o acceso local antes de que o túnel sexa utilizábel, e o núcleo volveraa poñer. Unha ruta propiedade dun xestor debe cambiarse a través dese xestor, non cun ip route del manual que a próxima reconexión desfai.

Unha interface retida facilita a mesma confusión. Cando o dispositivo do túnel sobrevive a unha reconexión, as rutas instaladas por código de configuración personalizado poden seguir presentes na segunda execución, así que un script que asume un estado limpo falla a segunda vez e funciona a primeira. Ou limpas a entrada obsoleta a propósito ou fas idempotente o código de configuración.

block-local responde a outra pregunta

Cando un perfil envía todo o tráfico polo túnel, o cliente debe decidir que ocorre coa rede local. O indicador block-local cambia esa decisión encamiñando a LAN local polo túnel mentres mantén a excepción documentada para a pasarela da LAN; é unha elección de política de tráfico con consecuencias visibles para a conectividade.

Non explica por que engadir unha ruta devolveu un erro de entrada existente, e adoptalo como reparación universal esconde o conflito real detrás dun cambio de política. Se os teus recursos locais deixan de ser accesibles tras editar un perfil, este indicador é unha das primeiras cousas a inspeccionar; se engadir unha ruta falla, non é a resposta.

Trátao como unha decisión sobre que destinos permanecen locais, tomada a propósito e escrita. Non é un interruptor para probar cando o rexistro parece alarmante.

Pecha o círculo: elimina o duplicado na súa orixe

Unha vez que saibas que propietario ten a entrada, elimina a instrución duplicada onde está definida. Pode ser unha liña route no perfil, un push do servidor ou un gancho que xa non precisa executarse.

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

Despois reconecta e confirma tres cousas: o túnel sobe, o destino previsto resólvese cara á ruta que querías, e o fallo desapareceu sen que apareza un novo no seu lugar. Un rexistro limpo cunha ruta elixida incorrectamente non é unha corrección.

Se o prefixo significa a LAN local por un lado e unha rede remota polo outro, o problema é un solapamento de enderezos e non un duplicado, e ningunha cantidade de borrado fará que ambos os significados sexan certos á vez. Ese caso necesita un plan distinto para unha das dúas redes. Decide que lado se vai renumerar antes de tocar calquera dos dous.