Stopp VPN-klienter fra å nå hverandre på tunnelen

To klienter kan begge åpne hoppverten og likevel ikke ha noe å gjøre med å åpne hverandre. Å nå en tjeneste er en videresendingsbeslutning, mens å nå en peer er en policybeslutning, og de fleste VPN-stakker holder dem i separate objekter. Ingenting du konfigurerer for det første håndhever det andre. Oppgaven er derfor ikke å legge til en regel, men å finne objektet som avgjør peer-trafikken på denne serveren, skrive avvisningen der og bevise den fra en klient.

En rute til den delte tjenesten er ikke en tillatelse mellom peers

Å annonsere klientundernettet forteller en peer hvordan den skal sette en pakke på ledningen mot en annen klients adresse. Om pakken blir levert avgjøres etterpå, av det som videresender den. På en Linux-gateway er det FORWARD-kjeden; inne i en daemon i brukerrommet er det tunnelens egen sesjonstabell. En rute svarer på tilgjengelighet og lar tillatelsen være urørt.

Derfor beviser en isolasjonskontroll som bare leser ruter ingenting. Et /24 kan skyves til hver klient mens hver peer-til-peer-pakke droppes ved forward-kroken. Det farlige tilfellet er det motsatte: ingen uttrykkelig regel, en ettergivende standard, og isolasjon som bare finnes fordi ingen har testet den.

Skriv kravet på én linje før du åpner en terminal. Nå tjenesteblokken og hoppverten, nå ingenting annet inne i klientblokken.

Finn ut hvem som faktisk videresender peer-pakken

To serveratferder ser like ut fra klientsiden og krever forskjellige regler. Enten videresender kjernen pakken ut av tunnelegrensesnittet igjen, eller daemonen kopierer den mellom sesjoner og kjernen ser den aldri.

WireGuard hører til den første gruppen: det har ingen peer-til-peer-bryter, så en pakke fra 10.8.0.4 til 10.8.0.5 ankommer på wg0, treffer forward-kroken og rutes ut av wg0 igjen når AllowedIPs dekker begge adressene. OpenVPN er den andre gruppen når client-to-client er satt i serverkonfigurasjonen, fordi den direktivet overleverer pakken mellom sesjoner i brukerrommet. Sjekk den innleste konfigurasjonen for den direktivet før du skriver noe. En kjerneregel som aldri ser trafikk kan ikke skilles fra en regel som virker, og slik ender en utrulling helt uten isolasjon.

Les den effektive konfigurasjonen i stedet for filen du antar er lastet, fordi distribusjonspakker leverer sine egne inkluderinger. Hvis daemonen videresender, hører avvisningen til i dens egne per-klient-kontroller, og en vertsbrannmur filtrerer bare trafikk adressert til verten. Hvis kjernen videresender, er forward-kroken det eneste stedet som betyr noe.

Rutede og oversatte utrullinger trenger en sjekk til: kilden en fjern klient ser er kanskje ikke den du forventer. Da matcher en regel som matcher klientundernettet ingenting. Noter adressen som overlever oversettelsen før du skriver match, og foretrekk å matche grensesnittparet framfor å gjette på NAT-adresser.

Gi hver adresse en identitet du kan tilbakekalle alene

Isolasjonen bryter sammen så snart to enheter deler én legitimasjon. En regel knyttet til den identiteten kan ikke skille dem, og tilbakekalling av en mistet bærbar PC tilbakekaller hele gruppen. Sertifikater per enhet eller nøkler per peer holder tilbakekallingen lokal og policyen lesbar, fordi hver adresse svarer til nøyaktig én person eller maskin. Der designet ikke kan gjøre det, si det i runbooken i stedet for å beskrive regelen som finkornet.

Adressetildeling må stemme med policyen. Reserver en blokk til tjenester, en blokk til klienter, og del ut klientadresser fra en pool du kontrollerer i stedet for et område etter førstemann-til-mølla. Hvis serveren oversetter eller broer, hold mappingstabellen ved siden av konfigurasjonen, fordi den tabellen er det neste leser trenger for å utlede regelen på nytt.

Plasser avvisningen der pakken krysser tunnelen

På en gateway som videresender WireGuard-trafikk, dekker to regler tilfellet: tillat tjenesteblokken, og dropp deretter resten av klientblokken. Grensesnittparet betyr like mye som adressene, fordi match bare på mål også fanger trafikk som kommer fra LAN. Last dem i den rekkefølgen slik at tillatelsen vurderes først.

Med nftables går paret inn i en eksisterende inet filter-tabell, tillatelse først og dropp deretter. Begge matchene fester grensesnittparet så vel som adressene.

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

Les kjeden tilbake etter lasting i stedet for å stole på utgangsstatusen, og bekreft at begge reglene står i den rekkefølgen du mente. Legg til matchende ip6-regler for IPv6-poolen, ellers er v4-paret bare dekorasjon på en dual-stack-tunnel. Hvis serveren allerede har en ettergivende forward-policy, legg til droppet i stedet for å erstatte kjeden helt.

Når client-to-client er aktivert på OpenVPN, matcher disse forward-reglene aldri peer-trafikk, og avvisningen må ligge i daemonens egne kontroller. Behold kjernereglene for trafikk adressert til verten, men ikke regn dem som isolasjonskontrollen.

Bevis avvisningen fra en klient, ikke fra serveren

Testing fra gatewayen beviser ingenting, fordi lokalt generert trafikk tar utgangsstien og aldri krysser forward-kroken. Bruk to ekte klienter: én som skal nå tjenesten, én som skal avvises. Kjør tillatelsestilfellet først, slik at en brutt tunnel ikke forveksles med en policy som virker.

Fra den tillatte klienten, bekreft at tjenesten svarer på porten sin. Fra samme klient, prøv peer-adressen og forvent et stille dropp i stedet for en avvisning:

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 ut som en tidsavbrudd, så sjekk tellerne før du konkluderer noe. Bekreft at telleren for droppregelen øker mens peeren er beviselig oppe. Gjenta over IPv6, der en manglende ip6-regel får v4-avvisningen til å se effektiv ut. Noter de aksepterte og avviste resultatene i runbooken med dato, fordi neste migrering vil utlede regelen på nytt.