OpenVPN redirect-gateway: o que cada flag faz com as rotas

Conecte-se com redirect-gateway no perfil, e a rota padrão da sua máquina pode desaparecer, dividir-se em duas ou ficar exatamente onde estava, dependendo de flags que ninguém lê duas vezes. A opção altera apenas o estado de roteamento e nada mais, então a única prova confiável do que ela fez é a tabela que o cliente instalou depois. O que segue é a tabela após uma conexão, a rota que mantém o próprio túnel vivo e o tráfego IPv6 que a diretiva nunca afirma cobrir. Cada passo é um comando que você pode executar no cliente enquanto o túnel está ativo.

O que cada flag faz com a rota padrão

Sem nenhuma flag, a opção remove a rota padrão comum e coloca o túnel no lugar dela, então o gateway antigo desaparece da tabela enquanto a conexão está ativa. Adicione def1 e essa rota padrão continua listada, com duas rotas mais estreitas fazendo o trabalho. Adicione bypass-dhcp e a rota DHCP também sobrevive, o que importa numa rede em que o cliente ainda precisa alcançar o servidor DHCP local. A lista de flags na página do manual do OpenVPN 2.6 é curta o bastante para ler uma vez, e cada entrada muda quais rotas acabam na tabela.

Uma opção empurrada comporta-se da mesma forma quando chega, então o perfil do cliente pode não conter nada enquanto a tabela parece completamente redirecionada. Isso é normal: o servidor enviou as flags, o cliente aplicou-as e o ficheiro local nunca mencionou a diretiva. Quando um envio parece não fazer nada, verifique o filtro do lado do cliente que aceita ou descarta as opções extraídas, porque uma opção descartada não gera erro em nenhum dos lados.

def1 ganha por especificidade sem tocar na sua rota padrão

Duas rotas de meio padrão cobrem juntas o espaço IPv4, 0.0.0.0/1 e 128.0.0.0/1. Cada uma é mais específica do que 0.0.0.0/0, então uma consulta prefere-as enquanto a rota padrão real fica na tabela para tudo o que pede a correspondência menos específica.

Leia a tabela em vez do perfil, porque só a tabela mostra em qual desses casos você está. Duas linhas bastam para distingui-los:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Repare na interface e na métrica de cada linha, não apenas no destino. Uma rota padrão que aponta para o túnel e um par de meias rotas que apontam para o túnel descrevem a mesma intenção e falham de forma diferente quando o túnel cai, porque num caso o recurso de reserva ainda existe. Anote os dois campos na nota de alteração. Um recurso de reserva sobrevivente é às vezes o que mantém uma sessão remota viva o suficiente para reparar o túnel, e também é o que vaza tráfego quando a intenção era um túnel completo.

Mantenha o extremo do túnel alcançável

O cliente precisa de uma rota até o extremo distante do túnel que não passe ela própria pelo túnel. O OpenVPN instala essa rota de host antes de alterar qualquer outra coisa, e uma edição manual de rotas ou um segundo cliente VPN podem removê-la. O sintoma depois é uma ligação que diz estar ligada e em seguida não deixa passar nada.

Pergunte ao núcleo que interface usaria para o endereço do extremo enquanto o túnel está ativo. A resposta deve nomear a interface física e o seu gateway, nunca tun0:

ip route get 198.51.100.20

Se essa consulta devolver o dispositivo do túnel, o túnel transporta o seu próprio tráfego e entrará em colapso assim que um pacote tiver de sair. Os prefixos locais, um segundo adaptador e o encaminhamento por políticas continuam a contar aqui, e é por isso que um redirecionamento que funciona num portátil limpo pode falhar num anfitrião com uma interface de gestão e duas rotas padrão. Normalmente culpa-se o perfil pelo que o plano de endereços fez.

O tráfego IPv6 continua a usar a sua própria tabela

Redirecionar IPv4 deixa o IPv6 em paz, e as duas famílias são alteradas por flags diferentes. Num anfitrião de pilha dupla com uma rota v6 padrão a funcionar, o tráfego v4 pode ficar completamente dentro do túnel enquanto cada destino capaz de v6 sai pela ligação física. Um anfitrião que parece correto numa tabela está a vazar na outra.

Verifique a tabela v6 depois de ligar em vez de assumir que o túnel a cobriu. A diretiva transporta flags de família de endereços exatamente por isso, e um perfil que as omite herda o que a plataforma faz por predefinição:

ip -6 route show default
ip -6 route get 2001:db8::10

Prove que interface uma aplicação usa

Um estado ligado não é um bloqueio, e uma alteração de rota não é um interruptor de segurança. Se o tráfego direto tem de parar quando o túnel falha, essa política vive na firewall e precisa do seu próprio teste.

Teste o caminho que uma aplicação realmente segue em vez do caminho que o perfil descreve. Peça primeiro a rota, depois ligue um pedido a cada interface por vez e compare o que o lado distante comunica:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Se ambos os pedidos devolverem o mesmo endereço, a aplicação não está a usar o túnel, mesmo que a tabela de encaminhamento diga que deveria. Se apenas o pedido ligado ao túnel tiver êxito, o caminho físico está filtrado para esse destino e o túnel faz o que você pediu. Escreva as flags, as rotas instaladas, a consulta do extremo e ambos os resultados de saída no registo de alterações, para que a próxima pessoa herde factos em vez de uma captura de ecrã.