Varför nftables inte ser OpenVPN-trafik mellan klienter

Två klienter på en server utbyter filer, överföringen lyckas, och varje vidarebefordringsregel du riktar mot tunneln rapporterar noll paket. Reglerna är inte trasiga och kedjan står inte fel. När vidarebefordran mellan parter är påslagen levereras paketet inne i serverprocessen och värdstacken blir aldrig routern, så kärnans brandvägg har inget att räkna. Att förstå den uppdelningen avgör om du behåller genvägen eller bygger vägen på nytt genom kärnan.

Följ ett paket genom servern

I en routad tunnel lämnar daemonen varje klients dekrypterade paket till tunnelenheten. Därifrån routar värden det, vidarebefordringskroken körs, och en regel som matchar tunnelenheten kan räkna eller släppa trafiken. Det är vägen som de flesta brandväggsexempel antar.

Genvägen tar bort värden från mitten. En sessions dekrypterade paket lämnas till en annan session inne i daemonen, och det inre paketet skickas aldrig ut på tunnelenheten och routas inte av värden. Inkapslad trafik korsar fortfarande det fysiska gränssnittet, så en yttre fångst ser upptagen ut medan de inre reglerna förblir tysta. En fångst tagen på tunnelenheten visar ingenting alls, vilket förvånar alla som väntar sig att se överföringen där. Den asymmetrin är det snabbaste sättet att känna igen genvägen utanför daemonen.

Räknartestet som avgör vilken väg som kördes

Fäst en räknare på regeln som borde gälla, kör en överföring mellan två klienter som regeln borde blockera, och läs räknaren efteråt.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Om överföringen lyckas och räknaren stannar på noll har kärnan aldrig hanterat de paketen, och ingen regelredigering ändrar det. Upprepa samma test mot en tjänst på servern själv, eftersom det flödet faktiskt går genom värdstacken och räknaren rör sig. Det är jämförelsen av de två resultaten som ger svaret.

Två detaljer förhindrar en felaktig avläsning. Ett gränssnittsnamn som skrivs i en kedjeetikett filtrerar ingenting i sig, eftersom matchningen sker på gränssnittsfält inne i reglerna. Och en bryggd lag-2-design beter sig annorlunda igen: där delar klienterna en broadcastdomän, så partsupptäckt är förväntat och inte ett routingfel.

En switch är inte en åtkomstlista

Det här är delen som kostar en eftermiddag. Vidarebefordran mellan parter är en enda inställning på eller av, och medan den är på är daemonen den enda vidarebefordringspunkten. Värdens brandvägg kan inte uttrycka vem som får nå vem, och filer per klient gör inte switchen till en policymatris.

Om du behöver regler per part är valet mellan att ge upp genvägen och att ge upp värdens brandvägg som kontroll. Att stänga av den återställer kärnvidarebefordran, vilket kräver IP-vidarebefordran på servern och uttryckliga regler för de flöden du vill ha. Att låta den vara på betyder att policyn lever i daemonens konfiguration, vilket i praktiken är alla parter eller inga parter.

Separat serverprocesser med egna adresspooler och portar är den genomförbara mellanvägen. Varje process bär exakt ett åtkomstbeslut, så två grupper kan ha olika regler utan en policymatris. Värden kan routa mellan poolerna när det är meningen, och då ser brandväggen dessa flöden eftersom de korsar värden. Kostnaden är extra portar, extra certifikat och en profil per grupp.

Att välja vidarebefordringspunkt

Välj kärnvidarebefordran när brandväggen är policymotorn, när du behöver loggning per flöde, eller när redovisning spelar roll. Kostnaden är genomströmning genom värdstacken och fler regler att underhålla. Fördelen är att varje befintligt verktyg, från räknare till flödesexportörer, beskriver trafiken igen. På en liten server är den kostnaden osynlig; på en upptagen relay är den inte det.

Välj vidarebefordran i processen när trafik mellan parter antingen är helt tillåten eller helt förbjuden och servern är dimensionerad för det. Kostnaden är att räknare, ködiscipliner och anslutningsspårning inte längre beskriver de inre flödena; det är bara acceptabelt om ingen senare förlitar sig på dem.

Vad du än väljer, skriv ner det bredvid brandväggsreglerna. En regeluppsättning som ser ut att tillåta trafik mellan parter medan daemonen ändå avgör vilseleder nästa person som felsöker en misslyckad överföring. Den som bara läser reglerna kommer att anta att kärnan är porten.

Vad du bör kontrollera innan du ändrar regler

Läs den konfiguration servern faktiskt laddade, inte filen du minns att du redigerade, och bekräfta om partalternativet finns. Om du ändrade det måste du se till att tjänsten laddade om och inte bara skrev om en fil på disken.

Upprepa sedan testet med ett flöde från klient till server för att bevisa att regeln över huvud taget matchar, och kontrollera de pushade rutterna, för en saknad rutt ser från klientsidan exakt ut som en brandväggsblockering. Ändra regelordningen först när du vet vilken vidarebefordringspunkt som äger beslutet.