Masquerade ou encaminhamento por políticas: tráfego LAN por um gateway VPN

Colocar uma LAN inteira atrás de um túnel VPN é a parte fácil; decidir como o lado remoto vê esses clientes não é. O masquerade reescreve cada origem da LAN para o endereço do túnel do gateway, de modo que o extremo remoto responde a um único par. O encaminhamento por políticas mantém os endereços originais e exige que o extremo remoto saiba como chegar a eles. Nenhum dos dois é o padrão; a escolha decorre de quem possui o lado remoto e de a identidade por dispositivo importar.

Os dois desenhos prometem coisas diferentes

O masquerade reduz a LAN a um único host visível: o gateway. A rede remota responde a esse único endereço, e o gateway traduz as respostas de volta ao cliente que iniciou o fluxo. Não é necessária qualquer rota para os seus prefixos privados no lado remoto, e por isso este desenho sobrevive a um provedor que se recusa a transportá-los. O gateway também se torna a origem de cada ligação, pelo que o lado remoto não consegue distinguir dois clientes.

O encaminhamento por políticas mantém intacto o endereço de cada cliente. A rede remota vê a origem real e pode registá-la, aplicar uma regra por host ou enviar a resposta diretamente para esse endereço. Essa visibilidade é todo o objetivo, e vem com uma obrigação: o lado remoto tem de ter uma rota para o prefixo da LAN que aponte de volta pelo túnel. Planeie essa rota antes de ativar a regra, porque o túnel vai subir de qualquer forma e só faltarão as respostas.

Os modos de falha diferem tanto quanto as promessas. Uma regra de masquerade ausente produz pacotes que saem com origens privadas e nunca voltam. Uma rota de retorno ausente produz o mesmo sintoma no encaminhamento por políticas, mas a correção pertence ao router remoto e não ao gateway.

Masquerade: um único par no lado remoto

O caminho do masquerade tem uma ordem que importa. O encaminhamento tem de estar ativo antes de qualquer regra NAT servir para algo, a tabela de filtros tem de permitir o trânsito nos dois sentidos, e só então a tradução se aplica na interface do túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Os clientes continuam a precisar de um caminho para o gateway. Ou o gateway é o router predefinido deles, ou transportam uma rota específica para o prefixo remoto; se um router separado continuar a ser o predefinido, esse router precisa de uma rota estática para os destinos do túnel, caso contrário o pacote vai para o salto errado antes de o gateway o ver.

O DNS é uma decisão à parte. Um resolver do lado remoto só responde se a sua resposta puder viajar de volta ao cliente. Com masquerade a consulta parece vir do gateway, pelo que a rota de retorno do resolver já está satisfeita; com encaminhamento por políticas o resolver precisa da mesma rota de retorno que qualquer outro serviço remoto.

Encaminhamento por políticas: conserve a origem, acrescente uma rota de retorno

O encaminhamento por políticas começa com uma tabela e uma regra que a seleciona. O tráfego que entra pela interface da LAN é enviado para uma tabela dedicada, e essa tabela transporta uma rota predefinida pelo túnel. A tabela principal fica intacta, pelo que o tráfego originado pelo próprio gateway pode seguir outro caminho.

ip rule add iif eth1 table vpn
ip route add default dev tun0 table vpn

O lado remoto tem então de encaminhar o prefixo da LAN de volta pelo túnel. Isso é uma configuração no router remoto, não neste gateway. O gateway também tem de aceitar respostas que chegam por uma interface diferente da que a tabela principal preveria; a filtragem frouxa do caminho inverso (rp_filter definido para 2) é o ajuste habitual quando o modo estrito descarta esses pacotes.

Quando há dois túneis ativos, marque cada fluxo à entrada e deixe a marca escolher a tabela. Uma regra que só olha para a interface de entrada envia o tráfego dos dois túneis para a mesma tabela, pelo que o segundo túnel rouba fluxos ao primeiro. Teste essa marca com uma ligação que sobreviva a uma reconexão, que é quando uma política mista se manifesta.

Decida pela propriedade e pelo que o lado remoto registe

Se o túnel termina num provedor, use masquerade. Esse operador não vai encaminhar os seus intervalos privados de LAN e não tem motivo para distinguir clientes individuais atrás do seu gateway. Um único par visível é o único modelo que a política dele suporta, por isso dê-lhe isso e mantenha a tradução na sua margem. O provedor vê um par, que é exatamente o que a política dele espera, e os seus clientes herdam essa única identidade.

Se ambas as extremidades forem suas e os serviços remotos agirem sobre endereços de origem, o encaminhamento por políticas merece a sua rota extra. As regras da firewall, o acesso por utilizador e os registos de auditoria podem então distinguir clientes. Se o lado remoto só precisa de alcançabilidade, o masquerade é mais simples e elimina uma classe de erros de rota de retorno.

Os desenhos híbridos são normais: encaminhamento por políticas dentro da sua própria rede, masquerade na margem do provedor. O importante é anotar qual salto traduz e qual salto encaminha, porque uma regra NAT acidental acrescentada para um cliente esconde a origem a todos os clientes da mesma cadeia.

Verifique a partir de um cliente e depois de um segundo cliente

Execute o teste onde o tráfego começa. Verifique a rota que o host usa, observe o pacote aparecer na interface do túnel e inspecione o conntrack para a tradução. Essa sequência prova que o pacote seguiu o caminho previsto, e não que simplesmente chegou a algum sítio.

Repita o teste depois de uma reconexão. Uma regra de masquerade que nomeia a interface sobrevive a um novo endereço de túnel; uma regra que nomeia o endereço antigo não. Depois teste um segundo host da LAN, porque um desenho que funciona numa máquina depende muitas vezes da rota dessa mesma máquina e não da política do gateway.

Anote o modelo escolhido, a origem traduzida ou preservada e o proprietário da rota de retorno nas notas do gateway. Caso contrário, a próxima pessoa que acrescentar um cliente ou um túnel irá adivinhar, e adivinhar é como uma configuração LAN-para-VPN que funciona se torna parcial.