Miért nem látja az nftables az OpenVPN ügyfelek közötti forgalmát

Két ügyfél egy szerveren fájlokat cserél, az átvitel sikerül, és minden továbbítási szabály, amelyet az alagútra irányít, nulla csomagot jelent. A szabályok nincsenek elrontva, és a lánc sincs rossz helyen. Ha a partnerek közötti továbbítás be van kapcsolva, a csomag a szerverfolyamaton belül kerül kézbesítésre, és a gazdagép veremtára soha nem lesz útválasztó, így a kernel tűzfalának nincs mit számlálnia. Ennek a kettősségnek a megértése dönti el, hogy megtartja-e a rövidítést, vagy újraépíti az utat a kernelen keresztül.

Kövessen egy csomagot a szerveren keresztül

Egy útválasztott alagútban a démon minden ügyfél visszafejtett csomagját átadja az alagút-eszköznek. Onnan a gazdagép továbbítja, lefut a továbbítási horog, és az alagút-eszközhöz illeszkedő szabály számlálhatja vagy eldobhatja a forgalmat. Ezt az utat feltételezi a legtöbb tűzfalpélda.

A rövidítés kiveszi a gazdagépet a középpontból. Az egyik munkamenet visszafejtett csomagja a démonon belül egy másik munkamenethez kerül, és a belső csomag soha nem kerül ki az alagút-eszközre, és a gazdagép sem továbbítja. A beágyazott forgalom továbbra is átlépi a fizikai interfészt, ezért a külső rögzítés foglaltnak tűnik, miközben a belső szabályok hallgatnak. Az alagút-eszközön készített rögzítés semmit sem mutat, ami mindenkit meglep, aki ott szeretné látni az átvitelt. Ez az aszimmetria a leggyorsabb módja annak, hogy a rövidítést a démonon kívülről felismerje.

A számlálós próba, amely eldönti, melyik út futott le

Csatoljon számlálót az érvényesülni hivatott szabályhoz, futtasson átvitelt két ügyfél között, amelyeket ennek a szabálynak blokkolnia kellene, majd olvassa le a számlálót.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Ha az átvitel sikerül, és a számláló nullán marad, a kernel soha nem kezelte ezeket a csomagokat, és ezen semmilyen szabályszerkesztés nem változtat. Ismételje meg ugyanezt a próbát a szerveren futó szolgáltatás ellen, mert az a folyam valóban átmegy a gazdagép veremtárán, és a számlálója mozdul. A két eredmény összevetése adja meg a választ.

Két részlet akadályozza meg a téves leolvasást. A lánccímkébe írt interfésznév önmagában semmit nem szűr, mert az illesztés a szabályokon belüli interfészmezőkön történik. A hidalt 2. rétegű kialakítás pedig megint másképp viselkedik: ott az ügyfelek egy üzenetszóró tartományt osztanak meg, ezért a partnerfelderítés várható, nem útválasztási hiba.

A kapcsoló nem hozzáférési lista

Ez az a rész, amely egy délutánba kerül. A partnerek közötti továbbítás egyetlen be- vagy kikapcsolt beállítás, és amíg be van kapcsolva, a démon az egyetlen továbbítási pont. A gazdagép tűzfala nem tudja kifejezni, ki kit érhet el, és az ügyfelenkénti fájlok nem teszik a kapcsolót házirend-mátrixszá.

Ha partnerenkénti szabályokra van szüksége, a választás a rövidítés feladása és a gazdagép tűzfalának mint vezérlőnek a feladása között van. Kikapcsolása visszaállítja a kernel továbbítását, amihez IP-továbbítás kell a szerveren és kifejezett szabályok a kívánt folyamokhoz. Bekapcsolva hagyása azt jelenti, hogy a házirend a démon konfigurációjában él, ami a gyakorlatban minden partner vagy egy sem.

Külön szerverfolyamatok saját címtárakkal és portokkal jelentik a járható középutat. Minden folyamat pontosan egy hozzáférési döntést hordoz, így két csoport házirend-mátrix nélkül is kaphat különböző szabályokat. A gazdagép továbbíthat a tárak között, ha ez a szándék, és akkor a tűzfal látja ezeket a folyamokat, mert átlépik a gazdagépet. Az ár a többletport, a többlettanúsítvány és a csoportonkénti profil.

A továbbítási pont kiválasztása

Akkor válassza a kernel továbbítását, ha a tűzfal a házirend-motor, ha folyamonkénti naplózásra van szüksége, vagy ha az elszámolás számít. Az ár a gazdagép veremtárán átmenő átviteli teljesítmény és a több karbantartandó szabály. Az előny, hogy minden meglévő eszköz, a számlálóktól a folyamkiviteli eszközökig, újra leírja a forgalmat. Kis szerveren ez az ár láthatatlan; forgalmas továbbítón nem.

Akkor válassza a folyamaton belüli továbbítást, ha a partnerek közötti forgalom vagy teljesen engedélyezett, vagy teljesen tiltott, és a szerver erre van méretezve. Az ár az, hogy a számlálók, a várakozási sorok fegyelme és a kapcsolatkövetés már nem írja le a belső folyamokat; ez csak akkor elfogadható, ha később senki nem támaszkodik rájuk.

Bármit is választ, írja le a tűzfalszabályok mellé. Egy szabálykészlet, amely úgy tűnik, engedélyezi a partnerek közötti forgalmat, miközben a démon úgyis dönt, félrevezeti a következő embert, aki egy sikertelen átvitelt hibakeres. Aki csak a szabályokat olvassa, azt fogja feltételezni, hogy a kernel a kapu.

Mit ellenőrizzen a szabályok módosítása előtt

Azt a konfigurációt olvassa, amelyet a szerver ténylegesen betöltött, ne azt a fájlt, amelyről emlékszik, hogy szerkesztette, és erősítse meg, hogy a partnerbeállítás jelen van-e. Ha módosította, győződjön meg róla, hogy a szolgáltatás újratöltött, és nem csak újraírt egy fájlt a lemezen.

Ezután ismételje meg a próbát egy ügyféltől szerverig tartó folyammal, hogy bebizonyítsa, a szabály egyáltalán illeszkedik, és ellenőrizze a küldött útvonalakat, mert egy hiányzó útvonal az ügyfél oldaláról pontosan tűzfaltiltásnak látszik. A szabályok sorrendjét csak akkor módosítsa, ha tudja, melyik továbbítási pont birtokolja a döntést.