O cliente VPN apaga a rota que você adicionou? Use uma tabela de políticas

Uma /24 para uma impressora de laboratório desaparece entre duas chamadas a ip route show, e o log do cliente só diz que a rede mudou. Não havia nada errado com o comando, o prefixo ou os seus privilégios. Um cliente corporativo que possui o modelo de roteamento do host reafirma esse modelo sempre que outra pessoa o edita, então a entrada que você adicionou é removida como intrusa. Lutar contra ele na mesma tabela é uma posição perdida. A solução é parar de competir por essa tabela por completo e colocar a exceção onde o monitor nunca olha.

O monitor explica a rota desaparecida

Demonstre isso antes de redesenhar qualquer coisa: leia a tabela, adicione o prefixo, espere alguns segundos, leia de novo. Se a entrada não estiver lá e você não digitou nada para removê-la, um agente está observando. Encontre o processo que possui esse comportamento e leia o journal dele em torno do momento em que a rota some, porque o mesmo serviço costuma manter o túnel, os filtros de pacotes e a configuração do resolver. Matá-lo para a sua rota ficar é uma troca que você vai lamentar na próxima reconexão.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

O prefixo e a interface acima são placeholders. Copiar um nome de interface de um exemplo que funciona em outra máquina é o motivo mais comum de esta demonstração não produzir absolutamente nada.

Uma segunda tabela é invisível para o monitor

O agente só reconstrói a tabela que possui. Dê à exceção uma tabela própria mais uma regra que envie para lá os destinos correspondentes, e a tabela principal nunca muda, então o agente não tem nada a corrigir. É toda a ideia: um espaço de nomes de rotas que outra pessoa mantém, e outro que só você toca.

A troca é manutenção. Dois objetos podem divergir, e a posição da regra na lista importa tanto quanto a rota dentro da tabela que ela seleciona.

Construa a exceção e depois faça-a vencer

Crie a tabela, instale a rota e adicione uma regra que selecione a tabela para esse destino. A preferência decide se a sua regra é consultada antes ou depois das que o cliente inseriu, e uma regra ordenada mais tarde nunca é alcançada, então o número faz parte do projeto e não é decoração. Depois pergunte ao kernel o que ele realmente faria, que é uma pergunta diferente do que você configurou.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get resolve a rota que o kernel usaria, incluindo o dispositivo e o endereço de origem. Ele não imprime o identificador da tabela, então combine-o com ip rule show quando precisar confirmar qual tabela venceu. Juntos, respondem à única pergunta que importa: o tráfego para esse endereço sai onde você pretendia?

Outras formas da mesma ideia

O padrão se generaliza assim que você deixa de pensar em destinos. Uma sub-rede local pode continuar acessível enquanto o túnel mantém a rota padrão. As respostas de um servidor SSH ligado à LAN podem sair pela interface por onde chegaram em vez de desaparecer no túnel. E uma regra baseada em interface pode empurrar tudo o que chega numa interface sem fio para o túnel enquanto o tráfego que o próprio host gera fica no Ethernet:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Esse último caso corresponde à interface de entrada em vez do destino, o que é outro tipo de regra e outro modelo mental. O tráfego encaminhado também precisa de net.ipv4.ip_forward ativado, e a extremidade remota deve encaminhar de volta a faixa de origem ou traduzi-la; uma regra numa máquina nunca cria a outra metade do caminho.

Trate a regra como descartável

As regras e as rotas de tabela vivem na memória. Depois de uma reconexão, o dispositivo do túnel pode ser renomeado, o endereço atribuído pode mudar, e uma regra com o valor antigo deixa de corresponder em silêncio. Reaplique toda a mudança a partir de um único script que a possua, e então verifique novamente ip rule show, o nome atual do dispositivo e um ip route get novo contra um destino real antes de confiar na exceção.

Dois limites sobrevivem a qualquer cuidado. O cliente ainda controla as suas próprias regras de filtragem e a configuração do resolver, e uma exceção de roteamento não substitui nenhuma das duas. Se o cliente também apagar a sua regra de política, os caminhos suportados são a sua própria política de túnel dividido ou um cliente que permite gerenciar rotas, como o OpenConnect; corrigir um binário de fornecedor para silenciar o seu monitor é um compromisso de manutenção com uma verificação de integridade anexada.

Escreva o número da tabela, a preferência e o destino numa nota ao lado do script. Caso contrário, a próxima pessoa encontra uma regra que supera o túnel e não tem como saber por quê.