Clientes VPN e a LAN: quando usar uma zona separada

Colocar a interface do túnel na zona da LAN é o caminho mais curto para uma VPN a funcionar, e normalmente é o padrão errado. Concede ao cliente remoto a mesma confiança que a LAN com cabo tem, o que a tarefa raramente exige. Uma zona separada custa algumas regras e torna a fronteira visível. A decisão não é se as zonas são melhores; é quais três condições se aplicam à sua rede.

O nome da zona não cifra nada nem autentica utilizador. Apenas agrupa interfaces para o modelo de políticas da firewall.

O que a pertença a uma zona controla realmente

Uma zona agrupa interfaces ou tráfego dentro do modelo da firewall. As suas definições de entrada, saída e encaminhamento governam depois papéis diferentes. A entrada é o tráfego para o próprio router; o encaminhamento é o tráfego que o atravessa para outro host. A documentação do OpenWrt sobre zonas trata entrada, saída e encaminhamento como definições separadas exatamente por esse motivo.

Uma autorização da zona VPN para a zona LAN não é automaticamente uma autorização inversa. As regras de encaminhamento têm direção, e uma regra que permite tráfego de cliente para servidor não permite sessões de servidor para cliente. Um cliente que consegue abrir uma ligação para um servidor não é um cliente para o qual o servidor consiga abrir uma ligação de volta.

Essa distinção é a razão pela qual uma zona separada é útil: pode declarar cada direção e cada papel de forma explícita. Escreva a direção ao lado de cada regra.

Decisão um: entrada, encaminhamento ou ambos

Se os clientes remotos precisam de DNS do router, permita entrada apenas para esse serviço. Se precisam de chegar a um servidor de ficheiros, permita encaminhamento para esse destino. A maioria dos projetos de VPN precisa de ambos, mas para serviços diferentes.

O acesso amplo de entrada a todos os serviços locais quase nunca é necessário. Trate a gestão do router como uma decisão separada do acesso a aplicações. Se o router só precisa de responder a DNS, escreva essa única autorização e deixe o resto fechado.

Decisão dois: que recursos os clientes remotos precisam

Liste os intervalos de clientes, os destinos e os serviços que a VPN deve fornecer antes de escrever regras. Uma lista de destinos é mais útil do que um rótulo de confiança, porque sobrevive a uma migração da firewall.

Mantenha as interfaces de gestão separadas do acesso normal às aplicações. Um cliente remoto que chega a uma wiki não precisa por isso da página de administração do router nem da consola do hipervisor.

Se um destino autorizado puder encaminhar mais além, a fronteira da zona termina na firewall, não no que o destino faz a seguir.

Decisão três: como vai provar a fronteira

Teste um fluxo autorizado e um deliberadamente negado após cada alteração. Provar que um site carrega não revela uma autorização ampla não intencional. Teste a partir do intervalo de endereços do cliente VPN, não da LAN, e inclua a direção que espera que falhe. Registe ambos os resultados ao lado da regra.

Preserve o acesso de recuperação do gateway antes de alterar a política da zona remota. Use a configuração gerida persistente em vez de edições em tempo de execução, ou o próximo reinício restaurará a confiança antiga. Uma cópia da configuração anterior, guardada fora do dispositivo, é a reversão mais barata que alguma vez terá.

À medida que a rede cresce, documente a pertença e o propósito das regras. Uma interface recentemente ligada não deve herdar privilégios só porque alguém lhe deu um nome de zona conveniente.