Hvorfor nftables ikke kan se OpenVPN-trafik mellem klienter

To klienter på én server udveksler filer, overførslen lykkes, og hver videresendelsesregel, du peger mod tunnelen, rapporterer nul pakker. Reglerne er ikke i stykker, og kæden står ikke forkert. Når videresendelse mellem parter er slået til, leveres pakken inde i serverprocessen, og værtens netværksstak bliver aldrig routeren, så kernens firewall har intet at tælle. Forståelsen af den opdeling afgør, om du beholder genvejen eller genopbygger ruten gennem kernen.

Følg én pakke gennem serveren

I en rutet tunnel giver dæmonen hver klients dekrypterede pakke til tunneleenheden. Derfra ruter værten den, videresendelses-hooket kører, og en regel, der matcher tunneleenheden, kan tælle eller droppe trafikken. Det er den vej, de fleste firewall-eksempler antager.

Genvejen fjerner værten fra midten. Én sessions dekrypterede pakke gives til en anden session inde i dæmonen, og den indre pakke udsendes aldrig på tunneleenheden og rutes ikke af værten. Indkapslet trafik krydser stadig det fysiske interface, så en ydre optagelse ser travl ud, mens de indre regler forbliver tavse. En optagelse taget på tunneleenheden viser slet intet, hvilket overrasker enhver, der forventer at se overførslen der. Den asymmetri er den hurtigste måde at genkende genvejen udefra dæmonen.

Tællertesten, der afgør, hvilken vej der blev brugt

Sæt en tæller på den regel, der burde gælde, kør en overførsel mellem to klienter, som reglen burde blokere, og læs tælleren bagefter.

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

Hvis overførslen lykkes, og tælleren bliver på nul, har kernen aldrig håndteret de pakker, og ingen mængde regelredigering ændrer det. Gentag den samme test mod en tjeneste på selve serveren, for det flow går faktisk gennem værtens stak, og dets tæller flytter sig. Det er sammenligningen af de to resultater, der giver svaret.

To detaljer forhindrer en falsk aflæsning. Et interfacenavn skrevet i en kædeetiket filtrerer intet i sig selv, fordi matchning sker på interfacefelter inde i reglerne. Og et broet lag-2-design opfører sig igen anderledes: der deler klienterne et broadcast-domæne, så peer-opdagelse er forventet snarere end en rutefejl.

En switch er ikke en adgangsliste

Det er den del, der koster en eftermiddag. Videresendelse mellem parter er én indstilling til eller fra, og mens den er til, er dæmonen det eneste videresendelsespunkt. Værtens firewall kan ikke udtrykke, hvem der må nå hvem, og filer pr. klient gør ikke switchen til en politikmatrix.

Hvis du har brug for regler pr. part, er valget mellem at opgive genvejen og at opgive værtens firewall som styring. At slå den fra gendanner kernel-videresendelse, hvilket kræver IP-videresendelse på serveren og udtrykkelige regler for de flows, du vil have. At holde den til betyder, at politikken lever i dæmonens konfiguration, hvilket i praksis er alle parter eller ingen parter.

Adskilte serverprocesser med egne adressepuljer og porte er den brugbare mellemvej. Hver proces bærer præcis én adgangsbeslutning, så to grupper kan have forskellige regler uden en politikmatrix. Værten kan rute mellem puljerne, når det er meningen, og så ser firewallen de flows, fordi de krydser værten. Prisen er ekstra porte, ekstra certifikater og en profil pr. gruppe.

At vælge videresendelsespunktet

Vælg kernel-videresendelse, når firewallen er politikmotoren, når du har brug for logning pr. flow, eller når regnskab betyder noget. Prisen er gennemstrømning gennem værtens stak og flere regler at vedligeholde. Fordelen er, at ethvert eksisterende værktøj, fra tællere til flow-eksportører, igen beskriver trafikken. På en lille server er den pris usynlig; på et travlt relay er den ikke.

Vælg videresendelse i processen, når trafik mellem parter enten er helt tilladt eller helt afvist, og serveren er dimensioneret til det. Prisen er, at tællere, kødiscipliner og forbindelsessporing ikke længere beskriver de indre flows; det er kun acceptabelt, hvis ingen senere stoler på dem.

Uanset hvad du vælger, så skriv det ned ved siden af firewall-reglerne. Et regelsæt, der ser ud til at tillade trafik mellem parter, mens dæmonen alligevel afgør det, vildleder den næste person, der fejlretter en mislykket overførsel. Enhver, der kun læser reglerne, vil antage, at kernen er porten.

Hvad du skal kontrollere, før du ændrer regler

Læs den konfiguration, serveren faktisk har indlæst, ikke den fil, du husker at have redigeret, og bekræft, om part-indstillingen er til stede. Hvis du har ændret den, så sørg for, at tjenesten genindlæste i stedet for blot at genskrive en fil på disken.

Gentag derefter testen med et flow fra klient til server for at bevise, at reglen overhovedet matcher, og kontroller de push'ede ruter, for en manglende rute ser fra klientens side præcis ud som en firewall-blokering. Ændr kun regelrækkefølgen, når du ved, hvilket videresendelsespunkt der ejer beslutningen.