Impeça os clientes VPN de se alcançarem no túnel

Dois clientes podem ambos abrir o host de salto e ainda assim não ter nada a ver com abrir um ao outro. Alcançar um serviço é uma decisão de encaminhamento, enquanto alcançar um par é uma decisão de política, e a maioria das pilhas VPN guarda-as em objetos separados. Nada do que configura para a primeira impõe a segunda. A tarefa, portanto, não é acrescentar uma regra, mas encontrar o objeto que decide o tráfego entre pares neste servidor, escrever a negação lá e prová-la a partir de um cliente.

Uma rota para o serviço partilhado não é uma permissão entre pares

Anunciar a sub-rede de clientes diz a um par como colocar um pacote no fio em direção ao endereço de outro cliente. Se esse pacote é entregue decide-se depois, por aquilo que o encaminha. Num gateway Linux é a cadeia FORWARD; dentro de um daemon no espaço do utilizador é a própria tabela de sessões do túnel. Uma rota responde à acessibilidade e deixa a permissão intacta.

Por isso uma verificação de isolamento que só lê rotas não prova nada. Pode empurrar-se um /24 para cada cliente enquanto cada pacote entre pares é descartado no gancho de encaminhamento. O caso perigoso é o inverso: nenhuma regra explícita, um valor predefinido permissivo e um isolamento que só existe porque ninguém o testou.

Escreva o requisito numa linha antes de abrir um terminal. Alcance o bloco de serviços e o host de salto, não alcance mais nada dentro do bloco de clientes.

Descubra quem encaminha realmente o pacote entre pares

Dois comportamentos do servidor parecem iguais do lado do cliente e exigem regras diferentes. Ou o núcleo encaminha o pacote pela interface do túnel outra vez, ou o daemon copia-o entre sessões e o núcleo nunca o vê.

O WireGuard pertence ao primeiro grupo: não tem qualquer comutador entre pares, por isso um pacote de 10.8.0.4 para 10.8.0.5 chega em wg0, atinge o gancho de encaminhamento e é encaminhado de novo para fora de wg0 quando AllowedIPs cobre os dois endereços. O OpenVPN é o segundo grupo assim que client-to-client está definido na configuração do servidor, porque essa diretiva entrega o pacote entre sessões no espaço do utilizador. Verifique a configuração carregada quanto a essa diretiva antes de escrever o que quer que seja. Uma regra do núcleo que nunca vê tráfego é indistinguível de uma regra que funciona, e é assim que uma implementação acaba sem qualquer isolamento.

Leia a configuração efetiva em vez do ficheiro que assume carregado, porque os pacotes das distribuições trazem as suas próprias inclusões. Se o daemon faz o encaminhamento, a negação pertence aos seus próprios controlos por cliente, e uma firewall do anfitrião só filtra o tráfego dirigido ao anfitrião. Se o núcleo encaminha, o gancho de encaminhamento é o único lugar que importa.

Implementações encaminhadas e traduzidas precisam de mais uma verificação: a fonte que um cliente distante vê pode não ser a que espera. Então uma regra que corresponde à sub-rede de clientes não corresponde a nada. Anote o endereço que sobrevive à tradução antes de escrever a correspondência, e prefira corresponder ao par de interfaces em vez de adivinhar endereços NAT.

Dê a cada endereço uma identidade que se possa revogar sozinha

O isolamento desmorona-se assim que dois dispositivos partilham uma credencial. Uma regra ligada a essa identidade não os pode separar, e revogar um portátil perdido revoga todo o grupo. Certificados por dispositivo ou chaves por par mantêm a revogação local e a política legível, porque cada endereço corresponde exatamente a uma pessoa ou máquina. Onde o desenho não o pode fazer, diga-o no manual de operações em vez de descrever a regra como granular.

A atribuição de endereços tem de concordar com a política. Reserve um bloco para serviços, um bloco para clientes, e distribua endereços de clientes a partir de um conjunto que controla e não de um intervalo de primeiro a chegar. Se o servidor traduz ou faz ponte, mantenha a tabela de mapeamento junto à configuração, porque é essa tabela que o leitor seguinte precisa para voltar a derivar a regra.

Coloque a negação onde o pacote atravessa o túnel

Num gateway que encaminha tráfego WireGuard, duas regras cobrem o caso: permita o bloco de serviços e depois descarte o resto do bloco de clientes. O par de interfaces importa tanto como os endereços, porque corresponder apenas no destino também apanha tráfego vindo da LAN. Carregue-as nessa ordem para que a permissão seja avaliada primeiro.

Com nftables o par entra numa tabela inet filter existente, primeiro a permissão e depois o descarte. Ambas as correspondências fixam o par de interfaces e os endereços.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Releia a cadeia depois de carregar em vez de confiar no estado de saída, e confirme que ambas as regras estão na ordem pretendida. Acrescente regras ip6 correspondentes para o conjunto IPv6, senão o par v4 é decorativo num túnel de pilha dupla. Se o servidor já tem uma política de encaminhamento permissiva, acrescente o descarte em vez de substituir a cadeia inteira.

Quando client-to-client está ativado no OpenVPN, estas regras de encaminhamento nunca correspondem ao tráfego entre pares e a negação tem de viver nos controlos próprios do daemon. Mantenha as regras do núcleo para o tráfego dirigido ao anfitrião, mas não as conte como o controlo de isolamento.

Prove a negação a partir de um cliente, não do servidor

Testar a partir do gateway não prova nada, porque o tráfego gerado localmente toma o caminho de saída e nunca atravessa o gancho de encaminhamento. Use dois clientes reais: um que deveria alcançar o serviço e um que deveria ser recusado. Execute primeiro o caso permitido, para que um túnel quebrado não seja tomado por uma política a funcionar.

A partir do cliente permitido, confirme que o serviço responde na sua porta. A partir do mesmo cliente, tente o endereço do par e espere um descarte silencioso em vez de uma recusa:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Um pacote descartado e um par offline parecem ambos um tempo limite, por isso verifique os contadores antes de concluir algo. Confirme que o contador da regra de descarte aumenta enquanto o par está comprovadamente ativo. Repita por IPv6, onde uma regra ip6 em falta deixa a negação v4 como se fosse eficaz. Registe os resultados aceites e recusados no manual com a data, porque a próxima migração vai voltar a derivar a regra.