Impedir que os clientes VPN se alcancen entre si no túnel

Dous clientes poden abrir ambos o host de salto e aínda así non ter nada que facer abríndose un ao outro. Alcanzar un servizo é unha decisión de reenvío, mentres que alcanzar un par é unha decisión de política, e a maioría das pilas VPN gárdaas en obxectos separados. Nada do que configure para a primeira impón a segunda. Así que o traballo non é engadir unha regra, senón atopar o obxecto que decide o tráfico entre pares neste servidor, escribir alí a denegación e demostrala desde un cliente.

Unha ruta ao servizo compartido non é un permiso entre pares

Anunciar a subrede de clientes dille a un par como pór un paquete no fío cara ao enderezo doutro cliente. Se ese paquete se entrega decídese despois, polo que o reenvía. Nunha pasarela Linux é a cadea FORWARD; dentro dun demoño no espazo de usuario é a propia táboa de sesións do túnel. Unha ruta responde á accesibilidade e deixa o permiso intacto.

Por iso unha comprobación de illamento que só le rutas non demostra nada. Pódese empurrar un /24 a cada cliente mentres cada paquete entre pares se descarta no gancho de reenvío. O caso perigoso é o contrario: ningunha regra explícita, un valor predeterminado permisivo e un illamento que só existe porque ninguén o probou.

Escriba o requisito nunha liña antes de abrir un terminal. Chegue ao bloque de servizos e ao host de salto, non chegue a nada máis dentro do bloque de clientes.

Descubra quen reenvía realmente o paquete entre pares

Dous comportamentos do servidor parecen iguais desde o lado do cliente e necesitan regras distintas. Ou o núcleo reenvía o paquete pola interface do túnel outra vez, ou o demoño cópiao entre sesións e o núcleo nunca o ve.

WireGuard pertence ao primeiro grupo: non ten conmutador entre pares, así que un paquete de 10.8.0.4 a 10.8.0.5 chega por wg0, toca o gancho de reenvío e volve encamiñarse por wg0 cando AllowedIPs cobre ambos os enderezos. OpenVPN é o segundo grupo en canto client-to-client está definido na configuración do servidor, porque esa directiva entrega o paquete entre sesións no espazo de usuario. Revise a configuración cargada por esa directiva antes de escribir nada. Unha regra do núcleo que nunca ve tráfico non se distingue dunha regra que funciona, e así acaba un despregamento sen ningún illamento.

Lea a configuración efectiva en lugar do ficheiro que supón cargado, porque os paquetes de distribución traen as súas propias inclusións. Se o demoño fai o reenvío, a denegación pertence aos seus propios controis por cliente, e a devasa do host só filtra o tráfico dirixido ao host. Se o núcleo reenvía, o gancho de reenvío é o único lugar que importa.

Os despregamentos encamiñados e traducidos necesitan unha comprobación máis: a fonte que ve un cliente afastado pode non ser a que espera. Entón unha regra que coincide coa subrede de clientes non coincide con nada. Anote o enderezo que sobrevive á tradución antes de escribir a coincidencia, e prefira facer coincidir o par de interfaces en lugar de adiviñar enderezos NAT.

Dea a cada enderezo unha identidade que se poida revogar por si soa

O illamento derrúbase en canto dous dispositivos comparten unha credencial. Unha regra ligada a esa identidade non os pode separar, e revogar un portátil perdido revoga todo o grupo. Certificados por dispositivo ou chaves por par manteñen a revogación local e a política lexible, porque cada enderezo corresponde exactamente a unha persoa ou máquina. Onde o deseño non o poida facer, dígao no manual de operacións en lugar de describir a regra como granular.

A asignación de enderezos debe concordar coa política. Reserve un bloque para servizos, un bloque para clientes, e reparta enderezos de clientes desde un conxunto que controle en lugar dun rango de primeiro en chegar. Se o servidor traduce ou fai ponte, manteña a táboa de mapeo xunto á configuración, porque esa táboa é o que o seguinte lector necesita para volver derivar a regra.

Pon a denegación onde o paquete cruza o túnel

Nunha pasarela que reenvía tráfico de WireGuard, dúas regras cobren o caso: permita o bloque de servizos e logo descarte o resto do bloque de clientes. O par de interfaces importa tanto como os enderezos, porque coincidir só no destino tamén atrapa o tráfico que chega da LAN. Cárgueas nesa orde para que o permiso se avalíe primeiro.

Con nftables o par entra nunha táboa inet filter existente, primeiro o permiso e despois o descarte. Ambas as coincidencias fixan o par de interfaces ademais dos enderezos.

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

Volva ler a cadea despois de cargala en lugar de confiar no estado de saída, e confirme que ambas as regras están na orde que pretendía. Engada regras ip6 coincidentes para o conxunto IPv6, ou o par v4 é decorativo nun túnel de dobre pila. Se o servidor xa ten unha política de reenvío permisiva, engada o descarte en lugar de substituír a cadea enteira.

Cando client-to-client está activado en OpenVPN, estas regras de reenvío nunca coinciden co tráfico entre pares e a denegación debe vivir nos controis propios do demoño. Manteña as regras do núcleo para o tráfico dirixido ao host, pero non as conte como o control de illamento.

Demostre a denegación desde un cliente, non desde o servidor

Probar desde a pasarela non demostra nada, porque o tráfico xerado localmente toma o camiño de saída e nunca cruza o gancho de reenvío. Use dous clientes reais: un que debería alcanzar o servizo e outro que debería ser rexeitado. Execute primeiro o caso permitido, para que un túnel roto non se confunda cunha política que funciona.

Desde o cliente permitido, confirme que o servizo responde no seu porto. Desde o mesmo cliente, probe o enderezo do par e espere un descarte silencioso en lugar dun rexeitamento:

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

Un paquete descartado e un par desconectado parecen ambos un tempo de espera, así que revise os contadores antes de concluír nada. Confirme que o contador da regra de descarte aumenta mentres o par está demostrablemente activo. Repita por IPv6, onde unha regra ip6 ausente deixa a denegación v4 como se fose efectiva. Anote os resultados aceptados e rexeitados no manual coa data, porque a próxima migración volverá derivar a regra.