Hvorfor nftables ikke ser OpenVPN-trafikk mellom klienter

To klienter på én server utveksler filer, overføringen lykkes, og hver videresendingsregel du peker mot tunnelen rapporterer null pakker. Reglene er ikke ødelagt, og kjeden står ikke feil. Når videresending mellom parter er slått på, leveres pakken inne i serverprosessen, og vertsstakken blir aldri ruteren, så kjernens brannmur har ingenting å telle. Å forstå denne delingen avgjør om du beholder snarveien eller bygger stien på nytt gjennom kjernen.

Følg én pakke gjennom serveren

I en rutet tunnel gir daemonen hver klients dekrypterte pakke til tunellenheten. Derfra ruter verten den, videresendingskroken kjører, og en regel som samsvarer med tunellenheten kan telle eller forkaste trafikken. Det er stien de fleste brannmureksempler forutsetter.

Snarveien fjerner verten fra midten. Én sesjons dekrypterte pakke gis til en annen sesjon inne i daemonen, og den indre pakken sendes aldri ut på tunellenheten og rutes ikke av verten. Innkapslet trafikk krysser fortsatt det fysiske grensesnittet, så en ytre fangst ser opptatt ut mens de indre reglene forblir tause. En fangst tatt på tunellenheten viser absolutt ingenting, noe som overrasker alle som forventer å se overføringen der. Den asymmetrien er den raskeste måten å kjenne igjen snarveien utenfra daemonen.

Tellertesten som avgjør hvilken sti som ble brukt

Fest en teller til regelen som burde gjelde, kjør en overføring mellom to klienter som regelen burde blokkere, og les telleren etterpå.

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øringen lykkes og telleren blir stående på null, har kjernen aldri behandlet disse pakkene, og ingen regelredigering endrer det. Gjenta den samme testen mot en tjeneste på serveren selv, for den flyten går faktisk gjennom vertsstakken, og telleren beveger seg. Det er sammenligningen av de to resultatene som gir svaret.

To detaljer forhindrer en feil avlesning. Et grensesnittnavn skrevet i en kjedetikett filtrerer ingenting i seg selv, fordi samsvar skjer på grensesnittfelt inne i reglene. Og et broet lag-2-design oppfører seg annerledes igjen: der deler klientene ett kringkastingsdomene, så partsoppdagelse er forventet og ikke en ruterfeil.

En svitsj er ikke en tilgangsliste

Dette er delen som koster en ettermiddag. Videresending mellom parter er én innstilling på eller av, og mens den er på, er daemonen det eneste videresendingspunktet. Vertens brannmur kan ikke uttrykke hvem som kan nå hvem, og filer per klient gjør ikke svitsjen til en policy-matrise.

Hvis du trenger regler per part, er valget mellom å gi opp snarveien og å gi opp vertens brannmur som kontroll. Å slå den av gjenoppretter kjernevideresending, som krever IP-videresending på serveren og uttrykkelige regler for flytene du vil ha. Å la den stå på betyr at policyen lever i daemonens konfigurasjon, som i praksis er alle parter eller ingen parter.

Adskilte serverprosesser med egne adressepuljer og porter er den gjennomførbare mellomveien. Hver prosess bærer nøyaktig én tilgangsbeslutning, så to grupper kan ha ulike regler uten en policy-matrise. Verten kan rute mellom puljene når det er meningen, og da ser brannmuren disse flytene fordi de krysser verten. Kostnaden er ekstra porter, ekstra sertifikater og en profil per gruppe.

Å velge videresendingspunktet

Velg kjernevideresending når brannmuren er policymotoren, når du trenger logging per flyt, eller når regnskap betyr noe. Kostnaden er gjennomstrømning gjennom vertsstakken og flere regler å vedlikeholde. Fordelen er at hvert eksisterende verktøy, fra tellere til flyteksportører, beskriver trafikken igjen. På en liten server er den kostnaden usynlig; på et travelt relay er den ikke.

Velg videresending i prosessen når trafikk mellom parter enten er helt tillatt eller helt forbudt og serveren er dimensjonert for det. Kostnaden er at tellere, kødisipliner og tilkoblingssporing ikke lenger beskriver de indre flytene; det er bare akseptabelt hvis ingen senere baserer seg på dem.

Uansett hva du velger, skriv det ned ved siden av brannmurreglene. Et regelsett som ser ut til å tillate trafikk mellom parter mens daemonen uansett bestemmer, villeder den neste som feilsøker en mislykket overføring. Den som bare leser reglene, vil anta at kjernen er porten.

Hva du bør kontrollere før du endrer regler

Les konfigurasjonen serveren faktisk lastet, ikke filen du husker å ha redigert, og bekreft om partvalget er til stede. Hvis du endret det, må du sørge for at tjenesten lastet på nytt og ikke bare skrev om en fil på disken.

Gjenta deretter testen med en flyt fra klient til server for å bevise at regelen i det hele tatt samsvarer, og kontroller rutene som pushes, for en manglende rute ser fra klientsiden nøyaktig ut som en brannmurstopp. Endre rekkefølgen på reglene først når du vet hvilket videresendingspunkt som eier beslutningen.