Waarom nftables het OpenVPN-verkeer tussen clients niet ziet

Twee clients op één server wisselen bestanden uit, de overdracht slaagt, en elke forward-regel die je op de tunnel richt meldt nul pakketten. De regels zijn niet kapot en de keten staat niet verkeerd. Met doorsturen tussen peers ingeschakeld wordt het pakket binnen het serverproces afgeleverd en wordt de hoststack nooit de router, dus de kernelfirewall heeft niets te tellen. Begrijpen waar die splitsing zit, bepaalt of je de snelkoppeling houdt of het pad via de kernel opnieuw opbouwt.

Volg één pakket door de server

In een geroute tunnel geeft de daemon het ontsleutelde pakket van elke client aan het tunnelapparaat. Vanaf daar routeert de host het, de forward-hook loopt, en een regel die bij het tunnelapparaat past kan het verkeer tellen of laten vallen. Dat is het pad dat de meeste firewallvoorbeelden aannemen.

De snelkoppeling haalt de host uit het midden. Het ontsleutelde pakket van de ene sessie wordt binnen de daemon aan een andere sessie gegeven, en het binnenste pakket wordt nooit op het tunnelapparaat uitgestuurd en niet door de host gerouteerd. Ingekapseld verkeer steekt nog steeds de fysieke interface over, dus een buitenste capture lijkt druk terwijl de binnenregels stil blijven. Een capture op het tunnelapparaat toont helemaal niets, wat iedereen verrast die de overdracht daar verwacht te zien. Die asymmetrie is de snelste manier om de snelkoppeling van buiten de daemon te herkennen.

De tellertest die beslist welk pad is gelopen

Hang een teller aan de regel die zou moeten gelden, voer een overdracht uit tussen twee clients die die regel zou moeten blokkeren, en lees de teller daarna.

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

Als de overdracht slaagt en de teller op nul blijft, heeft de kernel die pakketten nooit verwerkt, en geen enkele regelwijziging verandert dat. Herhaal dezelfde test tegen een dienst op de server zelf, want die stroom gaat wel door de hoststack en de teller beweegt. Het vergelijken van de twee resultaten is wat het antwoord oplevert.

Twee details voorkomen een verkeerde meting. Een interfacenaam die in een ketenlabel staat, filtert op zichzelf niets, omdat de match op interfacevelden binnen regels gebeurt. En een overbrugd laag-2-ontwerp gedraagt zich weer anders: daar delen de clients één broadcastdomein, dus peer-detectie is verwacht en geen routeringsfout.

Een switch is geen toegangslijst

Dit is het deel dat een middag kost. Doorsturen tussen peers is één aan-of-uit-instelling, en zolang die aan staat is de daemon het enige doorstuurpunt. De hostfirewall kan niet uitdrukken wie wie mag bereiken, en bestanden per client maken de switch niet tot een beleidsmatrix.

Heb je regels per peer nodig, dan is de keuze tussen de snelkoppeling opgeven en de hostfirewall als sturing opgeven. Die uitzetten herstelt kernel-doorsturen, wat IP-doorsturen op de server en expliciete regels voor de gewenste stromen vereist. Aan laten betekent dat het beleid in de configuratie van de daemon leeft, wat in de praktijk alle peers of geen peers is.

Aparte serverprocessen met eigen adrespoelen en poorten zijn de werkbare middenweg. Elk proces draagt precies één toegangsbeslissing, dus twee groepen kunnen verschillende regels hebben zonder beleidsmatrix. De host kan tussen de poelen routeren wanneer dat de bedoeling is, en dan ziet de firewall die stromen omdat ze de host passeren. De prijs is extra poorten, extra certificaten en een profiel per groep.

Het doorstuurpunt kiezen

Kies kernel-doorsturen wanneer de firewall de beleidsmotor is, wanneer je logging per stroom nodig hebt, of wanneer boekhouding telt. De prijs is doorvoer door de hoststack en meer regels om te onderhouden. Het voordeel is dat elk bestaand hulpmiddel, van tellers tot stroom-exporteurs, het verkeer weer beschrijft. Op een kleine server is die prijs onzichtbaar; op een drukke relay niet.

Kies doorsturen in het proces wanneer verkeer tussen peers of helemaal toegestaan of helemaal geweigerd is en de server daarop is gedimensioneerd. De prijs is dat tellers, wachtrijdisciplines en verbindingstracking de binnenstromen niet meer beschrijven; dat is alleen aanvaardbaar als niemand er later op vertrouwt.

Wat je ook kiest, schrijf het naast de firewallregels. Een regelset die verkeer tussen peers lijkt toe te staan terwijl de daemon het toch beslist, misleidt de volgende persoon die een mislukte overdracht debugt. Wie alleen de regels leest, gaat ervan uit dat de kernel de poort is.

Wat te controleren voordat je regels wijzigt

Lees de configuratie die de server werkelijk heeft geladen, niet het bestand waarvan je je herinnert dat je het hebt bewerkt, en bevestig of de peer-optie aanwezig is. Heb je die gewijzigd, zorg dan dat de dienst opnieuw is geladen en niet alleen een bestand op schijf heeft herschreven.

Herhaal dan de test met een stroom van client naar server om te bewijzen dat de regel helemaal matcht, en controleer de gepushte routes, want een ontbrekende route lijkt vanaf de clientkant precies op een firewallblokkade. Wijzig de regelvolgorde pas als je weet welk doorstuurpunt de beslissing heeft.