Ändring av brandväggsregel fungerar inte: regelordning och anslutningsstatus

Du redigerade regeln, laddade om regeluppsättningen och tunneln beter sig precis som förut. Det resultatet har två vanliga orsaker, och de kräver olika tester. Antingen ligger den nya regeln efter en tidigare regel som redan har accepterat paketet, eller så är utbytet du tittar på en spårad anslutning som ändringen aldrig omvärderar. En regel i en fil uttrycker avsikt; det som avgör paketet är den aktiva väg det möter. Gå igenom kontrollerna nedan i ordning och håll en väg tillbaka öppen medan du gör det.

Regelordning och anslutningsstatus är olika fel

Ordnade kedjor utvärderas uppifrån och ned, och den första regeln som når ett slutgiltigt avgörande avslutar genomgången av den kedjan. Sätt ett brett godkännande ovanför en noggrant skriven låsningsregel, och låsningsregeln blir dokumentation: den finns i regeluppsättningen, räknaren är noll och ingen paket kommer någonsin att nå den. Samma text tillämpad på en annan kedja bevisar inte heller något. I nftables fästs baskedjor vid krokar enligt prioriteter, så ett godkännande i en kedja hindrar inte en annan kedja på en annan krok eller prioritet från att se samma paket.

Anslutningsspårningen ger det andra symptomet, och utifrån ser det identiskt ut. När ett flöde väl finns i tillståndstabellen återvänder ett godkännande för etablerad-eller-relaterad nära kedjans topp innan din nya regel ens konsulteras. NAT-mappningar har samma egenskap: översättningen fastställdes när flödet började, så en redigerad postrouting-regel skriver inte om en session som redan kör. Det är därför en ändring verkar fungera kl. 09:00 för en ny anslutning och verkar göra ingenting för sessionen som någon öppnade kl. 08:55.

Molnsäkerhetsgrupper lägger till en tredje modell som fångar folk som lärt sig på iptables. Deras inkommande regler är en tillåtelselista som utvärderas som en mängd i stället för en genomgång efter första träff, de är stateful, och att ta bort en tillåtelseregel avslutar inte flöden som redan spåras. Att anta första-träff-semantik på en plattform som inte har den leder till självsäkra, felaktiga slutsatser.

Läs den aktiva regeluppsättningen, inte filen du redigerade

Börja med vad kärnan faktiskt tillämpar just nu. En sparad konfiguration som aldrig användes förklarar förvånansvärt många oförändrade beteenden, och det kostar ett enda kommando att utesluta den:

nft list ruleset
iptables-save

Fråga sedan om din regel ens nås. Paketräknare svarar direkt på det, och de svarar bättre än något resonemang om avsikt:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

En låsningsregel med noll paket efter ett verkligt testförsök är inte ett policyproblem, det är ett positionsproblem. Att flytta den är en ändring på en rad, och syntaxen är precis det som orsakade det ursprungliga felet. Med iptables -I infogar, och -A lägger till i slutet; med nftables insert placerar en regel i början av kedjan medan add lägger till i slutet. När en regel måste vinna, säg det uttryckligen i stället för att lita på den ordning som råkade laddas.

Bevisa om flödet spåras

Innan du skyller på regeln, kontrollera om trafiken ens är en spårad anslutning. Fråga tillståndstabellen om det specifika flödet i stället för att dumpa hela:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Listan visar tillståndet och den återstående tidsgränsen, och så skiljer du en etablerad session från ett färskt försök; händelseläget skriver ut uppdateringar när de inträffar, vilket är användbart medan du återansluter en klient. Om flödet redan finns med etablerat tillstånd innan du rörde något, kommer ingen ändring av filterreglerna att ändra dess öde. Det är ingen bugg i brandväggen, det är kontraktet för stateful filtrering.

Motstå genvägen att tömma hela tabellen på en produktionsgateway. conntrack -F är tillgängligt, och det förstör också varje spårat flöde på maskinen, inklusive den administrationssession du arbetar från och den tunnel som bär ditt skal. Enskilda poster kan raderas när du verkligen behöver det, men ett färskt flöde från en ny källport är oftast ett renare experiment.

Vissa vägar spåras inte, och de beter sig tvärtom. Trafik märkt notrack i raw-tabellen, vissa tunnlar som kringgår de vanliga krokarna och asymmetrisk routning som delar ett flöde mellan två gateways ger alla paket som utvärderas ett i taget, eller tillstånd som aldrig skapas i båda ändarna. Om räknarna rör sig för varje paket, misstänk den sortens väg innan du misstänker ordningen.

Testa från ett färskt flöde med en väg tillbaka

Innan du testar en regel som kan skära av fjärråtkomst, upprätta en återställningsväg: leverantörens konsol, en seriell konsol, en administrationsadress utanför bandet eller ett andra gränssnitt som regeln inte kan träffa. En återställningstimer är en rimlig följeslagare, eftersom den återställer den föregående regeluppsättningen även om din session dör mitt i testet.

Testa sedan med ett utbyte som tillståndet inte redan kunde ha täckt. Koppla från och återanslut klienten så att en ny femling skapas, och observera båda ändarna medan det sker:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Kör testet i båda riktningarna. En regel som blockerar det nya inkommande handskakningen kan fortfarande tillåta svarsvägen, eller tvärtom, och ett enkelriktat resultat är den vanliga anledningen till att ett lås bara fungerar halvt. Återanslut en gång efter testet för att bekräfta det stabila tillståndet, och kontrollera att legitim administrationsåtkomst överlevde; en regel skriven för en port har för vana att matcha ett bredare område än avsett.

Anteckna syfte och position tillsammans med regeln

En regel utan ett nedtecknat syfte är en regel som ingen vågar ta bort. Vid varje låspost, behåll flödet den skyddar, kedjan och kroken den lever i, positionen den måste hålla i förhållande till bredare godkännanden och testet som bevisade det. När någon redigerar den omgivande regeluppsättningen sex månader senare är den anteckningen den enda varningen om att positionen var avsiktlig.

Innan du stänger ändringen, bekräfta fyra saker: den körande regeluppsättningen stämmer med filen, den nya regeln har räknare som inte är noll efter ett färskt försök, motsatt riktning och administrationsåtkomst fungerar fortfarande, och du har återanslutit en gång för att bevisa det stabila tillståndet i stället för tillståndet hos en session som är äldre än ändringen. Om något av detta är overifierat är ändringen inte klar, vad tunneln än gör.