Stop VPN-klienter i at nå hinanden på tunnelen

To klienter kan begge åbne jump-værten og stadig ikke have noget at gøre med at åbne hinanden. At nå en tjeneste er en videresendelsesbeslutning, mens at nå en peer er en politikbeslutning, og de fleste VPN-stakke holder dem i separate objekter. Intet, du konfigurerer til det første, håndhæver det andet. Opgaven er derfor ikke at tilføje en regel, men at finde det objekt, der afgør peer-trafik på denne server, skrive afvisningen der og bevise den fra en klient.

En rute til den delte tjeneste er ikke en tilladelse mellem peers

At annoncere klient-undernettet fortæller en peer, hvordan den skal sætte en pakke på ledningen mod en anden klients adresse. Om pakken bliver leveret, afgøres bagefter af det, der videresender den. På en Linux-gateway er det FORWARD-kæden; inde i en daemon i brugerrummet er det tunnelens egen sessionstabel. En rute svarer på tilgængelighed og lader tilladelsen være urørt.

Derfor beviser en isolationskontrol, der kun læser ruter, intet. Et /24 kan skubbes til hver klient, mens hver peer-til-peer-pakke droppes ved forward-krogen. Det farlige tilfælde er det omvendte: ingen udtrykkelig regel, en eftergivende standard, og isolation, der kun findes, fordi ingen har testet den.

Skriv kravet på én linje, før du åbner en terminal. Nå tjenesteblokken og jump-værten, nå intet andet inde i klientblokken.

Find ud af, hvem der faktisk videresender peer-pakken

To serveradfærdsmønstre ser ens ud fra klientsiden og kræver forskellige regler. Enten videresender kernen pakken ud af tunnelegrænsefladen igen, eller daemonen kopierer den mellem sessioner, og kernen ser den aldrig.

WireGuard hører til den første gruppe: det har ingen peer-til-peer-kontakt, så en pakke fra 10.8.0.4 til 10.8.0.5 ankommer på wg0, rammer forward-krogen og routes ud af wg0 igen, når AllowedIPs dækker begge adresser. OpenVPN er den anden gruppe, når client-to-client er sat i serverkonfigurationen, fordi den direktiv giver pakken videre mellem sessioner i brugerrummet. Tjek den indlæste konfiguration for den direktiv, før du skriver noget. En kerneregel, der aldrig ser trafik, kan ikke skelnes fra en regel, der virker, og det er sådan en udrulning ender helt uden isolation.

Læs den effektive konfiguration i stedet for den fil, du antager er indlæst, fordi distributionernes pakker leverer deres egne inkluderinger. Hvis daemonen videresender, hører afvisningen til i dens egne per-klient-kontroller, og værtens firewall filtrerer kun trafik adresseret til værten. Hvis kernen videresender, er forward-krogen det eneste sted, der betyder noget.

Rutede og oversatte udrulninger kræver endnu et tjek: den kilde, en fjern klient ser, er måske ikke den, du forventer. Så matcher en regel, der matcher klientundernettet, ingenting. Notér den adresse, der overlever oversættelsen, før du skriver match, og foretræk at matche grænsefladeparret frem for at gætte på NAT-adresser.

Giv hver adresse en identitet, du kan tilbagekalde alene

Isolation bryder sammen, så snart to enheder deler én legitimationsoplysning. En regel, der er knyttet til den identitet, kan ikke skille dem, og tilbagekaldelse af en mistet laptop tilbagekalder hele gruppen. Certifikater per enhed eller nøgler per peer holder tilbagekaldelsen lokal og politikken læsbar, fordi hver adresse svarer til præcis én person eller maskine. Hvor designet ikke kan gøre det, så sig det i runbooken i stedet for at beskrive reglen som finkornet.

Adressetildeling skal stemme med politikken. Reserver en blok til tjenester, en blok til klienter, og uddel klientadresser fra en pulje, du kontrollerer, i stedet for et område efter først-til-mølle. Hvis serveren oversætter eller broer, så hold mappingstabellen ved siden af konfigurationen, fordi den tabel er, hvad den næste læser har brug for til at udlede reglen igen.

Anbring afvisningen, hvor pakken krydser tunnelen

På en gateway, der videresender WireGuard-trafik, dækker to regler tilfældet: tillad tjenesteblokken, og drop derefter resten af klientblokken. Grænsefladeparret betyder lige så meget som adresserne, fordi match på kun destination også fanger trafik, der kommer fra LAN'et. Indlæs dem i den rækkefølge, så tilladelsen vurderes først.

Med nftables går parret ind i en eksisterende inet filter-tabel, tilladelse først og drop derefter. Begge match fastgør grænsefladeparret såvel som adresserne.

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

Læs kæden tilbage efter indlæsning i stedet for at stole på exitstatus, og bekræft, at begge regler står i den orden, du havde tænkt. Tilføj matchende ip6-regler til IPv6-puljen, ellers er v4-parret kun dekoration på en dual-stack-tunnel. Hvis serveren allerede har en eftergivende forward-politik, så tilføj droppet i stedet for at erstatte kæden helt.

Når client-to-client er aktiveret på OpenVPN, matcher disse forward-regler aldrig peer-trafik, og afvisningen skal ligge i daemonens egne kontroller. Behold kernereglerne for trafik adresseret til værten, men regn dem ikke som isolationskontrollen.

Bevis afvisningen fra en klient, ikke fra serveren

Test fra gatewayen beviser intet, fordi lokalt genereret trafik tager output-stien og aldrig krydser forward-krogen. Brug to rigtige klienter: en, der skal nå tjenesten, en, der skal afvises. Kør tilladelsestilfældet først, så en brudt tunnel ikke forveksles med en politik, der virker.

Fra den tilladte klient, bekræft at tjenesten svarer på sin port. Fra samme klient, prøv peer-adressen og forvent et stille drop i stedet for en afvisning:

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

En droppet pakke og en offline peer ser begge ud som en timeout, så tjek tællerne, før du konkluderer noget. Bekræft, at drop-reglens tæller stiger, mens peeren beviseligt er oppe. Gentag over IPv6, hvor en manglende ip6-regel får v4-afvisningen til at se effektiv ud. Notér de accepterede og afviste resultater i runbooken med datoen, fordi den næste migrering vil udlede reglen igen.