Ett kedjenamn är inte en hook: iptables mot nftables

Båda brandväggarna kan filtrera vidarebefordrad VPN-trafik, och de fäster regler vid paketvägen på olika sätt. iptables har inbyggda kedjor inuti en tabell, så FORWARD finns som en namngiven hookpunkt. nftables skiljer en kedjas namn från dess typ, hook och prioritet, vilket betyder att en vanlig kedja som heter FORWARD inte filtrerar någonting alls. Jämförelsen av de två modellerna förklarar varför en post som ser rätt ut i ett verktyg inte har någon effekt i det andra.

En kedja är en behållare. Om kärnan konsulterar den beror på implementeringen och på hur regeluppsättningen fäster den.

Två modeller, två olika fästpunkter

I iptables kommer filter-tabellen med tre inbyggda kedjor, INPUT, FORWARD och OUTPUT, och -N skapar en användardefinierad kedja som bara verkar när man hoppar till den från en av dem. nftables handbok definierar i stället baskedjor, som deklarerar typ, hook och prioritet, och vanliga kedjor, som inte gör det. En baskedja kan bära vilket namn som helst, och en vanlig kedja som heter FORWARD får inga egenskaper från sin etikett. Det är hela skillnaden, och den är osynlig i en handledning som bara visar regeltext.

Kompatibilitetsbakändar lägger till en andra anledning att inte sluta sig till beteende från ett kommandonamn. iptables dokumentation nämner operationer som skiljer sig under iptables-nft, så behandla inbyggt nftables, iptables-nft och en äldre regeluppsättning som tre system och inte som tre stavningar av ett.

Läs felet i sitt verkliga sammanhang

En saknad tabell, ett behörighetsfel, en otillgänglig kärnfunktion och en saknad namngiven kedja är fyra olika fynd, och bara ett handlar om kedjan. Anteckna verktygets version, den begärda adressfamiljen och tabellen, nätverksnamnrymden och det första exakta felet. Kontrollera sedan vilken komponent som äger regeluppsättningen: en brandväggstjänst eller en produktstyrd gateway kan generera egna kedjor och ordning. Att lägga till en inbyggd kedja bredvid dem lämnar den styrda policyn orörd och inventeringen mer förvirrande.

En containers namnrymd kan innehålla en annan regeluppsättning än värden, så ett kommando som körs i fel sammanhang kan inte visa vilken kedja som såg ett vidarebefordrat paket. Att höja behörigheter för att en förväntad kedja inte syntes är inte en diagnos.

Räknare bevisar träff, inte dom

Regelräknare berättar att en regel nåddes. De berättar inte att en senare regel tillät åtgärden, och de bevisar inte att varje alternativ väg nekades. Läs dem under ett enda ofarligt auktoriserat flöde, tillsammans med regelordning och kedjefästning, och behandla dem som en observation i stället för en dom. En räknare som inte är noll på en drop-regel betyder att trafiken träffade den; den säger ingenting om trafik som inte träffade den.

Kärnans IP-vidarebefordran är en helt separat inställning. Att en kedja finns aktiverar inte vidarebefordran, och att en välbekant etikett saknas betyder inte att vidarebefordran stoppades.

Beskriv flödet du vill skydda

Skriv ned en klientförfrågan efter dekapsulering: källan, målet, adressfamiljen och om den slutar vid gatewayen eller passerar genom den. Indata till en lokal tjänst och vidarebefordrad trafik observeras på olika punkter, så de behöver olika regler och olika tester. Verifiera även bryggvägen för ett bryggat VPN, eftersom en kedja på IP-nivå inte övervakar Ethernet-ramar automatiskt.

Bevara oberoende återställningsåtkomst innan du ändrar en fjärrgateway. Bekräfta sedan det avsedda flödet och de nödvändiga avvisningarna under samma regeluppsättning. En ny tom kedja med ett välbekant namn är inte en reparation.

Jämförelsen slutar i en fråga: vilken hook anropar kärnan egentligen för detta paket? Svara på det, och kedjenamnet slutar spela roll.