Duas portas de ligação, uma VPN: porque o OpenVPN escolhe o uplink errado

Dois uplinks, um túnel, e o tráfego sai pelo que não escolheu. As sub-redes privadas estão acessíveis, o registo reporta uma ligação bem-sucedida, e é o link medido que a transporta. Nada na saída do OpenVPN menciona um gateway, porque o cliente nunca escolheu um. Abriu um socket para um endereço remoto e deixou o kernel decidir como chegar a esse endereço.

O endereço do túnel não é o ponto final

Existem dois caminhos diferentes em cada sessão. O caminho exterior transporta o tráfego cifrado até ao endereço público do servidor. O caminho interior transporta tudo o que o servidor empurra para o túnel, e as regras de encaminhamento de um não afetam o outro.

A entrada remote do perfil indica o destino exterior, por isso é esse o endereço a fixar. É também o valor que muda quando um nome de host é resolvido de forma diferente ou o perfil lista vários remote.

Encontre o endereço que o cliente realmente chamou

Leia o socket ativo em vez do ficheiro de configuração. A tabela de sockets mostra o par ao qual o processo se ligou realmente, e é esse o valor que a exceção tem de corresponder. Um perfil pode ser editado depois de a sessão começar, e o socket é a única prova do que foi chamado:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

A linha de registo indica o endereço e a porta do par no momento da ligação. Se não coincidir com o perfil, algo à frente do cliente reescreve o destino antes de a ligação começar.

Verifique também a família de endereços. Um perfil de dupla pilha pode ligar-se por IPv6 enquanto a sua exceção só cobre IPv4, e então o tráfego segue uma regra diferente da que escreveu. O mesmo se aplica a um proxy que responde em nome do ponto final. Ambos os casos produzem um túnel que funciona enquanto a sua rota não faz nada.

Fixe o ponto final e leia a ordem da política

Uma rota de host é mais específica do que qualquer rota predefinida. Por isso uma /32 para o endereço do par ganha dentro da tabela que a contém. A forma habitual indica explicitamente o gateway e o dispositivo:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Essa rota só ajuda se a procura chegar a essa tabela. As regras de política são avaliadas por ordem e a primeira correspondência decide, por isso uma regra que envia tudo para uma segunda tabela contorna a sua rota de host em main. Leia as regras antes de assumir que a rota é autoritativa:

ip rule show
ip route get 203.0.113.40

Pergunte ao segundo comando com o mesmo endereço de origem ou marca que o cliente usa quando a política depende deles. Ele reporta a rota que o kernel escolheria, o que é uma prova sobre a procura e não uma prova de que o socket ativo usa esse caminho.

Quando o ponto final se desloca

Um nome de host que resolve para vários endereços invalida uma /32 permanente assim que a resposta muda. Um perfil com várias linhas remote tem o mesmo problema, porque o cliente pode aterrar em qualquer uma delas. Atualize a rota a partir dos próprios ganchos do ciclo de vida do cliente em vez de a adicionar à mão. Um script up que lê o par negociado e instala a rota de host mantém a exceção alinhada com a realidade, e um script down correspondente remove-a.

Registe a atualização no mesmo local que o resto da configuração de encaminhamento do host. Uma rota que só existe até ao próximo reinício é um teste, não uma correção.

Mantenha a política interior separada

Mover o caminho exterior não dá acesso a uma nova sub-rede privada nem altera quais destinos o servidor empurra para o túnel. A rota da camada inferior escolhe o cabo; as rotas empurradas escolhem o que entra no túnel. Manter essas duas decisões separadas é o que torna a divisão previsível.

Se o objetivo é apenas manter o tráfego cifrado fora de um link medido, deixe a rota predefinida em paz e adicione a única exceção de host. Substituir a rota predefinida de toda a máquina para mover uma única ligação VPN quebra qualquer outra aplicação no host.

Confirme o resultado com duas observações independentes: o endereço local e o dispositivo do socket, e a rota para a qual o destino privado resolve. Quando ambos coincidem com a sua intenção, a divisão é real. O manual do OpenVPN 2.6 cobre as opções remote e de ligação local que determinam a que endereço o cliente chama.