Beide firewalls kunnen doorgestuurd VPN-verkeer filteren, en ze koppelen regels op verschillende manieren aan het pakketpad. iptables heeft ingebouwde kettingen binnen een tabel, dus FORWARD bestaat als een benoemd hookpunt. nftables scheidt de naam van een ketting van het type, de hook en de prioriteit, wat betekent dat een gewone ketting met de naam FORWARD helemaal niets filtert. De vergelijking van beide modellen verklaart waarom een regel die in het ene hulpprogramma juist lijkt, in het andere geen effect heeft.

Een ketting is een houder. Of de kernel hem raadpleegt, hangt af van de implementatie en van de manier waarop de regelset hem koppelt.

Twee modellen, twee verschillende koppelingen

In iptables komt de filtertabel met drie ingebouwde kettingen, INPUT, FORWARD en OUTPUT, en -N maakt een door de gebruiker gedefinieerde ketting die alleen werkt als er vanuit een van die drie naar wordt gesprongen. De nftables-handleiding definieert in plaats daarvan basale kettingen, die hun type, hook en prioriteit aangeven, en gewone kettingen, die dat niet doen. Een basale ketting mag elke naam dragen, en een gewone ketting met de naam FORWARD krijgt geen eigenschappen van het label. Dat is het hele verschil, en het is onzichtbaar in een handleiding die alleen regeltekst toont.

Compatibiliteitsbackends voegen een tweede reden toe om gedrag niet uit een commandonaam af te leiden. De iptables-documentatie vermeldt bewerkingen die onder iptables-nft anders zijn, dus behandel native nftables, iptables-nft en een oude regelset als drie systemen en niet als drie spellingen van één.

Lees de fout in zijn werkelijke context

Een ontbrekende tabel, een machtigingsfout, een niet-beschikbare kernfaciliteit en een ontbrekende benoemde ketting zijn vier verschillende bevindingen, en slechts één gaat over de ketting. Noteer de versie van het hulpprogramma, de gevraagde adresfamilie en tabel, de netwerknaamruimte en de eerste exacte fout. Controleer daarna welke component de regelset bezit: een firewalldienst of een door een product beheerde gateway kan eigen kettingen en ordening genereren. Een native ketting ernaast toevoegen laat het beheerde beleid ongemoeid en maakt de inventaris verwarrender.

De naamruimte van een container kan een andere regelset bevatten dan de host, dus een opdracht in de verkeerde context kan niet laten zien welke ketting een doorgestuurd pakket zag. Rechten verhogen omdat een verwachte ketting niet zichtbaar was, is geen diagnose.

Tellers bewijzen bereik, niet uitspraak

Regeltellers vertellen je dat een regel is bereikt. Ze vertellen je niet dat een latere regel de bewerking toestond, en ze bewijzen niet dat elk alternatief pad werd geweigerd. Lees ze tijdens één onschadelijke geautoriseerde stroom, samen met de regelvolgorde en de koppeling van de ketting, en behandel ze als één waarneming in plaats van een uitspraak. Een teller die niet nul is op een drop-regel betekent dat verkeer die regel raakte; over verkeer dat hem niet raakte, zegt hij niets.

IP-doorsturen in de kernel is een volledig aparte instelling. Het bestaan van een ketting schakelt doorsturen niet in, en het ontbreken van een bekend label betekent niet dat het doorsturen stopte.

Beschrijf de stroom die u wilt beschermen

Schrijf één clientverzoek na decapsulatie op: de bron, de bestemming, de adresfamilie en of het bij de gateway eindigt of erdoorheen gaat. Invoer voor een lokale dienst en doorgestuurd verkeer worden op verschillende punten waargenomen, dus ze vragen om andere regels en andere tests. Controleer bij een overbrugde VPN ook het bridgepad, omdat een ketting op IP-niveau Ethernet-frames niet automatisch controleert.

Behoud onafhankelijke hersteltoegang voordat u een externe gateway wijzigt. Bevestig daarna de bedoelde stroom en de vereiste weigeringen onder dezelfde regelset. Een nieuwe lege ketting met een bekende naam is geen reparatie.

De vergelijking eindigt in één vraag: welke hook roept de kernel werkelijk aan voor dit pakket? Beantwoord die, en de kettingnaam doet er niet meer toe.

Gerelateerde artikelen