Lokale app, VPN-regel: waarom je FORWARD-keten nooit afgaat

Je voegt een regel voor VPN-verkeer toe aan de FORWARD-keten, voert het verzoek uit vanaf dezelfde Linux-machine, en de teller blijft op nul staan. De regel is waarschijnlijk correct. Het pakket heeft die route nooit genomen, omdat een verzoek dat op de machine zelf ontstaat er niet door wordt doorgestuurd. Het leven van het pakket van socket tot kabel volgen verklaart waarom, en waar de regel in plaats daarvan hoort.

Zoek uit waar het pakket is geboren

De hookvolgorde van Netfilter scheidt drie gevallen, en slechts één daarvan betreft FORWARD:

Een lokale toepassing begint in het OUTPUT-pad, omdat de kernel al heeft vastgesteld dat het pakket hier ontstaat en nooit kandidaat is voor doorsturen. Een tunnel opzetten verandert die classificatie niet; de tunnel is een apparaat waar het pakket doorheen kan vertrekken, geen fase die lokale uitvoer in transit verandert.

Twee pakketten, één verhaal

Zodra de tunnel staat, zijn het binnenste pakket van de app en het versleutelde buitenste pakket verschillende objecten. Het binnenste pakket draagt de bestemming en de payload die de app heeft gekozen. Het buitenste pakket draagt ciphertext naar het adres en de poort van de peer, en dat is wat daadwerkelijk de fysieke interface oversteekt.

Je beleid gaat over een van beide, en de verkeerde kiezen is een veelvoorkomende reden dat een regel niets lijkt te doen. Een regel die overeenkomt met het buitenste adres van de peer ziet elk tunnelpakket gelijk, wat de app binnen ook doet. Een regel die overeenkomt met een binnenste bestemming ziet het verkeer dat je aangaat, en die gaat alleen af als dat pakket de hook bereikt waarop je de regel hebt geïnstalleerd.

Namespaces verschuiven de grens

Een container maakt dit moeilijker zonder het principe te veranderen. Het verzoek van de app is lokale uitvoer binnen de netwerknamespace van de container. De host ontvangt dat verkeer op een virtuele Ethernet-interface en kan het doorsturen, dus een FORWARD-regel op de host kan zinvol zijn, ook al heeft het proces dat het verzoek maakte nooit de OUTPUT-keten van de host aangeraakt.

Voordat je een hook kiest, stel vast waar de regelset en de tunnel werkelijk leven. Een tunnel in de container, een tunnel op de host met de container erdoorheen gerouteerd, en een tunnel in een aparte namespace zijn drie verschillende topologieën met drie verschillende regelplaatsingen. Lees de regels in de namespace die het apparaat bezit, niet alleen in de standaardnamespace.

Vraag je af of je überhaupt een mark nodig hebt

Als het doel is één bestemmingsprefix door de tunnel te sturen, kan een route voor dat prefix genoeg zijn. Controleer eerst de effectieve routes, inclusief alles wat de server heeft geduwd: een omgeleide standaardroute stuurt veel meer verkeer door de VPN dan het smalle beleid dat je voor ogen had, en geen enkele hoeveelheid markering krijgt het resultaat in lijn met de bedoeling.

Classificatie is nodig wanneer de beslissing afhangt van iets wat een route niet kan uitdrukken, zoals de bron, de gebruiker of het proces. Voor ontvangen verkeer werkt markeren in PREROUTING. Voor lokaal verkeer moet het markeren gebeuren in een uitvoerfase die na het zetten van de mark een nieuwe routeopzoeking kan uitlokken. Met nftables is dat een keten van het type route op de uitvoerhook; een gewone uitvoerfilterketen zet de waarde en laat de route ongewijzigd.

Met iptables leeft het equivalent in de mangle OUTPUT-indeling, en dezelfde eis geldt: de routingbeslissing moet opnieuw worden bekeken nadat de mark bestaat. Daarna moet een beleidsregel de mark consumeren en wijzen naar een tabel met een bruikbare route. Een conntrack-mark zetten is een derde, aparte bewerking; die slaat een waarde op de flow op en zet die waarde niet uit zichzelf op het huidige pakket zodat de routing die kan lezen.

Verifieer de opzoeking en de teller samen

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

Het adres en de mark zijn illustratief, en de twee routevragen beantwoorden verschillende vragen. De tweede vraagt wat de kernel zou doen als een pakket die mark droeg; die toont niet aan dat jouw regelset er een toekent. Behandel het als een hypothesetest, niet als bewijs dat het beleid werkt.

Voer daarna een onschadelijk verzoek uit en kijk naar twee dingen tegelijk: de teller op de gekozen hook en de uitgang die het pakket werkelijk nam. Als de teller beweegt en het pakket ergens anders vertrekt, zijn de mark of de tabel fout. Als geen van beide beweegt, bereikt het pakket die hook helemaal niet, en de volgende vraag is de namespace of het pad.

Beperk de test ten slotte tot wat het mechanisme kan uitdrukken. Eén route voor één adres wordt geen permanent beleid voor een dienst waarvan de adressen roteren. Bepaal eerst de pakketomvang en controleer dan of het routing- en markeringsontwerp die omvang na een herverbinding kan vasthouden.