Encaminhe uma sub-rede LAN pela OpenVPN e mantenha a rota padrão

Máquinas que encaminham para uma LAN e ao mesmo tempo discam uma VPN acabam na mesma discussão consigo mesmas: o túnel quer possuir a rota padrão, e a LAN precisa dela de volta. Quando a OpenVPN se liga, pode instalar uma rota padrão através do túnel ou um par de meias rotas padrão, o que é correto para um portátil e errado para uma gateway cujos vizinhos esperam respostas do seu endereço LAN. A resposta não é dispensar a VPN. A resposta é dar às duas decisões tabelas diferentes.

Uma rota padrão, dois proprietários

O tráfego encaminhado e o tráfego originado localmente não têm de seguir o mesmo caminho. Os clientes da LAN só precisam do túnel para os destinos que escolher, enquanto as sessões de gestão do próprio host e as suas respostas a esses clientes precisam da rota padrão da LAN. Misturar ambos na tabela principal força uma única resposta a duas perguntas diferentes.

A OpenVPN tem um interruptor exatamente para isto. route-noexec impede o cliente de tocar na tabela principal, e os valores que teria usado são exportados para um script route-up como route_vpn_gateway, dev e os endereços da interface. Depois decide que tabela recebe que rota, em código que poderá ler mais tarde.

Tabela de políticas versus reescrever a principal

A tabela separada é a única opção que escala para além de uma sub-rede. Dê-lhe um nome uma vez e depois refira-se a ela pelo nome, para que ninguém tenha de memorizar um número:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Os endereços aqui são marcadores. Substitua o prefixo LAN, a gateway do túnel e o nome do dispositivo da sua própria instalação antes de executar seja o que for.

A regra também tem de corresponder ao host

Uma regra que só corresponde ao prefixo LAN cobre os pacotes encaminhados. Não cobre o tráfego que a própria gateway origina, nem as respostas que envia de volta aos clientes da LAN, que transportam o endereço LAN da gateway como origem. Essas consultas caem em main e ainda podem sair pelo túnel.

Acrescente uma segunda regra para o endereço LAN da própria gateway, ou alargue a primeira regra a um conjunto que inclua ambas. A ordem importa: coloque primeiro a regra mais específica e verifique o resultado com uma consulta que nomeie a origem explicitamente.

ip route get 203.0.113.9 from 192.168.50.1

Se isso reportar o dispositivo do túnel para um destino que devia ficar local, o conjunto de regras está errado independentemente do que a tabela contém.

NAT ou uma rota do outro lado

O servidor VPN conhece a sub-rede do túnel e mais nada. Os pacotes que chegam com um endereço de origem LAN não têm caminho de volta a menos que alguém o forneça, e há exatamente duas formas de o fornecer. Acrescentar uma rota para o prefixo LAN no servidor mantém a origem original visível de ponta a ponta, que é o que um desenho auditado costuma querer. O mascaramento na gateway reescreve a origem para o endereço do túnel e não precisa de qualquer cooperação do servidor.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Escolha NAT quando não controla o servidor e não pode acrescentar lá rotas. Escolha a rota do lado do servidor quando os registos, o controlo de acesso ou a simetria do caminho de volta importam, porque o mascaramento apaga o endereço original de tudo o que o outro lado registe.

De qualquer forma o encaminhamento tem de estar ativo, e a filtragem estrita do caminho inverso pode descartar a resposta quando main não teria escolhido o túnel para essa origem. Verifique o valor efetivo antes de culpar o túnel.

Faça a divisão sobreviver a uma reconexão

As regras e rotas acrescentadas à mão desaparecem quando a interface é recriada, e uma entrada de tabela obsoleta pode sobreviver à sessão que a justificava. Coloque a regra de tabela, a rota do túnel e a entrada de mascaramento no script route-up do cliente, e limpe a tabela no início do script para que uma gateway antiga não sobreviva na nova sessão.

Verifique a partir dos dois extremos: uma consulta na gateway com a origem LAN, e um pedido real de um cliente da LAN para um destino que deva atravessar o túnel. Uma rota que existe mas nunca é escolhida comporta-se exatamente como nenhuma rota, até ler os contadores.