Como limitar o acesso entre dois escritórios ligados por VPN

Um túnel site a site responde a uma pergunta, se os dois escritórios podem trocar pacotes, e deixa a importante em aberto: qual dispositivo da filial pode alcançar qual serviço central. Tratar o túnel como confiança mútua é a forma como um portátil de visitante acaba no mesmo caminho do servidor financeiro. A solução não é um túnel melhor, mas uma lista de permissões explícita aplicada após a decifragem. Este guia leva essa lista da definição a uma recusa comprovada.

Trabalhe nesta ordem e não alargue a rota do túnel antes que os passos de política abaixo passem.

Escreva a matriz antes de tocar no gateway

Uma linha útil nomeia três coisas: um grupo de origem, um host ou rede de serviço de destino, e o protocolo e a porta que a aplicação realmente usa. A filial e o centro de dados não são entradas. O DNS privado e os serviços de autenticação merecem linhas próprias apenas quando a aplicação não pode funcionar sem eles.

Agrupe as origens por função e não por conveniência de sub-rede: pessoal, visitantes, administração. Quando as três partilham uma LAN plana, o gateway não as consegue distinguir na camada de rede, pelo que os controlos de identidade ou a segmentação têm de vir primeiro. Depois ponha a matriz por escrito, com um responsável e uma data de revisão em cada linha.

Aplique onde os pacotes são decifrados

As regras que permitem IKE e ESP constroem apenas o túnel exterior. O tráfego interno chega em claro à interface do túnel, e é aí que fica a lista de permissões: uma cadeia de encaminhamento no dispositivo que decifra, descarte predefinido, uma regra por linha da matriz. Em gateways Linux isso significa encaminhamento ativo e regras de filtragem no dispositivo do túnel, não no enlace físico, como explica o guia de encaminhamento do strongSwan.

Os seletores de tráfego são uma decisão de encaminhamento, não de autorização. Um seletor amplo que cobre as duas sub-redes pode estar certo para o encaminhamento enquanto a firewall continua a permitir apenas TCP 443 para um host. O seletor é negociado para o túnel e descreve o que pode entrar nele, não o que um dado dispositivo pode usar. Nunca alargue uma regra de firewall porque o seletor é amplo.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT e sub-redes sobrepostas mudam as regras

Quando o gateway da filial traduz cada host num único endereço antes do túnel, cada linha baseada na origem colapsa nesse único endereço. Ou deixa de traduzir o tráfego do túnel, ou aceita que as regras têm de assentar noutra coisa, como o endereço de origem original registado antes da tradução. O extremo remoto tem o mesmo problema, porque o host de destino vê o endereço depois do NAT e não o original.

Os intervalos sobrepostos são a outra armadilha. Dois escritórios que usam ambos 192.168.1.0/24 não podem ser descritos numa só tabela de política sem mapear um lado, e um mapeamento não substitui um endereçamento que não colide. Corrija o plano antes de escrever regras que terá de deslindar mais tarde.

Prove uma recusa, não apenas um sucesso

Testar apenas a aplicação permitida prova muito pouco, porque uma regra permissiva algures a montante produz o mesmo resultado.

A partir de um dispositivo comum da filial, alcance o serviço previsto e confirme que toda a sessão funciona. Depois tente um destino que tem de permanecer fechado, como uma porta administrativa num servidor com o qual a filial não tem nada a ver, e leia o contador ou a entrada de registo que o descartou. Desativar o conjunto de regras para verificar se funciona invalida o teste e deixa o gateway aberto enquanto olha.

Mantenha a lista viva

As aplicações mudam de lugar, e uma regra que sobrevive à sua aplicação torna-se um buraco que ninguém possui. Ligue a data de revisão à linha e altere o âmbito do seletor e a regra de firewall no mesmo passo de manutenção quando um serviço muda de endereço.

As restrições ao nível do host continuam a importar atrás do túnel: a firewall do próprio servidor deve aceitar o intervalo da filial apenas para o serviço que publica. Duas camadas que concordam são mais fáceis de auditar do que uma só em que se confia por completo.