O «File exists» do OpenVPN numa rota não é um problema de ficheiro

Comece onde a mensagem aparece. Um cliente liga-se, o túnel sobe e, em seguida, o registo informa que o comando de adicionar rota do Linux falhou com File exists. Nada nessa frase se refere a um certificado, uma chave ou um ficheiro de configuração, embora as palavras o sugiram. O kernel está a descrever a sua tabela de rotas, e o prefixo que pediu para instalar já tem uma entrada.

Siga a sequência do próprio cliente: o que pediu, o que a tabela já continha, quem colocou essa entrada ali e só depois o que mudar. Cada passo elimina um possível proprietário.

O que o cliente estava realmente a pedir

Antes da falha, o cliente registra a rota que pretende adicionar, normalmente como destino, máscara de rede, gateway e às vezes como métrica ou tabela. Essa linha é o pedido. O erro que se segue é a resposta do kernel, e os dois devem ser lidos lado a lado.

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

Um estado de saída diferente de zero do auxiliar de rotas é menos informativo do que o texto por baixo, porque respostas diferentes do kernel produzem um estado diferente de zero. Guarde a mensagem exata; a distinção entre uma entrada existente e um gateway inalcançável decide qual das secções seguintes se aplica.

Leia a rota existente, não apenas o endereço

Procurar na tabela o mesmo quádruplo pontuado não é suficiente. Um objeto de rota é identificado pela sua família de endereços, tabela, prefixo de destino, métrica, protocolo e dispositivo de saída, e as entradas que partilham um prefixo podem coexistir legitimamente quando esses atributos diferem. O que colide é o objeto inteiro, não 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

O último comando responde a uma pergunta diferente das duas primeiras: não o que existe, mas que entrada o kernel escolheria para esse destino agora. Ambas as vistas são úteis, e divergem com frequência suficiente para valer a pena compará-las antes de concluir algo. A discrepância entre elas é o caso interessante, não um erro de arredondamento.

Anote o prefixo, a tabela, a métrica e o dispositivo junto ao pedido falhado. Se a entrada existente tiver os mesmos atributos e o mesmo salto seguinte, tem uma instrução duplicada e não um problema de encaminhamento.

Quatro proprietários que um prefixo pode ter

As rotas ligadas provêm de um endereço atribuído e são recriadas pelo sistema sempre que esse endereço existe. Um cliente DHCP ou um gestor de ligações instala rotas como parte do seu próprio ciclo de vida. Outro cliente VPN pode já estar a transportar o mesmo prefixo. E um gancho ou script local pode adicionar uma que mais nada conhece.

Cada proprietário precisa de uma correção diferente. Uma rota ligada não é sua para apagar; removê-la pode quebrar o acesso local antes de o túnel ser utilizável, e o kernel volta a colocá-la. Uma rota detida por um gestor deve ser alterada através desse gestor, não com um ip route del manual que a próxima reconexão desfaz.

Uma interface retida torna a mesma confusão mais fácil. Quando o dispositivo do túnel sobrevive a uma reconexão, as rotas instaladas por código de configuração personalizado podem ainda estar presentes na segunda execução, pelo que um script que assume um estado limpo falha da segunda vez e funciona da primeira. Ou limpa a entrada obsoleta deliberadamente ou torna o código de configuração idempotente.

block-local responde a outra pergunta

Quando um perfil envia todo o tráfego pelo túnel, o cliente tem de decidir o que acontece à rede local. O indicador block-local altera essa decisão ao encaminhar a LAN local pelo túnel, mantendo a exceção documentada para o gateway da LAN; é uma escolha de política de tráfego com consequências visíveis para a acessibilidade.

Não explica porque é que adicionar uma rota devolveu um erro de entrada existente, e adotá-lo como reparação universal esconde o conflito real por trás de uma mudança de política. Se os seus recursos locais deixarem de estar acessíveis após editar um perfil, este indicador é uma das primeiras coisas a inspecionar; se adicionar uma rota falhar, não é a resposta.

Trate-o como uma decisão sobre que destinos permanecem locais, tomada deliberadamente e registada. Não é um interruptor para experimentar quando o registo parece alarmante.

Feche o ciclo: remova o duplicado na sua origem

Depois de saber que proprietário tem a entrada, remova a instrução duplicada onde está definida. Pode ser uma linha route no perfil, um push do servidor ou um gancho que já não precisa de correr.

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

Depois reconecte e confirme três coisas: o túnel sobe, o destino pretendido é resolvido para o caminho que queria, e a falha desaparece sem que apareça uma nova no seu lugar. Um registo limpo com um caminho escolhido incorretamente não é uma correção.

Se o prefixo significa a LAN local de um lado e uma rede remota do outro, o problema é uma sobreposição de endereços e não um duplicado, e nenhuma eliminação fará com que ambos os significados sejam verdadeiros ao mesmo tempo. Esse caso precisa de um plano diferente para uma das duas redes. Decida que lado será renumerado antes de tocar em qualquer um deles.