nftables: infoga VPN-tillåtselseregeln före drop-handtaget

Placera en tillåtselseregel på fel ställe och den beter sig som om ingen regel fanns. I nftables avgör valet mellan insert och add vilken sida av en refererad regel den nya satsen landar på, och ett handtag namnger regeln i den levande regeluppsättningen i stället för dess radnummer. Om placeringen är fel når paketet droppen först.

Jämförelsen nedan använder en fast peer och ett yttre lyssnarutbyte. Den är medvetet smal; att ersätta en hel kedja är en annan ändring med en annan riskprofil.

Två placeringar, två olika utfall

insert placerar en regel före den refererade regeln. add placerar den efter. Om den refererade regeln är den terminala droppen för flödet ger de två kommandona motsatta resultat även när regeltexten är identisk.

Att utelämna en placering har sitt eget standardbeteende, vilket är ännu ett skäl att inte kopiera ett kommando från ett forum utan att läsa vad det är förankrat i. Förankringen är hela beslutet. Skriv ned den avsedda sidan innan du skriver kommandot. insert och add skiljer sig med ett ord i filen.

Placeringen är relativ till en regel i en viss kedja. Att flytta samma sats till en annan kedja eller en annan hook-prioritet ändrar vilka paket den ser, även när regelns syntax ser korrekt ut.

Ett handtag identifierar en regel, inte ett radnummer

Ett handtag som 42 är en identifierare i regeluppsättningens aktuella tillstånd. Det är inte den fyrtioandra regeln och det är inte stabilt mellan värdar, ombyggnader eller en hanterare som laddar om sin konfiguration.

Hitta kedjan och den faktiska terminala droppen innan du väljer förankring. Bekräfta sedan handtaget på den regeln i samma lista som visar droppen, så att numret och regeln läses tillsammans. Ett handtag läst från en gammal lista kan redan tillhöra en annan regel. Läs det igen i sessionen som ska tillämpa ändringen.

iptables --version
nft -a list ruleset

iptables-versionen anger vilken backend som används. En iptables-nft-regeluppsättning och en oberoende hanterad inbyggd tabell kan samexistera, så en lista från en enda frontend är inte automatiskt den fullständiga filtreringsbilden. Kontrollera båda vyerna innan du väljer en kedja.

Hitta kedjan och regeln som faktiskt droppar

Läs input-hooken, kedjans prioritet och regeln som avvisar detta lyssnarflöde. En inet-tabell kan bära båda adressfamiljerna, men en enskild regel kan fortfarande bara matcha IPv4.

Ta en godkänd peer och använd 198.51.100.25 från dokumentationsintervallet som exempel. En granskad inbyggd fil kan placera ett yttre tillstånd före handtag 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Byt ut familj, tabell, kedja, handtag, ingångsgränssnitt och peer efter inspektion. Exemplet använder handtagsplaceringsformen som dokumenteras för nft 1.0.9, och den hör hemma i en indatafil; citat av klammerparenteser är en separat fråga när kommandot skrivs interaktivt.

Håll konfigurationsägaren tydlig. En hanterare som bygger upp sina regler igen kan skriva över en ändring i drift, och ett startskript som hårdkodar ett föråldrat handtag kommer antingen att misslyckas eller fästa vid fel regel.

Tillstånd är avgränsat, en drop är terminal

En tillståndsdom avslutar utvärderingen på sin nuvarande väg, men en senare tillämplig baskedja kan fortfarande droppa paketet. En dropdom är terminal. Därför är en stigande tillståndsräknare inget bevis för att flödet lyckades.

Undersök alla relevanta hook-prioriteter i stället för en kedja isolerat. Ett paket kan passera ett inputfilter och ändå avvisas av en annan tabells hook vid en annan prioritet. Lista varje baskedja som kan se flödet.

Den regeln täcker bara det yttre lyssnarutbytet. Transportinkapslad ESP, inbyggd ESP, IPv6-peers och den dekrypterade trafiken inne i tunneln behöver alla egna policyer. Det är inte en fullständig webbplats-VPN-brandvägg.

Kontrollera filen och verifiera sedan det levande resultatet

Kör en syntax- och transaktionskontroll på den granskade filen innan du tillämpar den. Kontrolläget rapporterar om nft kan tolka och förbereda ändringen; det tillämpar den inte och bevisar inte att en annan hook tillåter paketet. Filen förblir ett förslag tills ägaren tillämpar den:

nft -c -f reviewed-vpn-rule.nft

Tillämpa den genom ägarens kontrollerade process och behåll återställningsåtkomst. Om regeln är fel kan droppen du försökte gå före också skära av vägen du använder för att rätta den.

Observera efter ändringen ett nytt tillåtet peer-försök och kontrollera att källor utanför den godkända peeren fortfarande avvisas. Flytta den varaktiga regeln till den hanterare som äger regeluppsättningen, eftersom handtag i drift lokaliserar aktuella objekt i stället för att identifiera dem mellan starter.