Miért nem talál soha egy OpenVPN-ügyfél-blokkoló szabály a FORWARD-ban

Két ügyfél ugyanazon az OpenVPN-kiszolgálón elérheti egymást, még akkor is, ha hozzáadtál egy DROP-szabályt a pool-jukhoz. A szabály a FORWARD láncban ül, a forgalom tisztán folyik, és a szabály számlálója nullán marad. A természetes következtetés az, hogy a tűzfal elromlott. Gyakrabban viszont a csomag soha nem is lépett be a láncba.

Két útvonalon haladhat át egy peer-csomag az OpenVPN-kiszolgálón, és ezeket a konfiguráció dönti el, nem a tűzfal. Ha tudod, melyik útvonal van használatban, az megmondja, hogy egy gazdagép-szabály egyáltalán a megfelelő helyen van-e.

Két útvonal, amelyen egy peer-csomag haladhat

Amikor a belső továbbítási beállítás ki van kapcsolva, egy A ügyféltől érkező csomag a B ügyfélnek kiosztott cím tartományába tartó céllal érkezik meg az alagút interfészre. A kiszolgáló útválasztási táblája ugyanazon az alagút interfészen küldi vissza, mert a B címéhez vezető útvonal a kiszolgálóé. Ez egy be- és kimenő folyam a gazdagépen keresztül, és az IPv4-továbbítási útvonal értékeli.

Amikor a belső továbbítási beállítás be van kapcsolva, a kiszolgáló folyamata a csomagot egy csatlakozott ügyfélhez rendeli, és közvetlenül annak az ügyfélnek írja vissza. A csomag a daemonon belül kerül feldolgozásra, és soha nem lép be újra az alagút-eszközbe, így a gazdagép továbbítási útvonala teljesen kimarad. Az OpenVPN 2.6 kézikönyve ezt a beállítást belső ügyfél-ügyfél továbbításként írja le, és pontosan ezért nem láthatja egy gazdagép tűzfalszabálya.

Létezik egy harmadik változat is olyan telepítésekben, amelyek az adatcsatornát kernelmodulba helyezik át. A továbbítási döntés és a titkosítás elhagyja a felhasználói teret, és hogy a netfilter látja-e a folyamot, attól függ, hogyan épül fel az átviteli útvonal. Soha ne feltételezd, hogy egy régi szabálykészlet ugyanúgy viselkedik egy átviteles kiszolgálón, mint egy felhasználói téri kiszolgálón. A módot a futó konfigurációból erősítsd meg, ne a csomagverzióból.

Amikor a számláló soha nem mozdul

A nulla számláló azt jelenti, hogy a csomag azon a ponton nem egyezett azzal a szabállyal, és ennek több oka van. Az első a fenti megkerülés: a forgalom soha nem érte el a láncot. A második az interfész, az irány, a forrás vagy a cél eltérése, ami gyakori, amikor a poolt újraszámozták, és a szabály még a régi előtagot nevezi meg.

A harmadik a pozíció. Egy korábbi szabály a láncban még a DROP-szabályod értékelése előtt elfogadhatja a folyamot, és egy későbbi szabály lehet az, amely valójában eldönti az eredményt. Olvasd a láncot sorrendben, látható számlálókkal, majd ellenőrizd, melyik szabály számlálója nő, amikor megismétled a tesztet.

Végezz egyetlen ellenőrzött cserét két ügyfél között, amelyek valódi címeit a kiszolgáló saját állapotából erősítetted meg, nem egy emlékezetből idézett bérletből. Ha a vonatkozó számláló még mindig nem mozdul, gyanakodj az útvonalra, mielőtt átírod az egyeztetést. Ha mozdul, de a kapcsolat mégis sikerül, a drop később felülíródik, és a sorrend a probléma. Ez a válasz dönti el, hogy a javítás szabályváltozás vagy topológiaváltozás, ezért szerezd meg, mielőtt bármit szerkesztenél.

Olyan határ választása, amely képes szűrni

Ha a szabályzatnak a gazdagép tűzfalában kell élnie, tedd a forgalmat oda, ahol a tűzfal látja. A belső továbbítás kikapcsolása a támogatott módja annak, hogy a peer-forgalom áthaladjon az alagút interfészen és a továbbítási útvonalon, azzal az árával, hogy minden peer-csomag átmegy a gazdagép vermén.

Ezután pontosan egyeztesd a folyamot. A forgalom az alagút interfészen érkezik és az alagút interfészen távozik, mindkét irányban, ezért a csak a fizikai interfészt vizsgáló szabályok nem fognak egyezni. A címalapú szabályoknak szükségük van az aktuális poolra, és figyelembe kell venniük a visszirányt éppúgy, mint az előre irányt.

Sok telepítésnek jobban szolgál az ügyfél- vagy csoportszintű szűrés, ahol az identitás ismert, és a szabályzat a felhasználót követi egy olyan cím helyett, amely újracsatlakozáskor változik. Ez más mechanizmus, mint egy gazdagép-lánc, és a kettőt nem szabad világos ok nélkül keverni.

Ne vidd át változatlanul egy régi topológia szabálykészletét egy migráción. A címpoolek, az interfésznevek és a továbbítási módok mind befolyásolják, hogy egy szabály egyezik-e, és egy másolt szabály, amely régen működött, a legfélrevezetőbb bizonyítékfajta. Indulj ki abból a folyamból, amelyet engedélyezni akarsz, és írd meg a hozzá illő szabályt.

Az elkülönítés tesztelése a szabályban való bizakodás helyett

Teszteld a tiltott esetet és az engedélyezett esetet ugyanabban a futásban. Indíts új kapcsolatot az egyik ügyféltől a másikig, és erősítsd meg, hogy meghiúsul, majd erősítsd meg, hogy az engedélyezendő kapcsolat továbbra is működik. Ha csak az elsőt tesztelik, a mindent blokkoló tűzfal sikernek látszik.

Ismételd meg a kiszolgáló konfigurációjának újratöltése után és egy ügyfél újracsatlakozása után, mert a belső továbbítás és a pool-kiosztások futásidejű állapotok. Ellenőrizd a számlálókat mindkét irányban, mivel az egyik irányra illeszkedő, de a válaszra nem illeszkedő szabály részleges elkülönítést hoz létre, amelyet gyors tesztben nehéz észrevenni.

Az elkülönítés a megfigyelt eredmény azon a határon, amely valóban hordozza a folyamot. Egy DROP-szabály valahol a gazdagépben nem bizonyíték; egy meghiúsult kapcsolat és az azt okozó szabály elmozdult számlálója az.