A sua antiga rota predefinida sobrevive ao OpenVPN de propósito

Liga o túnel, executa ip route, e o gateway predefinido original continua lá. O pensamento seguinte é que o cliente não assumiu a rota, por isso apaga a predefinida à mão e perde a conetividade por completo. Essa entrada deve permanecer. Com redirect-gateway def1, o OpenVPN instala duas rotas mais específicas que superam a predefinida normal em vez de a substituir. O gateway antigo fica e deixa de transportar o tráfego que estava a testar.

O que o def1 faz realmente

A flag acrescenta 0.0.0.0/1 e 128.0.0.0/1, ambas apontadas ao túnel. 0.0.0.0/1 abrange todos os endereços cujo primeiro octeto vai de 0 a 127, e 128.0.0.0/1 abrange de 128 a 255, por isso cada destino IPv4 tem uma correspondência mais específica do que a rota predefinida antiga. O comprimento do prefixo, não a métrica, decide qual rota ganha.

Deixar a rota predefinida original no lugar é deliberado. O cliente não tem de recordar o que substituiu e não reescreve a rota que transporta a sua própria ligação ao servidor VPN. Ao desligar, remove as duas meias rotas e a tabela volta ao que era.

Porquê /1 e não /0

O encaminhamento escolhe o prefixo correspondente mais longo, não a métrica mais baixa, por isso uma /1 vence uma /0 diga o que disser a métrica da predefinida. As duas metades existem porque uma /1 só cobre metade do espaço; com apenas 0.0.0.0/1 presente, tudo a partir de 128.0.0.0 segue ainda a rota predefinida antiga, o que produz o sintoma confuso de alguns sites funcionarem e outros não.

Subir ou descer a métrica da rota predefinida antiga não muda nada, e uma predefinida com métrica mais baixa noutra interface também não rouba o tráfego. Primeiro decide o comprimento do prefixo, e só os prefixos iguais recorrem à métrica.

Leia uma tabela de encaminhamento real

Um anfitrião ligado pode mostrar as três entradas ao mesmo tempo, com o túnel a transportar as metades e o gateway original ainda na lista. Os endereços são exemplos e não uma configuração a copiar, porque os nomes das interfaces, a topologia do túnel e as rotas adicionais variam conforme a plataforma e o cliente.

default via 192.168.50.1 dev wlan0
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0

O importante é a relação: duas metades concretas por cima de uma predefinida geral. A linha do gateway antigo fica porque nada a substituiu.

Verifique qual rota o pacote segue realmente

Rotas mais específicas ainda podem ganhar: uma rota para um intervalo privado, uma sub-rede local ou o próprio endereço do servidor VPN é mais longo do que uma /1. O túnel precisa de um caminho exterior até ao seu servidor, e devolver essa ligação para dentro do túnel quebrá-lo-ia de imediato. No Linux, pergunte ao kernel em vez de ler a tabela a olho: o ip route get com o destino que lhe interessa imprime a rota escolhida, a interface e a origem. Se houver encaminhamento por políticas configurado, reveja também as regras, porque uma regra pode escolher outra tabela antes de a principal ser consultada.

Se apenas parte do IPv4 se comporta mal, confirme que as duas metades estão instaladas e procure depois uma exceção que corresponda ao destino que falha. Apagar a rota predefinida antiga não é solução, e remove a rota de que o cliente precisa para desmontar o túnel de forma limpa.

O que o def1 não abrange

Duas entradas IPv4 não dizem nada sobre IPv6: um anfitrião com conetividade IPv6 continua a usar a sua própria predefinida até algo redirecionar essa família em separado, e é por isso que numa rede de pilha dupla parte do tráfego parece evitar o túnel. Outros clientes e gestores de rede implementam o encaminhamento de túnel completo de forma diferente, e as suas tabelas não coincidirão. O comportamento do def1 aqui descrito pertence à flag documentada do OpenVPN, não a cada VPN da máquina.

Um kill switch responde a outra pergunta: o que a máquina faz quando o túnel cai. A precedência de rotas decide para onde vai o tráfego enquanto o túnel está ativo; não decide o que faz depois uma firewall. Ordem de trabalho: leia a tabela, confirme que as duas metades existem, execute o ip route get para o destino que falha, reveja as regras de política e depois olhe para o IPv6 em separado. Deixe a rota predefinida antiga onde está.