Por que uma rota VPN excluída volta após reconectar

Uma rota que você excluiu à mão volta após a próxima reconexão, e a tabela fica exatamente como antes. Isso não é um bug de roteamento: algo recria a entrada a partir da configuração ou de uma ação do ciclo de vida da conexão. A maioria dos runbooks para na tabela ativa, e por isso a exclusão parece funcionar por um minuto e depois falha. Identifique o proprietário, altere isso e prove numa reconexão.

Quem instalou a rota

Comece com uma lista de candidatos em vez de uma correção. Um perfil de VPN pode carregar as próprias rotas, um servidor pode enviá-las no momento da conexão, um perfil do gerenciador de rede pode declará-las, uma unidade de inicialização ou script pode adicioná-las, e implementações de IPsec instalam rotas para os seletores de tráfego que negociam. Regras de roteamento por política também podem redirecionar o tráfego totalmente para outra tabela.

O momento em que aparecem as separa mais rápido do que a arqueologia de configuração. Uma entrada que aparece no instante em que a interface sobe pertence ao cliente; uma que chega um segundo depois geralmente veio de um push do servidor; uma que existe no boot pertence à configuração salva. Registre a tabela antes e depois de uma conexão, uma desconexão e um reinício, e o padrão nomeará o proprietário. Uma rota que só volta quando o serviço reinicia aponta para uma unidade, não para a VPN.

Leia a tabela antes de editá-la

Olhe a visão do próprio kernel em vez de um arquivo salvo. A coluna de protocolo mostra o que instalou cada entrada:

ip route show
ip route show table all
ip rule show

O campo de protocolo, a métrica e o número da tabela dizem se você está vendo uma entrada estática, uma criada pelo kernel ou algo adicionado por um daemon. A lista de regras importa porque uma consulta pode sair completamente da tabela principal, o que torna uma edição ali invisível para a aplicação que você está depurando. Leia a linha da esquerda para a direita: destino, gateway, dispositivo, protocolo e métrica.

Depois pergunte ao kernel qual rota ele realmente usaria. Um endereço protegido é uma sonda melhor do que um público:

ip route get 10.20.5.7

Mude o proprietário, não o sintoma

Depois que o proprietário é conhecido, a mudança pertence a esse proprietário. Remova a rota do perfil do cliente, corrija a rota enviada no servidor ou edite a conexão do gerenciador de rede em vez de adicionar uma rota persistente concorrente que vence pela métrica. Duas regras brigando entre si produzem uma tabela que ninguém conseguirá explicar depois.

Mantenha a exclusão do endpoint. Uma rota de host que envia o endereço público do próprio servidor VPN pelo gateway físico é o que mantém os pacotes externos do túnel fluindo; se você a remover, o túnel tenta carregar a si mesmo. Num perfil de túnel dividido, o mesmo cuidado vale para as sub-redes locais que devem contornar o túnel.

Reconecte e verifique os dois caminhos

Reconecte e então verifique os dois destinos numa única passada. O endereço protegido e o endpoint excluído respondem a perguntas diferentes:

ip route get 10.20.5.7
ip route get 198.51.100.20

O primeiro deve resolver pela interface do túnel e o segundo pelo gateway físico. Se ambos resolverem pelo túnel, falta a exclusão; se nenhum resolver, a mudança de perfil não entrou em vigor e você está vendo um proprietário diferente do que pensava.

Anote o propósito da rota, o proprietário e por quanto tempo ela deve viver. Essa nota é o que impede a próxima pessoa de repetir o mesmo ciclo de excluir e reconectar.