Blockera ett destinationsområde för varje VPN-klientpool

En regel kan hålla en tillåten VPN-pool borta från ett destinationsområde utan att störa något annat som gatewayen gör. Regeln i sig är kort; delarna som avgör om den fungerar är den hook den lever i och dess placering i kedjan. Tar man fel på dessa två får man en brandvägg som ser korrekt ut och beter sig inkonsekvent. Börja med vad paketet gör när regeln ser det.

Vad regeln faktiskt matchar

Regeln matchar tre saker samtidigt: ett ingångsgränssnitt, ett källprefix och ett destinationsprefix. Alla tre måste vara sanna innan drop tillämpas, och det är det som håller den smal. Att läsa den som ett uttryck är enklare än som tre separata policyer.

Gränssnittsmatchningen är det som skiljer vidarebefordrad klienttrafik från gatewayens egna anslutningar. Utan den skulle en regel som bara nämner källpoolen också påverka paket som gatewayen själv genererar från den adressen, om den någonsin gör det. Källprefixet begränsar policyn till tillåtna klienter, och destinationsprefixet begränsar den till ett område. Läs regeln som ett snitt och inte som en lista.

Skriv ner de tre värdena innan du ändrar något: namnet på tunnelgränssnittet, poolen som servern delar ut och prefixet du tänker neka. Ett skrivfel i något av dem ger en regel som tolkas rent och inte skyddar något. Håll de tre värdena i ändringsloggen bredvid regeln.

Hooken avgör vem regeln gäller

En netfilter-kedja är kopplad till en hook, och hooken avgör vilka paket kedjan överhuvudtaget ser. Forward-hooken ser trafik som routas genom gatewayen, och det är just klient-till-destination-trafik. Allt annat i kedjan riktar sig till en annan publik.

Input-hooken ser trafik som är adresserad till gatewayen själv, så en regel som placeras där styr åtkomsten till dess egna tjänster i stället för transittrafik. Output-hooken ser trafik som gatewayen själv skapar, vilket är motsatsen till vad en klientpoolpolicy behöver. Kedjenamn är godtyckliga etiketter valda av den som skrev regeluppsättningen, så härled inte hooken från namnet. Kontrollera var kedjan är kopplad innan du antar vad den kan matcha.

Att läsa kopplingen är en enradskontroll som hindrar en regel från att hamna i en kedja som aldrig ser paketet.

Placera regeln före den breda accepten

Regler utvärderas i ordning och den första domen vinner. En bred accept tidigare i kedjan avslutar utvärderingen för de paket den matchar, så en drop som läggs till efteråt körs aldrig för dem. Den ordningsregeln är hela anledningen till att en korrekt utseende regel kan sakna effekt.

Sätt in regeln före accepten i stället för att lägga den sist. Om kedjan redan innehåller en allmän accept för tunnelgränssnittet måste den nya regeln stå före den, annars är den bara dekorativ. Kontrollera den resulterande ordningen och inte filen du redigerade, eftersom en regeluppsättning som satts samman av flera filer kanske inte motsvarar någon av dem. Bekräfta sedan med ett testpaket från poolen.

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

Det tredje kommandot tolkar filen utan att tillämpa den, vilket fångar syntaxfel innan de blir ett avbrott. Tillämpa med en återställningsplan, eftersom en felaktig regel i en forward-kedja kan kapa tunneln du arbetar över.

Befintliga flöden bryr sig inte om din nya regel

En conntrack-post som skapades innan regeln fanns fortsätter att matcha den tidigare accepten. Därför kan en ny drop ibland se ut att fungera för nya anslutningar och inte göra något för den som testas.

Läs state-matchningen högst upp i kedjan. Om den accepterar established och related trafik före din regel fortsätter varje flöde som redan pågår att flöda tills det stängs. Det är oftast det beteende du vill ha för en nödregel, och det är förvirrande när du förväntar dig ett omedelbart avbrott. Bestäm vilken effekt du vill ha innan du rullar ut. Ett test som återanvänder en öppen anslutning berättar fel historia för dig.

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

Det första kommandot visar om ett flöde finns, och det andra visar om en tidig state-regel fortfarande accepterar det. Båda är skrivskyddade och säkra att köra under en incident.

Vad den här regeln inte är

Regeln är inte en domänsvartlista, en IPv6-policy eller en begränsning för ett enskilt applikationskonto.

Var och en av dem kräver sin egen mekanism. En domänblockering måste lösa namn, vilket ett paketfilter inte gör. IPv6-trafik behöver sin egen matchning, eftersom ett ip-uttryck inte säger något om ip6-paket. En begränsning på applikationsnivå hör till tjänsten eller en autentiserad proxy, inte till en prefixmatchning. Att hålla dessa krav åtskilda är det som hindrar en smal regel från att bli ombedd att göra fyra jobb.

Kontraktet som den här regeln levererar är exakt: trafik från en tillåten pool till ett destinationsprefix nekas, medan orelaterad gatewaytrafik behåller sin befintliga policy. Skriv den meningen bredvid regeln, så vet nästa person vad den var till för.