El "File exists" d'OpenVPN en una ruta no és un problema de fitxers

Comença on apareix el missatge. Un client es connecta, el túnel s'aixeca i després el registre informa que l'ordre d'afegir ruta de Linux ha fallat amb File exists. Res d'aquesta frase no fa referència a un certificat, una clau o un fitxer de configuració, encara que les paraules ho suggereixin. El nucli descriu la seva taula d'encaminament, i el prefix que vas demanar d'instal·lar ja té una entrada.

Segueix la seqüència del propi client: què va demanar, què ja contenia la taula, qui hi va posar aquella entrada i només després què cal canviar. Cada pas elimina un possible propietari.

Què demanava realment el client

Abans de la fallada, el client registra la ruta que vol afegir, normalment com a destinació, màscara de xarxa, passarel·la i de vegades com a mètrica o taula. Aquesta línia és la petició. L'error que segueix és la resposta del nucli, i tots dos s'han de llegir junts.

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 estat de sortida diferent de zero de l'auxiliar de rutes informa menys que el text que hi ha a sota, perquè diverses respostes del nucli produeixen un estat diferent de zero. Conserva el missatge exacte; la distinció entre una entrada existent i una passarel·la inabastable decideix quina de les seccions següents s'aplica.

Llegeix la ruta existent, no només l'adreça

Cercar a la taula el mateix quadre amb punts no és suficient. Un objecte de ruta s'identifica per la seva família d'adreces, taula, prefix de destinació, mètrica, protocol i dispositiu de sortida, i les entrades que comparteixen un prefix poden conviure legítimament quan aquests atributs difereixen. El que xoca és l'objecte sencer, no el text.

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

L'última ordre respon una pregunta diferent de les dues primeres: no què existeix, sinó quina entrada triaria el nucli per a aquesta destinació ara mateix. Totes dues vistes són útils, i discrepen prou sovint perquè valgui la pena comparar-les abans de concloure res. La discrepància entre elles és el cas interessant, no un error d'arrodoniment.

Anota el prefix, la taula, la mètrica i el dispositiu al costat de la petició fallida. Si l'entrada existent té els mateixos atributs i el mateix salt següent, tens una instrucció duplicada i no un problema d'encaminament.

Quatre propietaris que pot tenir un prefix

Les rutes connectades provenen d'una adreça assignada i el sistema les recrea sempre que aquesta adreça existeix. Un client DHCP o un gestor de connexions instal·la rutes com a part del seu propi cicle de vida. Un altre client VPN pot estar ja portant el mateix prefix. I un ganxo o script local pot afegir-ne una que res més no coneix.

Cada propietari necessita una correcció diferent. Una ruta connectada no és teva per esborrar-la; eliminar-la pot trencar l'accés local abans que el túnel sigui utilitzable, i el nucli la tornarà a posar. Una ruta propietat d'un gestor s'ha de canviar a través d'aquest gestor, no amb una ip route del manual que la propera reconnexió desfà.

Una interfície retinguda fa més fàcil la mateixa confusió. Quan el dispositiu del túnel sobreviu a una reconnexió, les rutes instal·lades pel codi de configuració personalitzat poden seguir presents a la segona execució, de manera que un script que assumeix un estat net falla la segona vegada i funciona la primera. O bé neteja l'entrada obsoleta deliberadament o bé fes el codi de configuració idempotent.

block-local respon una pregunta diferent

Quan un perfil envia tot el trànsit pel túnel, el client ha de decidir què passa amb la xarxa local. L'indicador block-local canvia aquesta decisió encaminant la LAN local pel túnel mentre manté l'excepció documentada per a la passarel·la de la LAN; és una elecció de política de trànsit amb conseqüències visibles per a la connectivitat.

No explica per què afegir una ruta va retornar un error d'entrada existent, i adoptar-ho com a reparació universal amaga el conflicte real darrere d'un canvi de política. Si els teus recursos locals deixen de ser accessibles després d'editar un perfil, aquest indicador és de les primeres coses a inspeccionar; si afegir una ruta falla, no és la resposta.

Tracta'l com una decisió sobre quines destinacions romanen locals, presa deliberadament i escrita. No és un interruptor per provar quan el registre sembla alarmant.

Tanca el cercle: elimina el duplicat al seu origen

Un cop saps quin propietari té l'entrada, elimina la instrucció duplicada on està definida. Pot ser una línia route al perfil, un push del servidor o un ganxo que ja no cal executar.

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

Després reconnecta i confirma tres coses: el túnel s'aixeca, la destinació prevista es resol cap al camí que volies, i la fallada desapareix sense que n'aparegui una de nova al seu lloc. Un registre net amb un camí triat incorrecte no és cap correcció.

Si el prefix significa la LAN local d'una banda i una xarxa remota de l'altra, el problema és un solapament d'adreces i no un duplicat, i cap esborrat farà que tots dos significats siguin certs alhora. Aquest cas necessita un pla diferent per a una de les dues xarxes. Decideix quin costat es renumerarà abans de tocar-ne cap.