Blokker eitt målområde for kvar VPN-klientpulje

Éi regel kan halde ein tillaten VPN-pulje borte frå eit målområde utan å forstyrre noko anna gatewayen gjer. Sjølve regelen er kort; det som avgjer om han verkar, er kroken han lever i og plasseringa i kjeda. Tek du feil av desse to, får du ein brannmur som ser rett ut og oppfører seg inkonsekvent. Start med kva pakken gjer når regelen ser han.

Kva regelen faktisk matchar

Regelen matchar tre ting samstundes: eit inngangsgrensesnitt, eit kjelde-prefiks og eit målprefiks. Alle tre må vere sanne før drop blir teke i bruk, og det er det som held han smal. Å lese han som eitt uttrykk er enklare enn som tre skilde retningslinjer.

Grensesnittmatchen er det som skil videresendt klienttrafikk frå gatewayen sine eigne tilkoplingar. Utan han ville ein regel som berre nemner kjeldebassenget òg påverke pakkar gatewayen sjølv genererer frå den adressa, om han nokon gong gjer det. Kjelde-prefikset avgrensar retningslinja til tillatne klientar, og målprefikset avgrensar ho til eitt område. Les regelen som eit snitt og ikkje som ei liste.

Skriv ned dei tre verdiane før du redigerer noko: namnet på tunnelgrensesnittet, bassenget serveren deler ut, og prefikset du vil avvise. Ein skrivefeil i ein av dei gir ein regel som blir parsa reint og vernar ingenting. Hald dei tre verdiane i endringsloggen ved sida av regelen.

Kroken avgjer kven regelen gjeld for

Ei netfilter-kjede er knytt til ein krok, og kroken avgjer kva pakkar kjeda i det heile ser. Forward-kroken ser trafikk som blir ruta gjennom gatewayen, og det er nettopp klient-til-mål-trafikk. Alt anna i kjeda er retta mot eit anna publikum.

Input-kroken ser trafikk adressert til gatewayen sjølv, så ein regel plassert der styrer tilgangen til hans eigne tenester i staden for transitt. Output-kroken ser trafikk gatewayen sjølv skapar, som er det motsette av det ein klientpulje-retningslinje treng. Kjedenamn er vilkårlege etikettar valde av den som skreiv regelverket, så ikkje leid kroken ut frå namnet. Kontroller kvar kjeda er knytt før du føreset kva ho kan matche.

Å lese tilknytinga er ein einlinjes sjekk som hindrar ein regel i å hamne i ei kjede som aldri ser pakken.

Plasser regelen før den breie accept

Reglar blir vurderte i rekkjefølgje, og den første dommen vinn. Ein brei accept tidlegare i kjeda avsluttar vurderinga for pakkane han matchar, så ein drop lagt til etterpå køyrer aldri for dei. Den rekkjefølgjeregelen er heile grunnen til at ein korrekt utsjåande regel kan ha null effekt.

Set inn regelen framfor accept i staden for å leggje han til på slutten. Viss kjeda alt inneheld ein generell accept for tunnelgrensesnittet, må den nye regelen stå før han, elles er han berre dekorativ. Kontroller den resulterande rekkjefølgja og ikkje fila du redigerte, fordi eit regelverk sett saman av fleire filer kanskje ikkje svarar til noka enkelt av dei. Stadfest deretter med ein testpakke frå 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 parsar fila utan å bruke ho, noko som fangar syntaksfeil før dei blir eit avbrot. Bruk han med ein tilbakerullingsplan, sidan ein feil regel i ei forward-kjede kan kappe tunnelen du jobbar over.

Eksisterande flytar bryr seg ikkje om din nye regel

Ei conntrack-oppføring oppretta før regelen fanst, held fram med å matche den tidlegare accepten. Difor ser ein ny drop av og til ut til å verke for ferske tilkoplingar og til å gjere ingenting for den som blir testa.

Les state-matchen øvst i kjeda. Viss han godtek established og related trafikk før regelen din, held kvar flyt som alt er i gang, fram til han blir lukka. Det er vanlegvis åtferda du vil ha for ein naudregel, og det er forvirrande når du ventar eit umiddelbart kutt. Bestem kva effekt du vil ha før du rullar ut. Ein test som brukar ein open tilkopling om att, vil fortelje 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 ein flyt finst, og den andre viser om ein tidleg state-regel framleis godtek han. Begge er skriveverna og trygge å køyre under ei hending.

Kva denne regelen ikkje er

Regelen er ikkje ei domenesvarteliste, ei IPv6-retningslinje eller ei avgrensing på ein enkelt applikasjonskonto.

Kvar av dei treng sin eigen mekanisme. Ei domeneblokkering må løyse opp namn, noko eit pakkefilter ikkje gjer. IPv6-trafikk treng sin eigen match, fordi eit ip-uttrykk ikkje seier noko om ip6-pakkar. Ei avgrensing på applikasjonsnivå høyrer til tenesta eller ein autentisert proxy, ikkje til ein prefiksmatch. Å halde desse krava skilde er det som hindrar at éin smal regel blir beden om å gjere fire jobbar.

Kontrakten denne regelen leverer, er presis: trafikk frå eit tillaten basseng til eitt målprefiks blir avvist, medan ubeslekta gatewaytrafikk held på den eksisterande retningslinja si. Skriv den setninga ved sida av regelen, så veit neste person kva han var til.