Helyi alkalmazás, VPN-szabály: miért nem lép soha működésbe a FORWARD láncod

Hozzáadsz egy szabályt a VPN-forgalomhoz a FORWARD láncban, ugyanarról a Linux-gépről indítod a kérést, és a számláló nullán marad. A szabály valószínűleg helyes. A csomag soha nem járt azon az úton, mert a gépen magán keletkező kérést az nem továbbítja. A csomag életének követése a socket-től a kábelig megmagyarázza, miért van ez így, és hová kellene inkább a szabálynak kerülnie.

Találd meg, hol született a csomag

A Netfilter hook-sorrendje három esetet különít el, és csak az egyik érinti a FORWARD-ot:

A helyi alkalmazás az OUTPUT útvonalon indul, mert a kernel már megállapította, hogy a csomag itt keletkezik, és soha nem jelölt a továbbításra. Az alagút létrehozása nem változtat ezen a besoroláson; az alagút egy eszköz, amelyen a csomag elhagyhatja a gépet, nem pedig egy szakasz, amely a helyi kimenetet tranzitté alakítja.

Két csomag, egy történet

Amint az alagút feláll, az alkalmazás belső csomagja és a titkosított külső csomag különböző objektumok. A belső csomag hordozza az alkalmazás által választott célt és hasznos terhet. A külső csomag a titkosított szöveget viszi a partner címére és portjára, és valójában ez halad át a fizikai interfészen.

A szabályzatod az egyikükre vonatkozik, és a rossz kiválasztása gyakori oka annak, hogy egy szabály úgy tűnik, semmit sem tesz. A partner külső címére illeszkedő szabály minden alagútcsomagot ugyanúgy lát, bármit is tesz a belső alkalmazás. A belső célra illeszkedő szabály azt a forgalmat látja, amely fontos neked, és csak akkor lép működésbe, ha az a csomag eléri azt a hookot, amelyre a szabályt telepítetted.

A névterek elmozdítják a határt

Egy konténer nehezebbé teszi ezt anélkül, hogy az elvet megváltoztatná. Az alkalmazás kérése helyi kimenet a konténer hálózati névterén belül. A gazdagép virtuális Ethernet-interfészen fogadja ezt a forgalmat, és továbbíthatja, ezért a gazdagépen egy FORWARD szabály értelmes lehet, pedig a kérést létrehozó folyamat soha nem érintette a gazdagép OUTPUT láncát.

Mielőtt hookot választasz, állapítsd meg, hol él valójában a szabálykészlet és az alagút. Alagút a konténeren belül, alagút a gazdagépen a konténer rajta keresztül történő irányításával, és alagút külön névtérben három különböző topológia három különböző szabályelhelyezéssel. A szabályokat abban a névtérben olvasd, amely birtokolja az eszközt, ne csak az alapértelmezettben.

Kérdezd meg, kell-e egyáltalán jelölés

Ha a cél egy célprefix alagúton keresztüli küldése, elegendő lehet egy útvonal ahhoz a prefixhez. Először az érvényes útvonalakat ellenőrizd, beleértve mindent, amit a szerver tolt: egy átirányított alapértelmezett útvonal sokkal több forgalmat küld a VPN-en át, mint a szűk szabályzat, amelyre gondoltál, és a jelölés semmilyen mennyisége nem hozza összhangba az eredményt a szándékkal.

Besorolásra akkor van szükség, ha a döntés olyasmitől függ, amit egy útvonal nem tud kifejezni, például a forrástól, a felhasználótól vagy a folyamattól. A fogadott forgalom esetében a PREROUTING-ban történő jelölés működik. Helyi forgalom esetében a jelölést egy kimeneti szakaszban kell elvégezni, amely a jelölés beállítása után új útvonalkeresést indíthat. Az nftables esetében ez egy route típusú lánc a kimeneti hookon; egy közönséges kimeneti szűrőlánc beállítja az értéket, és az útvonalat változatlanul hagyja.

Az iptables esetében a megfelelő dolog a mangle OUTPUT elrendezésben él, és ugyanaz a követelmény érvényes: az útválasztási döntést a jelölés létezése után újra meg kell vizsgálni. Ezután egy házirend-szabálynak fel kell használnia a jelölést, és egy használható útvonalat tartalmazó táblára kell mutatnia. A conntrack jelölés beállítása harmadik, külön művelet; értéket tárol a folyamon, és önmagában nem teszi rá ezt az értéket az aktuális csomagra, hogy az útválasztás olvashassa.

Ellenőrizd a keresést és a számlálót együtt

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

A cím és a jelölés szemléltető jellegű, és a két útvonalkérdés különböző kérdésekre válaszol. A második azt kérdezi, mit tenne a kernel, ha egy csomag hordozná azt a jelölést; nem azt mutatja, hogy a szabálykészleted kioszt egyet. Kezeld hipotézis-tesztként, nem annak bizonyítékaként, hogy a szabályzat működik.

Ezután indíts egy ártalmatlan kérést, és figyelj egyszerre két dolgot: a választott hookon lévő számlálót és azt a kimenetet, amelyet a csomag valójában vett. Ha a számláló mozdul, és a csomag máshol hagyja el a gépet, akkor a jelölés vagy a tábla rossz. Ha egyik sem mozdul, a csomag egyáltalán nem éri el azt a hookot, és a következő kérdés a névtér vagy az útvonal.

Végül korlátozd a tesztet arra, amit a mechanizmus ki tud fejezni. Egy útvonal egy címhez nem válik állandó szabályzattá egy olyan szolgáltatás számára, amelynek címei változnak. Először döntsd el a csomagok hatókörét, majd ellenőrizd, hogy az útválasztási és jelölési kialakítás tartani tudja-e ezt a hatókört újracsatlakozás után.