route-gateway não é redirect-gateway: o que realmente muda
A opção só fornece um próximo salto às rotas que o OpenVPN instala. Removê-la não desliga um túnel completo empurrado, e a correção pertence ao redirecionamento.
Seu túnel sobe, a sub-rede privada responde, e a navegação comum continua desaparecendo na VPN mesmo que alguém tenha apagado a linha da gateway do perfil. Essa combinação é a impressão digital da diretiva errada que foi editada. O que foi removido dava ao cliente um próximo salto para as rotas que ele instala; o que continuou capturando tráfego veio de outro lugar e foi empurrado pelo servidor. Cobertura e próximo salto são tarefas separadas, e apenas uma delas decide se os destinos públicos usam o túnel.
A linha que você removeu era um próximo salto, não um interruptor de política
Cada rota que o cliente instala precisa de um endereço de gateway para apontar, e a diretiva de gateway é de onde vem esse endereço quando uma rota não nomeia nenhum. Apague-a e essas rotas não têm onde se prender, então ou não são instaladas ou caem num caminho que não leva a lugar nenhum. A sub-rede privada é exatamente o que uma rota assim carregava.
Enquanto isso, o comportamento que sobreviveu tem outro autor: uma opção de redirecionamento no bloco empurrado, que move o tráfego de saída comum para o túnel conforme as suas flags. Remover a gateway nem a desativa nem a enfraquece. O resultado é o pior dos dois estados, com o tráfego público ainda capturado e o destino privado que justificava o túnel agora inalcançável. Por isso a segunda edição, feita no mesmo espírito, também não muda nada.
Quatro alavancas, quatro tarefas diferentes
Quatro diretivas são citadas de forma intercambiável nesta discussão, e apenas uma delas governa a cobertura, ou seja, quais destinos passam pelo túnel. Uma segunda define o próximo salto que as rotas usam, uma terceira instala um único prefixo, e uma quarta descarta tudo o que o servidor empurrou, incluindo as rotas privadas de que a implementação precisa. A tabela ordena-as pelo que um administrador tenta mudar e não pelo nome, porque são os nomes que causam a confusão. Trate-as como quatro decisões separadas e escolha a que você realmente quer reverter.
Na prática, as quatro costumam chegar num único bloco empurrado, linha após linha, o que as faz parecer partes de uma só configuração. Não são, e a referência do OpenVPN documenta-as como mecanismos distintos exatamente por isso. Descobrir qual decisão você está revertendo é o trabalho; a edição é uma linha.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Filtre a linha empurrada, mantenha o próximo salto
Se a cobertura de que você discorda chega como opção empurrada, a resposta estreita é ignorar essa opção pelo nome e deixar o resto do bloco empurrado intacto. Escrito como filtro, parece a linha abaixo, e pertence ao perfil do cliente afetado, não à configuração do servidor.
pull-filter ignore "redirect-gateway"O estreito é o ponto. Como o filtro compara um prefixo de texto, um padrão mais curto também corresponde à diretiva do próximo salto, o que retira exatamente a informação de que as rotas privadas dependem e reproduz o erro original com uma roupa nova. Um filtro também age apenas sobre opções empurradas, então nunca toca uma linha equivalente escrita localmente ou imposta por um gestor de rede. Reconecte depois, porque uma sessão viva não reavalia o que o servidor empurrou.
Leia a consulta, não a tabela
Depois de recarregar o perfil, pergunte ao kernel aonde dois destinos realmente iriam: um dentro do prefixo privado e outro na internet pública. Um despejo completo da tabela principal é mais difícil de ler e mais fácil de ler errado, porque uma rota pode existir e ainda perder para uma correspondência mais específica. Com encaminhamento por políticas, a regra, a tabela e o endereço de origem também fazem parte da verificação.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showA variante def1 merece familiaridade, porque deixa visível a entrada padrão antiga enquanto um par de meias-padrão vence a consulta. Portanto, uma linha 0.0.0.0/0 na saída não prova nada por si só. A consulta responde a pergunta que a listagem só parece responder.
DNS, IPv6 e a rota privada ainda precisam funcionar
Recusar um redirecionamento IPv4 não diz nada sobre o resolvedor, então uma opção DNS empurrada pode continuar enviando consultas para o túnel enquanto as rotas parecem corretas. Um padrão IPv6 pode fazer o mesmo para uma família de endereços que a verificação IPv4 nunca tocou. Ambos exigem uma decisão explícita em vez de uma suposição. Depois confirme que o serviço privado ainda responde, porque um túnel dividido que perdeu a sua rota privada não é um túnel dividido, é um quebrado.
Uma ferramenta mais ampla merece um aviso: route-nopull descarta todas as rotas empurradas e todas as opções DNS empurradas, o que sem dúvida para o túnel completo e igualmente sem dúvida quebra as rotas privadas das quais a implementação depende, então é um martelo muito maior do que um filtro de nome voltado para uma opção. Verifique o destino privado, um destino público e o resolvedor após qualquer mudança, e trate um handshake concluído como prova de nada além do handshake.