O túnel completo matou a sua sessão SSH: fixe a rota de retorno

Inicie um cliente OpenVPN na máquina em que trabalha por SSH, e a meio do comando a sessão congela. O túnel declara-se ligado, o host alcança a internet através dele, e as suas teclas continuam a chegar enquanto nada volta. O que mudou não é o túnel: é o caminho de retorno dos pacotes endereçados a si, que agora corresponde à nova rota predefinida e entra num túnel que o gateway remoto não usará para chegar à sua secretária.

O que o redirect-gateway realmente instala

Na sua forma def1 redirect-gateway acrescenta 0.0.0.0/1 e 128.0.0.0/1 em vez de substituir a rota predefinida. Essas duas metades cobrem todo o espaço de endereços e ambas continuam a ser prefixos mais longos do que 0.0.0.0/0, pelo que qualquer destino sem uma correspondência mais específica passa agora para o túnel. É este o mecanismo a reter, porque cada correção abaixo funciona instalando uma correspondência mais específica.

O seu endereço de administração é um desses destinos.

O servidor VPN encaminha o tráfego dos seus clientes para a internet. Não tem rota para o endereço público de onde se liga, nem motivo para tratar esses pacotes como algo diferente do tráfego que vem de um cliente, por isso descarta-os. Entretanto, o pedido que enviou chegou na mesma ao host, e é por isso que a sessão parece viva só de um lado.

ip route show table main | head -n 20
ip route get 198.51.100.23

Descubra o seu endereço de origem e o caminho antes do túnel

No servidor, liste a ligação SSH estabelecida e anote o endereço do par de onde veio. É esse endereço que a sua rota de retorno tem de cobrir, e nem sempre é o que pensa: um host de salto, um gateway NAT ou um tradutor da operadora podem substituir a origem por outra.

Depois encontre o gateway físico e a interface que transportavam o tráfego antes de o túnel arrancar. Na def1 disposição a rota predefinida continua presente por baixo das meias rotas predefinidas, pelo que a informação está disponível, embora ler a olho uma tabela de rotas longa convide a erros.

Anote os dois valores e o nome da interface em conjunto, porque a rota que vai acrescentar precisa dos três. Se o host usava uma regra de encaminhamento por políticas para escolher o seu uplink, uma rota simples pode nem sequer ser consultada, e essa possibilidade muda a correção.

Fixe uma rota de host que supere as meias rotas predefinidas

Uma rota /32 é mais longa do que qualquer uma das duas meias rotas predefinidas, pelo que as respostas ao seu endereço escolhem-na em vez do túnel. O salto seguinte é o gateway antes do túnel e o dispositivo é a interface física, o que mantém o pacote no caminho que usava antes de o túnel existir.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

Verifique com uma consulta em vez de inspecionar a tabela: a resposta tem de nomear eth0 e o gateway, nunca tun0.

O OpenVPN já acrescenta uma rota de host para o próprio endereço do servidor VPN pelo mesmo motivo, pelo que o padrão é familiar e o endereço de administração é simplesmente mais uma exceção. Não recorra a route-nopull para corrigir isto, porque descarta as rotas empurradas de que o túnel precisa, incluindo a rede remota e as opções de DNS.

Faça com que sobreviva a uma reconexão

Uma rota acrescentada à mão desaparece quando o cliente se reconecta e instala a sua, o que transforma uma correção em falha recorrente. Ligue o comando a algo que corra depois de as rotas serem instaladas.

Tanto um script route-up como o gancho pre-up do gestor de rede funcionam, e a verificação fiável é uma reconexão seguida da mesma consulta.

No Windows o equivalente é uma rota persistente acrescentada com -p, que sobrevive a reinícios mas continua a ter de apontar para o gateway correto após uma mudança de rede. Seja qual for a plataforma, escreva o motivo junto à rota: o próximo administrador precisa de saber que existe para proteger uma sessão de gestão, e não porque o desenho da rede o exigia.

Quando uma rota fixada ainda não chega

A filtragem do caminho inverso pode descartar um pacote que chega por uma interface e sai por outra, e é exatamente isso que uma rota fixada cria. Verifique o valor rp_filter efetivo antes de desativar seja o que for globalmente, e prefira corrigir a assimetria a desligar a verificação. Aplica-se a definição por interface, e o modo loose muitas vezes apenas registra a assimetria em vez de descartar o pacote. Leia ambos antes de concluir que o filtro é culpa sua.

Os hosts com encaminhamento por políticas precisam de uma regra além de uma rota, porque a base de regras escolhe a tabela antes de a rota lá dentro ser consultada. Uma rota na tabela main é invisível para um fluxo que corresponde a uma regra que aponta para outra tabela. Leia as regras antes de acrescentar seja o que for a main. Se uma regra já cobre o tráfego de gestão, a exceção pertence à tabela dessa regra.

Mantenha uma consola fora de banda aberta enquanto testa, e verifique de novo a partir de um segundo login antes de desligar aquele que está a usar. Uma rota que envia o seu próprio tráfego de gestão para o túnel corta a ligação através da qual a está a reparar. Voltar a entrar exige então uma consola série ou um arranque de recuperação, o que é uma má troca por saltar um passo de verificação.