Lokal app, VPN-regel: kvifor FORWARD-kjeda di aldri utløysast

Du legg til ein regel for VPN-trafikk i FORWARD-kjeda, køyrer førespurnaden frå same Linux-boks, og teljaren blir ståande på null. Regelen er truleg riktig. Pakken tok aldri den vegen, fordi ein førespurnad som oppstår på maskinen sjølv, ikkje blir vidaresend av han. Å følgje livet til pakken frå socket til kabel forklarer kvifor, og kvar regelen i staden høyrer heime.

Finn ut kvar pakken vart fødd

Hookrekkjefølgja til Netfilter skil tre tilfelle, og berre eitt av dei involverer FORWARD:

Ein lokal applikasjon startar i OUTPUT-stien, fordi kjernen allereie har fastslått at pakken oppstår her og aldri er kandidat for vidaresending. Å opprette ein tunnel endrar ikkje den klassifiseringa; tunnelen er ein eining pakken kan forlate gjennom, ikkje eit trinn som gjer lokal utgang til transit.

To pakkar, éi historie

Når tunnelen er oppe, er den indre pakken til applikasjonen og den krypterte ytre pakken ulike objekt. Den indre pakken ber destinasjonen og nyttelasta appen valde. Den ytre pakken ber chiffertekst til adressa og porten til peeren, og det er den som faktisk kryssar det fysiske grensesnittet.

Policyen din gjeld éin av dei, og å velje feil er ein vanleg grunn til at ein regel ser ut til å ikkje gjere noko. Ein regel som svarar til den ytre adressa til peeren, ser kvar tunnelpakke likt, uansett kva appen inni gjer. Ein regel som svarar til ein indre destinasjon, ser trafikken du bryr deg om, og han utløysast berre om den pakken når hooken du installerte regelen på.

Namnerom flyttar grensa

Ein container gjer dette vanskelegare utan å endre prinsippet. Førespurnaden til applikasjonen er lokal utgang inne i nettverksnamnerommet til containeren. Verten tek imot den trafikken på eit virtuelt Ethernet-grensesnitt og kan vidaresende han, så ein FORWARD-regel på verten kan vere meiningsfull sjølv om prosessen som laga førespurnaden aldri rørte OUTPUT-kjeda til verten.

Før du vel ein hook, må du fastslå kvar regelverket og tunnelen faktisk bur. Ein tunnel inne i containeren, ein tunnel på verten med containeren ruta gjennom han, og ein tunnel i eit eige namnerom er tre ulike topologiar med tre ulike regelplasseringar. Les reglane inne i namnerommet som eig eininga, ikkje berre i standardnamnerommet.

Spør om du i det heile treng eit merke

Om målet er å sende eitt destinasjonsprefiks gjennom tunnelen, kan ei rute for det prefikset vere nok. Sjekk først dei effektive rutene, inkludert alt serveren har dytta på: ei omdirigert standardrute sender langt meir trafikk gjennom VPN-en enn den smale policyen du hadde i tankane, og inga mengd merking får resultatet til å samsvare med hensikta.

Klassifisering trengst når avgjerda heng av noko ei rute ikkje kan uttrykke, som kjelda, brukaren eller prosessen. For motteken trafikk fungerer merking i PREROUTING. For lokal trafikk må merkinga skje i eit utgangstrinn som kan utløyse eit nytt ruteoppslag etter at merket er sett. Med nftables er det ei kjede av typen route på utgangshooken; ei vanleg utgangsfilterkjede set verdien og lèt ruta vere uendra.

Med iptables bur ekvivalenten i mangle OUTPUT-oppsettet, og same kravet gjeld: ruteringsavgjerda må vurderast på nytt etter at merket finst. Deretter må ein policyregel bruke merket og peike på ein tabell med ei brukbar rute. Å setje eit conntrack-merke er ein tredje, separat operasjon; det lagrar ein verdi på flyten og set ikkje i seg sjølv den verdien på den gjeldande pakken så rutinga kan lese han.

Stadfest oppslaget og teljaren saman

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

Adressa og merket er illustrerande, og dei to rutespurnadene svarar på ulike spørsmål. Den andre spør kva kjernen ville gjort om ein pakke bar det merket; han viser ikkje at regelverket ditt tildeler eitt. Handsame det som ein hypotesetest, ikkje som prov på at policyen verkar.

Køyr deretter ein ufarleg førespurnad og sjå på to ting samstundes: teljaren på hooken du valde, og den utgangen pakken faktisk tok. Om teljaren flyttar seg og pakken forlèt ein annan stad, er merket eller tabellen feil. Om ingen av dei flyttar seg, når pakken ikkje den hooken i det heile, og neste spørsmål er namnerommet eller stien.

Til slutt, avgrens testen til det mekanismen kan uttrykke. Éi rute for éi adresse blir ikkje ein permanent policy for ei teneste der adressene roterer. Fastset pakkeomfanget først, og sjekk deretter om ruting- og merkingsdesignet kan halde det omfanget etter ein ny tilkopling.