Clientes da LAN ignoram a VPN do roteador até ativar o roteamento por políticas

O roteador chega à internet pelo seu túnel, enquanto um portátil atrás dele continua a reportar o endereço do ISP. Adicionar regras de aceitação não ajuda, e essa falha é reveladora: a filtragem responde se um pacote pode passar, não para onde vai. A escolha da interface já foi feita por uma consulta de roteamento que nada sabe sobre a sua lista de clientes. Corrija a consulta e a firewall deixa de ser a suspeita.

Uma regra de filtro não pode escolher uma interface

O fluxo de pacotes num roteador Linux executa primeiro a decisão de roteamento e depois o gancho de encaminhamento. Quando uma regra corresponde ao dispositivo de túnel de saída, o kernel já decidiu que o túnel é a saída. Se a tabela principal ainda preferir a rota padrão da WAN, o pacote segue para o ISP e a regra de aceitação que acabou de escrever nunca o vê. Esse único facto de ordem explica porque é que uma página de novas regras de firewall não muda nada.

O exemplo abaixo usa uma LAN de 192.168.8.0/24 em br-lan, um dispositivo de túnel tun0 e um descodificador em 192.168.8.23 que deveria usar o túnel.

Leia a consulta antes de editar regras

Peça ao kernel que resolva uma rota em nome desse cliente. A resposta inclui o dispositivo de saída e o endereço de origem que seria escolhido, e isso é tudo o que precisa para confirmar o diagnóstico. Se a resposta nomear o dispositivo da WAN, o pacote nunca teve oportunidade de chegar à sua regra.

ip -4 route get 198.51.100.7 from 192.168.8.23

Repita a consulta para um cliente que deveria ficar no caminho normal. Quando ambas as respostas nomeiam o mesmo dispositivo, ainda não há qualquer política por origem em jogo, e a correção pertence ao roteamento e não à filtragem.

Associe uma tabela aos clientes que quer cobrir

O roteamento por políticas insere uma consulta de regras antes da tabela principal. Crie uma tabela cuja rota padrão seja o túnel e depois ligue essa tabela a um seletor: uma interface de entrada, um endereço de origem ou uma marca de firewall. As prioridades decidem a ordem, e a tabela principal fica muito abaixo na lista, em 32766, pelo que uma regra com número baixo é consultada primeiro. Os seletores de interface cobrem todos os clientes da ponte; os seletores de endereço cobrem uma máquina.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

As interfaces do firmware costumam expor os mesmos objetos que uma página de roteamento por políticas ou de política de VPN. Uma lista de dispositivos aí é mais fácil de manter do que regras escritas à mão e costuma sobreviver a atualizações que mudam a sintaxe das regras.

Escolha o seletor de propósito. Uma regra de interface é curta e duradoura, mas também capta o tráfego de gestão do próprio roteador que chega a essa ponte. Uma regra de origem é exata e precisa de edição sempre que a lista de dispositivos muda. Anote a escolha, porque a próxima pessoa que perguntar porque é que um dispositivo se comporta de forma diferente vai precisar dela.

Mantenha os destinos locais fora do túnel

Uma tabela nova só conhece as rotas que lá colocar. Falta o prefixo da LAN, por isso o tráfego da impressora e do NAS seguiria a rota padrão do túnel e desapareceria. Uma rota throw termina a consulta nesta tabela e devolve a decisão à tabela principal.

ip -4 route add throw 192.168.8.0/24 table 200

Se saltar essa rota, as partilhas locais quebram, e a sessão de gestão do próprio roteador pode desaparecer se o seletor for mais amplo do que o previsto. Depois resolva a questão da origem: os pacotes do túnel que ainda carregam endereços da LAN precisam que o outro lado conheça um caminho de regresso, enquanto o masquerading no túnel elimina esse requisito e elimina também a identidade do cliente que o outro lado veria.

As regras e rotas adicionadas em tempo de execução desaparecem após um reinício ou uma atualização de firmware. Adicione-as ao mecanismo de arranque do roteador, reinicie uma vez e volte a testar a partir do cliente: o seu endereço público, um segundo cliente que deveria ficar na WAN e os contadores do túnel durante uma nova ligação.