Et kjedenavn er ikke en krok: iptables mot nftables

Begge brannmurene kan filtrere videresendt VPN-trafikk, og de fester regler til pakkestien på ulike måter. iptables har innebygde kjeder inne i en tabell, så FORWARD finnes som et navngitt krokpunkt. nftables skiller navnet på en kjede fra typen, kroken og prioriteten, noe som betyr at en vanlig kjede kalt FORWARD ikke filtrerer noe i det hele tatt. Sammenligningen av de to modellene forklarer hvorfor en oppføring som ser riktig ut i ett verktøy ikke har noen virkning i det andre.

En kjede er en beholder. Om kjernen undersøker den, avhenger av implementasjonen og av hvordan regelverket fester den.

To modeller, to ulike festemåter

I iptables kommer filter-tabellen med tre innebygde kjeder, INPUT, FORWARD og OUTPUT, og -N lager en brukerdefinert kjede som bare virker når det hoppes til den fra en av dem. nftables-håndboken definerer i stedet basiskjeder, som erklærer type, krok og prioritet, og vanlige kjeder, som ikke gjør det. En basiskjede kan ha hvilket som helst navn, og en vanlig kjede kalt FORWARD får ingen egenskaper fra etiketten sin. Det er hele forskjellen, og den er usynlig i en veiledning som bare viser regeltekst.

Kompatibilitetsbakender legger til en annen grunn til ikke å utlede atferd fra et kommandonavn. iptables-dokumentasjonen nevner operasjoner som er ulike under iptables-nft, så behandle innfødte nftables, iptables-nft og et eldre regelverk som tre systemer og ikke som tre stavemåter av ett.

Les feilen i sin virkelige sammenheng

En manglende tabell, en tillatelsesfeil, en utilgjengelig kjernefunksjon og en manglende navngitt kjede er fire ulike funn, og bare ett handler om kjeden. Noter verktøyversjonen, adressefamilien og tabellen som ble bedt om, nettverksnavnerommet og den første nøyaktige feilen. Sjekk deretter hvilken komponent som eier regelverket: en brannmurteneste eller en produktstyrt gateway kan generere sine egne kjeder og rekkefølge. Å legge til en innfødt kjede ved siden av dem lar den styrte policyen være urørt og oversikten mer forvirrende.

Navnerommet til en container kan holde et annet regelverk enn verten, så en kommando som kjøres i feil kontekst, kan ikke vise hvilken kjede som så en videresendt pakke. Å heve privilegier fordi en forventet kjede ikke var synlig, er ikke en diagnose.

Tellere beviser treff, ikke dom

Regeltellere forteller deg at en regel ble nådd. De forteller deg ikke at en senere regel tillot operasjonen, og de beviser ikke at hver alternativ sti ble avvist. Les dem under én ufarlig autorisert flyt, sammen med regelrekkefølge og kjedeinnfesting, og behandle dem som én observasjon og ikke en dom. En teller ulik null på en drop-regel betyr at trafikken traff den; den sier ingenting om trafikk som ikke traff.

Kjernens IP-videresending er en helt egen innstilling. At en kjede finnes, aktiverer ikke videresending, og at en kjent etikett mangler, betyr ikke at videresendingen stoppet.

Beskriv flyten du vil beskytte

Skriv ned én klientforespørsel etter dekapsulering: kilden, målet, adressefamilien og om den avsluttes ved gatewayen eller passerer gjennom den. Inndata til lokal tjeneste og videresendt trafikk observeres på ulike punkter, så de trenger ulike regler og ulike tester. For en brokoblet VPN, verifiser også brostien, fordi en kjede på IP-nivå ikke overvåker Ethernet-rammer automatisk.

Bevar uavhengig gjenopprettingstilgang før du endrer en ekstern gateway. Bekreft deretter den tiltenkte flyten og de nødvendige avvisningene under samme regelverk. En ny tom kjede med et kjent navn er ikke en reparasjon.

Sammenligningen ender i ett spørsmål: hvilken krok kaller kjernen faktisk for denne pakken? Svar på det, og kjedenavnet slutter å bety noe.