Bloker ét destinationsområde for hver VPN-klientpulje

Én regel kan holde en tilladt VPN-pulje væk fra et destinationsområde uden at forstyrre noget andet, som gatewayen gør. Selve reglen er kort; delene, der afgør, om den virker, er det hook, den lever i, og dens placering i kæden. Tager man fejl af disse to, får man en firewall, der ser korrekt ud og opfører sig inkonsekvent. Start med, hvad pakken laver, når reglen ser den.

Hvad reglen faktisk matcher

Reglen matcher tre ting på én gang: et input-interface, et kilde-præfiks og et destinationspræfiks. Alle tre skal være sande, før drop anvendes, og det er det, der holder den snæver. At læse den som ét udtryk er lettere end at læse den som tre separate politikker.

Interface-matchningen er det, der skelner videresendt klienttrafik fra gatewayens egne forbindelser. Uden den ville en regel, der kun nævner kilde-puljen, også ramme pakker, som gatewayen selv genererer fra den adresse, hvis den nogensinde gør det. Kilde-præfikset begrænser politikken til tilladte klienter, og destinationspræfikset begrænser den til ét område. Læs reglen som et snit og ikke som en liste.

Skriv de tre værdier ned, før du redigerer noget: tunnel-interfacets navn, den pulje serveren uddeler, og det præfiks, du vil afvise. En tastefejl i en af dem giver en regel, der parses rent og beskytter intet. Hold de tre værdier i ændringsloggen ved siden af reglen.

Hooket afgør, hvem reglen gælder for

En netfilter-kæde er knyttet til et hook, og hooket afgør, hvilke pakker kæden overhovedet ser. Forward-hooket ser trafik, der routes gennem gatewayen, og det er netop klient-til-destination-trafik. Alt andet i kæden er rettet mod et andet publikum.

Input-hooket ser trafik, der er adresseret til gatewayen selv, så en regel, der placeres der, styrer adgangen til dens egne tjenester i stedet for transit. Output-hooket ser trafik, som gatewayen selv skaber, hvilket er det modsatte af, hvad en klientpulje-politik har brug for. Kædenavne er vilkårlige etiketter valgt af den, der skrev rulesettet, så udled ikke hooket af navnet. Kontrollér, hvor kæden er knyttet, før du antager, hvad den kan matche.

At læse tilknytningen er et én-linje-tjek, der forhindrer en regel i at lande i en kæde, der aldrig ser pakken.

Placér reglen før den brede accept

Regler evalueres i rækkefølge, og den første dom vinder. En bred accept tidligere i kæden afslutter evalueringen for de pakker, den matcher, så et drop tilføjet bagefter aldrig kører for dem. Den rækkefølgeregel er hele grunden til, at en korrekt udseende regel kan have ingen effekt.

Indsæt reglen foran accepten i stedet for at tilføje den til slutningen. Hvis kæden allerede indeholder en generel accept for tunnel-interfacet, skal den nye regel stå før den, ellers er den dekorativ. Kontrollér den resulterende rækkefølge i stedet for den fil, du redigerede, fordi et ruleset samlet af flere filer måske ikke svarer til nogen enkelt af dem. Bekræft derefter med en testpakke fra puljen.

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 kommando parser filen uden at anvende den, hvilket fanger syntaksfejl, før de bliver et nedbrud. Anvend med en tilbagerulningsplan, da en fejlagtig regel i en forward-kæde kan kappe den tunnel, du arbejder over.

Eksisterende flows er ligeglade med din nye regel

En conntrack-post oprettet før reglen fandtes, fortsætter med at matche den tidligere accept. Derfor ser et nyt drop nogle gange ud til at virke for friske forbindelser og til at gøre intet for den, der testes.

Læs state-matchningen øverst i kæden. Hvis den accepterer established og related trafik før din regel, fortsætter hvert flow, der allerede er i gang, med at flyde, indtil det lukker. Det er normalt den adfærd, du vil have til en nødregel, og det er forvirrende, når du forventer et øjeblikkeligt snit. Beslut, hvilken effekt du vil have, før du udruller. En test, der genbruger en åben forbindelse, vil fortælle dig den forkerte 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 kommando viser, om et flow findes, og den anden viser, om en tidlig state-regel fortsat accepterer det. Begge er skrivebeskyttede og sikre at køre under en hændelse.

Hvad denne regel ikke er

Reglen er ikke en domæne-sortliste, en IPv6-politik eller en begrænsning på en enkelt applikationskonto.

Hver af dem kræver sin egen mekanisme. En domæneblokering skal opløse navne, hvilket et pakkefilter ikke gør. IPv6-trafik kræver sin egen matchning, fordi et ip-udtryk intet siger om ip6-pakker. En begrænsning på applikationsniveau hører til tjenesten eller en autentificeret proxy og ikke til en præfiks-matchning. At holde disse krav adskilt er det, der forhindrer, at én snæver regel bliver bedt om at løse fire opgaver.

Den kontrakt, denne regel leverer, er præcis: trafik fra en tilladt pulje til ét destinationspræfiks afvises, mens ubeslægtet gateway-trafik beholder sin eksisterende politik. Skriv den sætning ved siden af reglen, så ved den næste person, hvad den var til.