Plaaslike app, VPN-reël: waarom jou FORWARD-ketting nooit vuur nie

Jy voeg ’n reël vir VPN-verkeer in die FORWARD-ketting by, voer die versoek vanaf dieselfde Linux-boks uit, en die teller bly op nul. Die reël is waarskynlik korrek. Die pakkie het nooit daardie pad gevolg nie, want ’n versoek wat op die masjien self geskep word, word nie deur dit aangestuur nie. Om die pakkie se lewe van die sokkel tot die draad te volg, verduidelik waarom, en waar die reël eerder hoort.

Vind waar die pakkie gebore is

Netfilter se haakorde skei drie gevalle, en net een daarvan behels FORWARD:

’n Plaaslike toepassing begin in die OUTPUT-pad, want die kern het reeds vasgestel dat die pakkie hier ontstaan en nooit ’n kandidaat vir aansturing is nie. Om ’n tonnel te skep verander nie daardie klassifikasie nie; die tonnel is ’n toestel waardeur die pakkie kan vertrek, nie ’n stadium wat plaaslike uitset in transito omskakel nie.

Twee pakkies, een verhaal

Sodra die tonnel op is, is die toepassing se binnepakkie en die geënkripteerde buitenste pakkie verskillende objekte. Die binnepakkie dra die bestemming en vrag wat die app gekies het. Die buitenste pakkie dra syferteks na die eweknie se adres en poort, en dit is wat werklik die fisiese koppelvlak oorsteek.

Jou beleid raak een van hulle, en om die verkeerde een te kies is ’n algemene rede waarom ’n reël niks blyk te doen nie. ’n Reël wat die eweknie se buitenste adres pas, sien elke tonnelpakkie eenders, ongeag wat die toepassing binne doen. ’n Reël wat ’n binneste bestemming pas, sien die verkeer waaroor jy bekommerd is, en dit sal net vuur as daardie pakkie die haak bereik waarop jy die reël geïnstalleer het.

Naamruimtes verskuif die grens

’n Houer maak dit moeiliker sonder om die beginsel te verander. Die toepassing se versoek is plaaslike uitset binne die houer se netwerknaamruimte. Die gasheer ontvang daardie verkeer op ’n virtuele Ethernet-koppelvlak en kan dit aanstuur, so ’n FORWARD-reël op die gasheer kan betekenisvol wees selfs al het die proses wat die versoek geskep het nooit die gasheer se OUTPUT-ketting geraak nie.

Voordat jy ’n haak kies, stel vas waar die reëlstel en die tonnel werklik woon. ’n Tonnel binne die houer, ’n tonnel op die gasheer met die houer wat daardeur gerouteer word, en ’n tonnel in ’n aparte naamruimte is drie verskillende topologieë met drie verskillende reëlplasings. Lees die reëls binne die naamruimte wat die toestel besit, nie net in die verstek een nie.

Vra of jy hoegenaamd ’n merk nodig het

As die doel is om een bestemmingsvoorvoegsel deur die tonnel te stuur, is ’n roete vir daardie voorvoegsel miskien genoeg. Kyk eers na die effektiewe roetes, insluitend enigiets wat die bediener gestoot het: ’n omgeleide verstek stuur baie meer verkeer deur die VPN as die smal beleid wat jy in gedagte gehad het, en geen hoeveelheid merk sal die resultaat met die bedoeling laat ooreenstem nie.

Klassifikasie is nodig wanneer die besluit afhang van iets wat ’n roete nie kan uitdruk nie, soos die bron, die gebruiker of die proses. Vir ontvange verkeer werk merk in PREROUTING. Vir plaaslike verkeer moet die merk in ’n uitsetstadium gebeur wat ’n nuwe roetesoektog kan begin nadat die merk gestel is. Met nftables is dit ’n roete-tipe ketting op die uitsethaak; ’n gewone uitsetfilterketting sal die waarde stel en die roete onveranderd laat.

Met iptables woon die ekwivalent in die mangle OUTPUT-reëling, en dieselfde vereiste geld: die roetebesluit moet herbesoek word nadat die merk bestaan. Dan moet ’n beleidsreël die merk verbruik en na ’n tabel wys wat ’n bruikbare roete bevat. Om ’n conntrack-merk te stel is ’n derde, aparte bewerking; dit stoor ’n waarde op die vloei en plaas dit nie op sigself op die huidige pakkie sodat roetering dit kan lees nie.

Verifieer die soektog en die teller saam

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

Die adres en merk is illustratief, en die twee roetevrae beantwoord verskillende vrae. Die tweede vra wat die kern sou doen as ’n pakkie daardie merk gedra het; dit wys nie dat jou reëlstel een toeken nie. Behandel dit as ’n hipotesetoets, nie as bewys dat die beleid werk nie.

Voer dan ’n onskadelike versoek uit en kyk terselfdertyd na twee dinge: die teller op die haak wat jy gekies het, en die uitgang wat die pakkie werklik geneem het. As die teller beweeg en die pakkie vertrek elders, is die merk of die tabel verkeerd. As nie een beweeg nie, bereik die pakkie daardie haak glad nie, en die naamruimte of die pad is die volgende vraag.

Ten slotte, beperk die toets tot wat die meganisme kan uitdruk. Een roete vir een adres word nie ’n permanente beleid vir ’n diens wie se adresse roteer nie. Besluit eers oor die pakkiebestek en kyk dan of die roetering- en merkontwerp daardie bestek na ’n herverbinding kan handhaaf.