O túnel completo do OpenVPN corta a sua sessão SSH: conserte o caminho de volta

Ativar um cliente OpenVPN em túnel completo numa máquina a que você chega por SSH pode cortar a sessão em um segundo, e a máquina não está fazendo nada errado. O túnel não muda como os pacotes chegam ao servidor; muda como as respostas saem. Assim que a rota padrão aponta para tun0, uma resposta ao seu cliente SSH entra na rede do provedor, que não tem rota de volta para o seu endereço. A conexão trava, a próxima tentativa expira e o daemon continua escutando na porta 22 o tempo todo.

Leia a tabela de roteamento antes de ler o log do VPN. O log vai dizer que o túnel subiu, e está certo. A questão é a qual interface cada resposta é entregue, e isso é uma consulta por pacote numa tabela que o túnel acabou de reescrever.

Por que a resposta sai pela porta errada

Os pacotes de entrada ainda chegam pela interface física, porque um cliente VPN não pode mudar como a internet chega ao endereço público do seu servidor. As respostas são uma decisão separada: para cada pacote, o núcleo procura o destino, e depois do --redirect-gateway a entrada padrão diz túnel. A saída do provedor vê um destino que não atende e descarta o pacote.

A proteção do próprio OpenVPN cobre exatamente um destino. O manual da 2.6 descreve --redirect-gateway como uma sequência: ele adiciona uma rota de host para o peer VPN pela gateway em uso antes do túnel, para que o tráfego cifrado não volte para dentro de si mesmo, e então substitui a rota padrão. Essa rota de host é só para o peer. Seu cliente SSH é apenas outro endereço de internet e não recebe exceção alguma.

Vale descartar cedo um erro de prefixo. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 sem comprimento corresponde ao endereço único 0.0.0.0, não à internet; tem de ser 0.0.0.0/0. E se tomar a rota padrão quebra o transporte do próprio túnel, adicione o endpoint como rota de host pela interface física, usando o endereço real do provedor.

Fixe o endereço do seu cliente SSH para um conserto imediato

O conserto mais rápido é uma rota de host para o endereço do seu cliente pela gateway que o servidor usava antes de o túnel existir. Do seu lado, encontre o endereço que o servidor vai ver e então leia a tabela do servidor para saber a gateway antiga:

curl -s https://ifconfig.co
ip route

No servidor, adicione a exceção antes de o cliente iniciar. Os endereços aqui são marcadores de posição; a forma é o que importa:

sudo ip route add 80.128.240.55 via 192.168.178.1

Este é o conserto usado no caso relatado, e ele funciona imediatamente. Também é frágil de duas maneiras previsíveis: a rota desaparece no reinício e fica errada no momento em que o seu ISP lhe dá outro endereço. Trate-o como medida de emergência e torne-o durável de propósito, por meio de uma unidade de rede ou de um gancho do dispatcher, ou aceite que é temporário e anote o caminho de recuperação.

Impeça o cliente de tomar a rota padrão

A opção mais limpa é impedir que o túnel substitua a rota padrão. route-nopull, usado com --client ou --pull, aceita as opções empurradas exceto rotas, block-outside-dns e opções no estilo DHCP como servidores DNS, então você só acrescenta os prefixos de que precisa. Uma ferramenta mais estreita é um filtro de tração, que descarta uma diretiva problemática e mantém o resto:

route-nopull
pull-filter ignore "redirect-gateway"

Use uma ou outra, não as duas, e tenha clareza sobre o que muda. Sem rota padrão pelo túnel, o servidor não navega mais na internet pelo provedor; ele só alcança o que você roteou explicitamente. Se o túnel completo era todo o propósito da configuração, esta é a alavanca errada e a rota de host acima é a certa.

Divida o caminho de volta por origem ou por conexão

Quando o endereço de entrada é estável, uma regra de origem mantém as respostas locais sem tocar nas rotas do próprio túnel. Dê ao endereço da interface física a sua própria tabela com o prefixo LAN e a rota padrão física, e então selecione essa tabela para o tráfego que vem dela:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Isso funciona porque as respostas a uma conexão SSH de entrada saem do endereço ao qual o cliente se conectou. Um caso relatado em que todo serviço de entrada precisava continuar funcionando usou exatamente esta forma. Quando o endereço de entrada flutua ou o caminho é dinâmico, marque a conexão: coloque uma marca conntrack no primeiro pacote que chega pela interface física, copie-a para os pacotes de resposta em OUTPUT e roteie os pacotes marcados por uma tabela que aponta para a gateway física.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Mantenha distintos a marca de conexão, a marca de firewall e o número de tabela durante os testes. Reutilizar um número para dois papéis produz uma regra que parece correta e atinge os pacotes errados. A entrada padrão da tabela também precisa de via com a gateway LAN num enlace Ethernet comum; uma entrada dev eth0 nua só funciona quando a interface é ponto a ponto ou o próximo salto é resolvido de outra forma. O host Jessie relatado estava num enlace onde a forma nua funcionava, o que não é uma regra de distribuição a copiar.

Verifique sem se trancar do lado de fora

Não teste desconectando. Mantenha a primeira sessão aberta, suba o túnel e pergunte ao núcleo que caminho o seu próprio endereço tomaria:

ip route get 80.128.240.55

A resposta deve nomear a interface física e a gateway antiga, não o túnel. Depois abra uma segunda conexão SSH; esse é o teste real, porque a sessão antiga pode sobreviver num estado que uma conexão nova não consegue reproduzir. Se a segunda trava enquanto a primeira ainda responde, a regra nunca bateu no tráfego que importa, e as marcas ou o endereço de origem são onde olhar.

Tenha um console fora de banda disponível durante todo o exercício. Um servidor cujo único caminho de acesso é o túnel que você acabou de quebrar não pode ser consertado por esse túnel, e a reversão é mais fácil quando você anotou os números de tabela e os prefixos que adicionou.