Atureu els clients VPN perquè no s’abastin entre ells al túnel

Dos clients poden obrir tots dos l’amfitrió de salt i tot i així no tenir cap motiu per obrir-se l’un a l’altre. Abastar un servei és una decisió de reenviament, mentre que abastar un parell és una decisió de política, i la majoria de piles VPN les guarden en objectes separats. Res del que configureu per a la primera no aplica la segona. Per tant, la feina no és afegir una regla, sinó trobar l’objecte que decideix el trànsit entre parells en aquest servidor, escriure-hi el bloqueig i demostrar-lo des d’un client.

Una ruta cap al servei compartit no és un permís entre parells

Anunciar la subxarxa de clients diu a un parell com posar un paquet al fil cap a l’adreça d’un altre client. Si aquell paquet es lliura es decideix després, per allò que el reenvia. En una passarel·la Linux és la cadena FORWARD; dins d’un dimoni en espai d’usuari és la taula de sessions pròpia del túnel. La ruta respon a l’abastabilitat i deixa el permís intacte.

Per això una comprovació d’aïllament que només llegeix rutes no demostra res. Es pot empènyer una /24 a cada client mentre cada paquet entre parells es descarta al ganxo de reenviament. El cas perillós és el contrari: cap regla explícita, un valor per defecte permissiu i un aïllament que només existeix perquè ningú no l’ha provat.

Escriviu el requisit en una línia abans d’obrir un terminal. Arribeu al bloc de serveis i a l’amfitrió de salt, no arribeu a res més dins del bloc de clients.

Esbrineu qui reenvia realment el paquet entre parells

Dos comportaments del servidor semblen iguals des del costat del client i necessiten regles diferents. O el nucli reenvia el paquet per la interfície del túnel una altra vegada, o el dimoni el copia entre sessions i el nucli no el veu mai.

WireGuard és del primer grup: no té cap commutador entre parells, així que un paquet de 10.8.0.4 a 10.8.0.5 arriba a wg0, toca el ganxo de reenviament i es torna a encaminar per wg0 quan AllowedIPs cobreix les dues adreces. OpenVPN és del segon grup quan client-to-client està definit a la configuració del servidor, perquè aquesta directiva lliura el paquet entre sessions en espai d’usuari. Reviseu la configuració carregada per a aquesta directiva abans d’escriure res. Una regla del nucli que no veu mai trànsit no es distingeix d’una regla que funciona, i així acaba un desplegament sense cap aïllament.

Llegiu la configuració efectiva i no el fitxer que suposeu carregat, perquè els paquets de distribució porten les seves pròpies inclusions. Si el dimoni fa el reenviament, el bloqueig pertany als seus propis controls per client, i el tallafoc de l’amfitrió només filtra el trànsit adreçat a l’amfitrió. Si el nucli reenvia, el ganxo de reenviament és l’únic lloc que importa.

Els desplegaments encaminats i traduïts necessiten una comprovació més: la font que veu un client llunyà pot no ser la que espereu. Llavors una regla que coincideix amb la subxarxa de clients no coincideix amb res. Anoteu l’adreça que sobreviu a la traducció abans d’escriure la coincidència i preferiu fer coincidir la parella d’interfícies en lloc d’endevinar adreces NAT.

Doneu a cada adreça una identitat que es pugui revocar per si sola

L’aïllament s’enfonsa tan bon punt dos dispositius comparteixen una credencial. Una regla lligada a aquesta identitat no els pot separar, i revocar un portàtil perdut revoca tot el grup. Certificats per dispositiu o claus per parell mantenen la revocació local i la política llegible, perquè cada adreça correspon exactament a una persona o màquina. On el disseny no ho pot fer, digueu-ho al manual d’operacions en lloc de descriure la regla com a granular.

L’assignació d’adreces ha de concordar amb la política. Reserveu un bloc per als serveis, un bloc per als clients, i repartiu adreces de clients des d’un conjunt que controleu i no des d’un rang de qui arriba primer. Si el servidor tradueix o fa pont, tingueu la taula de mapatge al costat de la configuració, perquè és el que el lector següent necessita per tornar a derivar la regla.

Poseu el bloqueig on el paquet travessa el túnel

En una passarel·la que reenvia trànsit de WireGuard, dues regles cobreixen el cas: permeteu el bloc de serveis i després descarteu la resta del bloc de clients. La parella d’interfícies importa tant com les adreces, perquè coincidir només en destí també atrapa el trànsit que arriba de la LAN. Carregueu-les en aquest ordre perquè el permís s’avalui primer.

Amb nftables la parella entra en una taula inet filter existent, primer el permís i després el descart. Totes dues coincidències fixen la parella d’interfícies així com les adreces.

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

Rellegiu la cadena després de carregar-la en lloc de confiar en l’estat de sortida, i confirmeu que totes dues regles seuen en l’ordre que volíeu. Afegiu regles ip6 coincidents per al conjunt IPv6, o la parella v4 és decorativa en un túnel de doble pila. Si el servidor ja té una política de reenviament permissiva, afegiu el descart en lloc de substituir la cadena sencera.

Quan client-to-client està activat a OpenVPN, aquestes regles de reenviament no coincideixen mai amb el trànsit entre parells i el bloqueig ha de viure en els controls propis del dimoni. Manteniu les regles del nucli per al trànsit adreçat a l’amfitrió, però no les compteu com el control d’aïllament.

Demostreu el bloqueig des d’un client, no des del servidor

Provar des de la passarel·la no demostra res, perquè el trànsit generat localment pren el camí de sortida i no travessa mai el ganxo de reenviament. Feu servir dos clients reals: un que hauria d’arribar al servei i un que hauria de ser refusat. Executeu primer el cas permès, perquè un túnel trencat no es confongui amb una política que funciona.

Des del client permès, confirmeu que el servei respon al seu port. Des del mateix client, proveu l’adreça del parell i espereu un descart silenciós en lloc d’un refús:

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 paquet descartat i un parell fora de línia semblen tots dos un temps d’espera, així que reviseu els comptadors abans de concloure res. Confirmeu que el comptador de la regla de descart augmenta mentre el parell és demostradament actiu. Repetiu per IPv6, on una regla ip6 absent deixa el bloqueig v4 com si fos efectiu. Anoteu els resultats acceptats i refusats al manual amb la data, perquè la propera migració tornarà a derivar la regla.