Blokker ett destinasjonsområde for hver VPN-klientpulje

Én regel kan holde en tillatt VPN-pulje borte fra et destinasjonsområde uten å forstyrre noe annet gatewayen gjør. Selve regelen er kort; det som avgjør om den virker, er hooken den lever i og plasseringen i kjeden. Tar du feil av disse to, får du en brannmur som ser riktig ut og oppfører seg inkonsekvent. Start med hva pakken gjør når regelen ser den.

Hva regelen faktisk matcher

Regelen matcher tre ting samtidig: et inngangsgrensesnitt, et kilde-prefiks og et destinasjonsprefiks. Alle tre må være sanne før drop tas i bruk, og det er det som holder den smal. Å lese den som ett uttrykk er enklere enn som tre separate retningslinjer.

Grensesnittmatchen er det som skiller videresendt klienttrafikk fra gatewayens egne tilkoblinger. Uten den ville en regel som bare nevner kildebassenget også påvirke pakker gatewayen selv genererer fra den adressen, hvis den noen gang gjør det. Kilde-prefikset begrenser retningslinjen til tillatte klienter, og destinasjonsprefikset begrenser den til ett område. Les regelen som et snitt og ikke som en liste.

Skriv ned de tre verdiene før du redigerer noe: navnet på tunnelgrensesnittet, bassenget serveren deler ut, og prefikset du vil avvise. En skrivefeil i en av dem gir en regel som parses rent og beskytter ingenting. Ha de tre verdiene i endringsloggen ved siden av regelen.

Hooken avgjør hvem regelen gjelder for

En netfilter-kjede er knyttet til en hook, og hooken avgjør hvilke pakker kjeden i det hele tatt ser. Forward-hooken ser trafikk som rutes gjennom gatewayen, og det er nettopp klient-til-destinasjon-trafikk. Alt annet i kjeden er rettet mot et annet publikum.

Input-hooken ser trafikk adressert til gatewayen selv, så en regel plassert der styrer tilgangen til dens egne tjenester i stedet for transitt. Output-hooken ser trafikk gatewayen selv skaper, som er det motsatte av det en klientpulje-retningslinje trenger. Kjedenavn er vilkårlige etiketter valgt av den som skrev regelverket, så ikke utled hooken fra navnet. Kontroller hvor kjeden er knyttet før du antar hva den kan matche.

Å lese tilknytningen er en enlinjes sjekk som hindrer en regel i å havne i en kjede som aldri ser pakken.

Plasser regelen før den brede accept

Regler vurderes i rekkefølge, og den første dommen vinner. En bred accept tidligere i kjeden avslutter vurderingen for pakkene den matcher, så en drop lagt til etterpå aldri kjører for dem. Den rekkefølgeregelen er hele grunnen til at en korrekt utseende regel kan ha null effekt.

Sett inn regelen foran accept i stedet for å legge den til på slutten. Hvis kjeden allerede inneholder en generell accept for tunnelgrensesnittet, må den nye regelen stå før den, ellers er den dekorativ. Kontroller den resulterende rekkefølgen og ikke filen du redigerte, fordi et regelverk satt sammen av flere filer kanskje ikke samsvarer med noen enkelt av dem. Bekreft deretter med en testpakke fra bassenget.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Den tredje kommandoen parser filen uten å bruke den, noe som fanger syntaksfeil før de blir et avbrudd. Bruk den med en tilbakerullingsplan, siden en feil regel i en forward-kjede kan kappe tunnelen du jobber over.

Eksisterende flyter bryr seg ikke om din nye regel

En conntrack-oppføring opprettet før regelen fantes, fortsetter å matche den tidligere accepten. Derfor ser en ny drop noen ganger ut til å virke for ferske tilkoblinger og til å gjøre ingenting for den som testes.

Les state-matchen øverst i kjeden. Hvis den aksepterer established og related trafikk før regelen din, fortsetter hver flyt som allerede er i gang, til den lukkes. Det er vanligvis oppførselen du vil ha for en nødregel, og det er forvirrende når du forventer et umiddelbart kutt. Bestem hvilken effekt du vil ha før du ruller ut. En test som gjenbruker en åpen tilkobling, vil fortelle deg feil historie.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Den første kommandoen viser om en flyt finnes, og den andre viser om en tidlig state-regel fortsatt aksepterer den. Begge er skrivebeskyttet og trygge å kjøre under en hendelse.

Hva denne regelen ikke er

Regelen er ikke en domenesvarteliste, en IPv6-retningslinje eller en begrensning på en enkelt applikasjonskonto.

Hver av dem trenger sin egen mekanisme. En domeneblokkering må løse opp navn, noe et pakkefilter ikke gjør. IPv6-trafikk trenger sin egen match, fordi et ip-uttrykk ikke sier noe om ip6-pakker. En begrensning på applikasjonsnivå hører til tjenesten eller en autentisert proxy, ikke til en prefiksmatch. Å holde disse kravene atskilt er det som hindrer at én smal regel blir bedt om å gjøre fire jobber.

Kontrakten denne regelen leverer, er presis: trafikk fra et tillatt basseng til ett destinasjonsprefiks avvises, mens ubeslektet gatewaytrafikk beholder sin eksisterende retningslinje. Skriv den setningen ved siden av regelen, så vet neste person hva den var til.