Lokal app, VPN-regel: varför din FORWARD-kedja aldrig utlöses

Du lägger till en regel för VPN-trafik i FORWARD-kedjan, kör begäran från samma Linux-maskin, och räknaren står kvar på noll. Regeln är förmodligen korrekt. Paketet tog aldrig den vägen, eftersom en begäran som skapas på maskinen själv inte vidarebefordras av den. Att följa paketets liv från socket till kabel förklarar varför, och var regeln i stället hör hemma.

Ta reda på var paketet föddes

Netfilters hookordning skiljer tre fall, och bara ett av dem involverar FORWARD:

En lokal applikation börjar i OUTPUT-vägen, eftersom kärnan redan fastställt att paketet uppstår här och aldrig är kandidat för vidarebefordran. Att skapa en tunnel ändrar inte den klassificeringen; tunneln är en enhet som paketet kan lämna genom, inte ett steg som gör lokal utdata till transit.

Två paket, en historia

När tunneln är uppe är applikationens inre paket och det krypterade yttre paketet olika objekt. Det inre paketet bär destinationen och nyttolasten som appen valde. Det yttre paketet bär chiffertext till peerens adress och port, och det är det som faktiskt korsar det fysiska gränssnittet.

Din policy gäller ett av dem, och att välja fel är en vanlig orsak till att en regel verkar inte göra något. En regel som matchar peerens yttre adress ser varje tunnelpaket likadant, vad appen därinne än gör. En regel som matchar en inre destination ser trafiken du bryr dig om, och den utlöses bara om paketet når den hook där du installerade regeln.

Namnutrymmen flyttar gränsen

En container gör detta svårare utan att ändra principen. Applikationens begäran är lokal utdata inne i containerns nätverksnamnutrymme. Värden tar emot trafiken på ett virtuellt Ethernet-gränssnitt och kan vidarebefordra den, så en FORWARD-regel på värden kan vara meningsfull även om processen som skapade begäran aldrig rörde värdens OUTPUT-kedja.

Innan du väljer en hook måste du fastställa var regelverket och tunneln faktiskt bor. En tunnel inne i containern, en tunnel på värden med containern rutad genom den, och en tunnel i ett separat namnutrymme är tre olika topologier med tre olika regelplaceringar. Läs reglerna inne i det namnutrymme som äger enheten, inte bara i standardnamnutrymmet.

Fråga om du överhuvudtaget behöver en markering

Om målet är att skicka ett destinationsprefix genom tunneln, kan en rutt för det prefixet räcka. Kontrollera först de effektiva rutterna, inklusive allt servern har skjutit in: en omdirigerad standardrutt skickar mycket mer trafik genom VPN:en än den smala policy du hade i åtanke, och ingen mängd markering får resultatet att stämma med avsikten.

Klassificering behövs när beslutet beror på något en rutt inte kan uttrycka, som källan, användaren eller processen. För mottagen trafik fungerar markering i PREROUTING. För lokal trafik måste markeringen ske i ett utsteg som kan utlösa en ny ruttuppslagning efter att markeringen satts. Med nftables är det en kedja av typen route på uthooken; en vanlig utfilterkedja sätter värdet och lämnar rutten oförändrad.

Med iptables bor motsvarigheten i mangle OUTPUT-arrangemanget, och samma krav gäller: routingbeslutet måste ses över efter att markeringen finns. Sedan måste en policyregel förbruka markeringen och peka på en tabell med en användbar rutt. Att sätta en conntrack-markering är en tredje, separat operation; den lagrar ett värde på flödet och sätter inte i sig själv det värdet på det aktuella paketet så att routingen kan läsa det.

Verifiera uppslagningen och räknaren tillsammans

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Adressen och markeringen är illustrativa, och de två ruttfrågorna svarar på olika frågor. Den andra frågar vad kärnan skulle göra om ett paket bar den markeringen; den visar inte att ditt regelverk tilldelar någon. Behandla det som ett hypotestest, inte som bevis för att policyn fungerar.

Kör sedan en ofarlig begäran och titta på två saker samtidigt: räknaren på hooken du valde, och den utgång paketet faktiskt tog. Om räknaren rör sig och paketet lämnar någon annanstans är markeringen eller tabellen fel. Om ingen av dem rör sig når paketet inte hooken alls, och nästa fråga är namnutrymmet eller vägen.

Begränsa slutligen testet till vad mekanismen kan uttrycka. En rutt för en adress blir inte en permanent policy för en tjänst vars adresser roterar. Bestäm paketomfånget först och kontrollera sedan om routing- och markeringsdesignen kan hålla det omfånget efter en återanslutning.