Zona VPN do OpenWrt, encaminhamento e mascaramento: qual é necessário?

Três alterações misturam-se sempre que uma VPN encontra o OpenWrt: abrir uma porta, permitir o encaminhamento e ativar o mascaramento. Respondem a perguntas diferentes, e normalmente só uma delas é o requisito real. Ler cada controlo segundo o papel do tráfego que governa transforma um palpite numa decisão, e também diz que sintoma esperar quando a alteração está errada. Comece por nomear o papel que falhou, não a caixa que recorda.

Nomeie o papel do tráfego antes de tocar num controlo

A entrada de zona decide o que pode chegar ao próprio router. A saída de zona cobre o tráfego que o router origina, o encaminhamento de zona é o valor predefinido para o tráfego que atravessa uma zona, e o mascaramento decide se o endereço de origem é reescrito à saída. São quatro perguntas diferentes, e uma política de zona responde a todas de uma vez com o mesmo valor, por isso uma alteração em toda a zona é um instrumento grosseiro. Uma regra com nome pode responder a uma delas sem tocar nas restantes.

O mapa útil é por papel do tráfego, porque é isso que pode observar quando algo falha. Cada papel abaixo tem um controlo que o decide e um sintoma que aponta para ele:

Um serviço à escuta no router precisa de uma única regra de entrada estreita

Um servidor OpenVPN no router recebe tráfego dirigido ao router, por isso a sua ligação exterior depende da política de entrada da zona que o transporta. Permita o transporte e a porta configurados e deixe tudo o resto dessa zona em rejeição. Uma única regra de porta é uma alteração muito menor do que uma aceitação em toda a zona, e é aquela que ainda poderá explicar dentro de um ano.

Duas coisas tornam essa regra segura de manter: nomeia a porta que o serviço usa realmente, e fica ao lado da definição da zona para que a pessoa seguinte veja porque existe. As linhas abaixo são a forma, com a porta no lugar do que está configurado no servidor. Altere essa porta nos dois locais quando o serviço se mudar, porque uma regra que fica na antiga é invisível até uma auditoria.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valide antes de recarregar, porque um erro de sintaxe num ficheiro de firewall pode deixar o router sem um conjunto de regras funcional. Numa versão que usa fw4 a verificação é um comando separado, e falha ruidosamente em vez de aceitar em silêncio um bloco quebrado. Recarregue só depois de a verificação passar, e guarde o ficheiro anterior onde o possa repor.

fw4 check
service firewall reload

O pedido de um cliente atravessa o encaminhamento, não a entrada

Depois da autenticação, o pedido de um cliente de túnel a um serviço da LAN produz um fluxo encaminhado, por isso o controlo que o decide é a relação de encaminhamento entre a zona do túnel e a zona LAN. Atribua a interface do túnel à zona pretendida e depois declare a direção, as fontes e o serviço. A atribuição de zona é o que dá sentido à regra de encaminhamento, e as duas só se entendem lidas em conjunto. Uma relação de encaminhamento que nomeia a zona do túnel como origem e a zona LAN como destino lê-se como uma decisão deliberada, enquanto duas aceitações em toda a zona se leem como um acidente.

Chegar ao próprio router continua a usar o caminho de entrada, por isso um ping à gateway não diz nada sobre a partilha de ficheiros por trás dela. Essas duas falhas vivem em blocos diferentes e corrigem-se com alterações diferentes. Escreva ambos os caminhos em separado antes de alterar qualquer um deles.

O mascaramento é uma decisão de encaminhamento, não uma permissão

O mascaramento reescreve o endereço de origem do tráfego de saída selecionado. Pode salvar um desenho de saída em que o lado remoto não tem rota de regresso, e também esconde os endereços de clientes individuais a qualquer serviço que registe ou autorize por endereço. Desativá-lo é uma escolha de encaminhamento sobre o caminho de regresso, não um interruptor de segurança que fecha um buraco de entrada. Um túnel que funciona com a tradução ativa e falha no momento em que esta é desativada costuma ter uma rota de regresso em falta, não uma regra de firewall em falta.

A alternativa encaminhada precisa de uma rota de regresso do lado remoto em vez da tradução. Nenhuma das opções fornece a permissão da firewall ou a conta da aplicação, por isso desativar o mascaramento quase nunca corrige um cliente de túnel que não chega a lado nenhum. Trate também a política IPv4 e a IPv6 em separado, porque uma única definição de tradução não descreve as duas famílias.

Prove a decisão com um pedido permitido e outro rejeitado

Envie um pedido que deveria ser permitido e outro que deveria ser rejeitado, e depois identifique o controlo que tomou cada decisão. Uma página que carrega por acaso não é prova; a prova é a regra que correspondeu, na cadeia onde correspondeu. A rejeição conta tanto como o sucesso, porque mostra que a política faz alguma coisa em vez de estar tudo permitido.

Dois comandos dão-lhe essa prova numa versão atual. O contador da regra correspondente mexe-se quando o pedido é aceite, e o registo mostra o descarte se ativou o registo para a regra:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Mantenha um caminho de administração que ainda possa usar antes de alterar qualquer política de firewall, e siga o processo de validação e reversão do proprietário da configuração. Uma alteração que o deixa fora do router não é um resultado de teste, é um segundo incidente. Anote a zona e o papel do tráfego junto a cada observação, para que o par de resultados explique a política em vez de descrever um carregamento de página com sorte.