Limitar um gateway OpenVPN a uma única LAN com regras do UFW

Decida a permissão antes de abrir um arquivo de firewall: clientes autenticados podem abrir conexões para uma sub-rede específica, e o gateway deve recusar qualquer outro caminho de trânsito mesmo quando um cliente instala rotas adicionais. Essa frase é o desenho, e cada regra abaixo existe para impô-lo. Algo mais amplo, como todo o espaço de endereços privados, a saída para a internet pelo túnel ou o tráfego entre pares, é outro desenho que precisa da sua própria decisão. As regras também são deliberadamente entediantes, porque um firewall esperto é aquele que ninguém poderá auditar depois.

Escreva primeiro a topologia e a permissão

O exemplo usa um servidor Community OpenVPN com um dispositivo TUN no espaço de usuário chamado tun0, um conjunto de clientes 10.77.0.0/24, e uma sub-rede conectada 192.168.60.0/24 em lan0. O encaminhamento IPv4 já funciona e a LAN já tem uma rota de volta para o conjunto, então nada aqui depende da tradução entre os dois.

O UFW é o dono do firewall neste host, e nenhum conjunto de regras de contêiner nem tabela nftables separada pode instalar um caminho de aceitação anterior. Um atalho de descarga de fluxo que pula o filtro tornaria as cadeias de guarda decorativas, então confirme que nenhum está ativo. Deixe o encaminhamento client-to-client do próprio OpenVPN desativado, porque o tráfego entre pares que nunca atravessa o filtro do sistema operacional não pode ser limitado por ele. O ouvinte externo e as regras de administração ficam como estão, já que esta mudança governa o tráfego decifrado do túnel em vez de substituir o firewall.

Coloque as guardas antes das aceitações iniciais do UFW

Uma permissão de rota seguida de uma negação não basta para uma fronteira estrita. As regras before padrão aceitam o tráfego estabelecido e alguns ICMP antes de qualquer regra de usuário ser consultada, então um fluxo permitido na semana passada pode ficar fora da nova restrição de destino apenas porque ainda tem estado. Faça cópia de segurança dos arquivos do UFW e mantenha um console fora de banda aberto antes de editar.

Na seção *filter do arquivo /etc/ufw/before.rules, declare duas cadeias ao lado das declarações existentes e antes de qualquer linha de regra.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Logo após as declarações, e antes das permissões de entrada e de encaminhamento, salte para dentro delas e defina o que elas admitem.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Mantenha o resto da seção e a sua linha COMMIT. Colar uma segunda tabela de filtro ou apagar regras não relacionadas é como uma mudança de firewall se torna uma queda, e o arquivo está a um reinício de ser a única cópia que importa.

Leia o que cada guarda admite e recusa

A primeira cadeia continua o processamento apenas quando a origem está no conjunto, o destino é a única sub-rede, a interface de saída é a LAN e o pacote viaja na direção original do seu fluxo. Todo o resto que chega do túnel é descartado, incluindo uma origem fora do conjunto e qualquer destino além da sub-rede permitida.

Um pacote entre pares entra e sai pelo tun0, então falha o teste de interface da LAN ainda antes de qualquer verificação de destino. As novas conexões da LAN para os clientes também falham o teste de direção da resposta, o que fecha por padrão o caminho de retorno invertido.

O destino RETURN mantém a política normal do UFW em jogo. Essas cadeias filtram, e a permissão de rota que você adiciona em seguida ainda decide se um pacote sobrevivente é aceito. É essa separação que permite mudar a sub-rede permitida num só lugar mais tarde. Se as guardas aceitassem os pacotes diretamente, cada regra futura teria de ser adicionada duas vezes.

Autorize a sub-rede e feche as portas laterais

Pré-visualize primeiro a permissão de rota e depois retire o sinalizador de pré-visualização para aplicá-la: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Em seguida, reveja a ordem das regras de usuário, porque uma negação anterior ainda vence uma permissão posterior. Uma permissão para toda a sub-rede também é a forma errada quando só a porta HTTPS de um host deve estar acessível.

Note o que o descarte de entrada faz: os clientes do túnel não alcançam nenhum serviço no próprio gateway, incluindo um ouvinte DNS ligado ao seu endereço de LAN. Alojar DNS ali exige uma exceção deliberada antes do descarte e um contrato de permissão revisto. Se o UFW gerir IPv6, acrescente descartes correspondentes para tun0 em before6.rules também, porque uma lista de destinos IPv4 nada diz sobre pacotes IPv6.

Verifique a política carregada, não a pré-visualização

Pré-visualize a recarga, aplique-a numa janela de manutenção e leia o conjunto de regras vivo.

sudo ufw --dry-run reload
sudo ufw show raw

Confirme que as guardas do túnel aparecem antes das permissões padrão de estado e ICMP. O ufw status simples não mostra regras before editadas à mão, e é por isso que os operadores concluem que falta uma regra quando na verdade ela está carregada. Leia a listagem crua de cima para baixo em vez de procurar um fragmento. Se as guardas aparecerem depois de uma permissão de estado, a fronteira não está a fazer o que o arquivo sugere.

Depois teste o comportamento, não o texto. Abra uma conexão nova para um host permitido e observe a resposta, encaminhe um pedido inofensivo para um destino fora da sub-rede e confirme que morre, tente uma conexão entre pares, tente um serviço local ao gateway e tente uma conexão não solicitada da LAN para um cliente. Inclua um fluxo fora do âmbito que existia antes da mudança, e apague apenas esse fluxo em vez de esvaziar toda a tabela de rastreamento da máquina.

Anote os limites ao lado das regras: isto limita o trânsito e nada mais. Não impede um cliente de usar a sua própria ligação à internet, não impede um host permitido da LAN de reencaminhar tráfego para além, e não substitui a autenticação dentro dos serviços permitidos.