Lokal app, VPN-regel: hvorfor FORWARD-kjeden din aldri utløses

Du legger til en regel for VPN-trafikk i FORWARD-kjeden, kjører forespørselen fra samme Linux-boks, og telleren blir stående på null. Regelen er trolig riktig. Pakken tok aldri den veien, fordi en forespørsel som oppstår på maskinen selv, ikke videresendes av den. Å følge pakkens liv fra socket til kabel forklarer hvorfor, og hvor regelen i stedet hører hjemme.

Finn ut hvor pakken ble født

Netfilters hookrekkefølge skiller tre tilfeller, og bare ett av dem involverer FORWARD:

En lokal applikasjon starter i OUTPUT-stien, fordi kjernen allerede har fastslått at pakken oppstår her og aldri er kandidat for videresending. Å opprette en tunnel endrer ikke den klassifiseringen; tunnelen er en enhet pakken kan forlate gjennom, ikke et trinn som gjør lokal utgang til transit.

To pakker, én historie

Når tunnelen er oppe, er applikasjonens indre pakke og den krypterte ytre pakken forskjellige objekter. Den indre pakken bærer destinasjonen og nyttelasten appen valgte. Den ytre pakken bærer chiffertekst til peerens adresse og port, og det er den som faktisk krysser det fysiske grensesnittet.

Policyen din gjelder én av dem, og å velge feil er en vanlig grunn til at en regel ser ut til å ikke gjøre noe. En regel som samsvarer med peerens ytre adresse, ser hver tunnelpakke likt, uansett hva appen inni gjør. En regel som samsvarer med en indre destinasjon, ser trafikken du bryr deg om, og den utløses bare hvis den pakken når hooken du installerte regelen på.

Navnerom flytter grensen

En container gjør dette vanskeligere uten å endre prinsippet. Applikasjonens forespørsel er lokal utgang inne i containerens nettverksnavnerom. Verten mottar den trafikken på et virtuelt Ethernet-grensesnitt og kan videresende den, så en FORWARD-regel på verten kan være meningsfull selv om prosessen som laget forespørselen aldri rørte vertens OUTPUT-kjede.

Før du velger en hook, må du fastslå hvor regelverket og tunnelen faktisk bor. En tunnel inne i containeren, en tunnel på verten med containeren rutet gjennom den, og en tunnel i et eget navnerom er tre ulike topologier med tre ulike regelplasseringer. Les reglene inne i navnerommet som eier enheten, ikke bare i standardnavnerommet.

Spør om du i det hele tatt trenger et merke

Hvis målet er å sende ett destinasjonsprefiks gjennom tunnelen, kan en rute for det prefikset være nok. Sjekk først de effektive rutene, inkludert alt serveren har dyttet på: en omdirigert standardrute sender langt mer trafikk gjennom VPN-en enn den smale policyen du hadde i tankene, og ingen mengde merking får resultatet til å samsvare med hensikten.

Klassifisering trengs når avgjørelsen avhenger av noe en rute ikke kan uttrykke, som kilden, brukeren eller prosessen. For mottatt trafikk fungerer merking i PREROUTING. For lokal trafikk må merkingen skje i et utgangstrinn som kan utløse et nytt ruteoppslag etter at merket er satt. Med nftables er det en kjede av typen route på utgangshooken; en vanlig utgangsfilterkjede setter verdien og lar ruten være uendret.

Med iptables bor ekvivalenten i mangle OUTPUT-oppsettet, og samme krav gjelder: rutingsavgjørelsen må vurderes på nytt etter at merket finnes. Deretter må en policyregel forbruke merket og peke på en tabell med en brukbar rute. Å sette et conntrack-merke er en tredje, separat operasjon; det lagrer en verdi på flyten og setter ikke i seg selv den verdien på den gjeldende pakken så rutingen kan lese den.

Verifiser oppslaget og telleren sammen

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

Adressen og merket er illustrative, og de to rutespørringene svarer på forskjellige spørsmål. Den andre spør hva kjernen ville gjort hvis en pakke bar det merket; den viser ikke at regelverket ditt tildeler ett. Behandle det som en hypotesetest, ikke som bevis for at policyen virker.

Kjør deretter en ufarlig forespørsel og se på to ting samtidig: telleren på hooken du valgte, og den utgangen pakken faktisk tok. Hvis telleren beveger seg og pakken forlater et annet sted, er merket eller tabellen feil. Hvis ingen av dem beveger seg, når pakken ikke den hooken i det hele tatt, og neste spørsmål er navnerommet eller stien.

Til slutt, begrens testen til det mekanismen kan uttrykke. Én rute for én adresse blir ikke en permanent policy for en tjeneste hvis adresser roterer. Bestem pakkeomfanget først, og sjekk deretter om ruting- og merkingsdesignet kan holde det omfanget etter en gjenoppkobling.