Et kædenavn er ikke et hook: iptables kontra nftables

Begge firewalls kan filtrere videresendt VPN-trafik, og de knytter regler til pakkens vej på forskellige måder. iptables har indbyggede kæder inde i en tabel, så FORWARD findes som et navngivet hook-punkt. nftables adskiller en kædes navn fra dens type, hook og prioritet, hvilket betyder, at en almindelig kæde kaldet FORWARD slet ikke filtrerer noget. Sammenligningen af de to modeller forklarer, hvorfor en post, der ser rigtig ud i ét værktøj, ingen effekt har i det andet.

En kæde er en beholder. Om kernen ser på den, afhænger af implementeringen og af, hvordan regelsættet knytter den.

To modeller, to forskellige tilknytninger

I iptables leverer filter-tabellen tre indbyggede kæder, INPUT, FORWARD og OUTPUT, og -N laver en brugerdefineret kæde, der først virker, når der springes til den fra en af dem. nftables-manualen definerer i stedet basiskæder, som erklærer deres type, hook og prioritet, og almindelige kæder, som ikke gør. En basiskæde kan bære præcis det navn, du vil, og en almindelig kæde med navnet FORWARD får ingen egenskaber fra sin etiket. Det er hele forskellen, og den er usynlig i en vejledning, der kun viser regeltekst.

Kompatibilitetsbagender tilføjer en anden grund til ikke at udlede adfærd af et kommandonavn. iptables-dokumentationen nævner handlinger, der er forskellige under iptables-nft, så behandl indbygget nftables, iptables-nft og et gammelt regelsæt som tre systemer i stedet for tre stavemåder af ét.

Læs fejlen i dens virkelige sammenhæng

En manglende tabel, en tilladelsesfejl, en utilgængelig kernfunktion og en manglende navngivet kæde er fire forskellige fund, og kun ét handler om kæden. Noter værktøjets version, den ønskede adressefamilie og tabel, netværksnavnerummet og den første præcise fejl. Kontroller derefter, hvilken komponent der ejer regelsættet: en firewalltjeneste eller en produktstyret gateway kan generere sine egne kæder og sin egen rækkefølge. At tilføje en indbygget kæde ved siden af dem lader den styrede politik være urørt og gør oversigten mere forvirrende.

En containers navnerum kan indeholde et andet regelsæt end værten, så en kommando kørt i den forkerte sammenhæng kan ikke vise, hvilken kæde der så en videresendt pakke. At hæve rettigheder, fordi en forventet kæde ikke var synlig, er ikke en diagnose.

Tællere beviser rækkevidde, ikke dom

Regeltællere fortæller dig, at en regel blev nået. De fortæller dig ikke, at en senere regel tillod handlingen, og de beviser ikke, at alle alternative veje blev afvist. Læs dem under én uskadelig godkendt strøm sammen med reglerækkefølgen og kædens tilknytning, og behandle dem som én observation frem for en dom. En tæller forskellig fra nul på en drop-regel betyder, at trafik ramte den; den siger intet om trafik, der ikke gjorde.

IP-videresendelse i kernen er en helt separat indstilling. At en kæde findes, aktiverer ikke videresendelse, og at en kendt etiket mangler, betyder ikke, at videresendelsen stoppede.

Beskriv den strøm, du forventer at beskytte

Skriv én klientanmodning ned efter dekapsulering: dens kilde, dens mål, adressefamilien og om den slutter ved gatewayen eller passerer igennem den. Lokal tjenesteinput og videresendt trafik ses på forskellige punkter, så de kræver forskellige regler og forskellige tests. For en VPN over bro, verificer også broens vej, fordi en kæde på IP-niveau ikke automatisk kontrollerer Ethernet-rammer.

Bevar uafhængig adgang til gendannelse, før du ændrer en fjern gateway. Bekræft derefter den tilsigtede strøm og de krævede afvisninger under det samme regelsæt. En ny tom kæde med et kendt navn er ikke en reparation.

Sammenligningen ender i ét spørgsmål: hvilket hook kalder kernen faktisk for denne pakke? Svar på det, og kædenavnet holder op med at betyde noget.