Nebula világítótorony-szűrők kontra tűzfal: mit blokkol melyik

Nézze meg a Nebula kézfogását a rossz végéről, és a két mechanizmus felcserélhetőnek tűnik. Az egyik eldönti, mely címeket jelenti be a csomópont a világítótoronynak, és mely távoli címeket fog megpróbálni; a másik eldönti, mi haladhat át, ha az alagút már létezik. Egy szűrő megállíthat egy kapcsolatot, mielőtt bármely tűzfalszabály kiértékelődne, és egy tűzfalszabály nem tudja újraéleszteni azt a végpontot, amelyet a felderítés eltávolított. A két réteg más kérdésekre válaszol, és a működési sorrendjük a kulcs.

Kövessen végig egy kapcsolatot négy szakaszon: a bejelentett helyi cím, a vizsgált távoli végpont, a kézfogás és az overlay forgalom. Minden szakasznak megvan a maga konfigurációja és a maga hiba-aláírása.

Kezdje a helyi címmel, amelyet a csomópont bejelent

local_allow_list kiszűri ennek a gazdagépnek a helyi címeit, mielőtt azokat a világítótornyoknak jelentik. A bejegyzések lehetnek címtartományok, és a konfiguráció az interfésznév-mintákat is támogatja. Ez akkor hasznos, ha a gazdagépnek konténerhídjai vagy további alagút-interfészei vannak, amelyekből nem szabad társ-végpontokat csinálni.

Járja végig a gazdagép interfészeit, és kérdezze meg, melyeket érhet el valóban egy távoli társ. Egy Docker-híd címe helyi az adott gazdagéphez, és haszontalan egy másik hálózatban lévő társnak. A bejelentése elpazarolja a felderítést, és olyan cím felé küldhet egy társat, amely soha nem válaszol. Minden, ahová egy társ nem tud útvonalat adni, zaj a világítótorony válaszában.

Egy szűk engedélyezési lista itt biztonságosabb, mint egy széles tiltási lista. Ha csak engedélyezési bejegyzések vannak, a meg nem adott rész kimarad; egy tiltási bejegyzés későbbi hozzáadása megváltoztatja az alapértelmezett logikát, és saját felülvizsgálatot igényel. Ez a változás megérdemel egy második pillantást az alapértelmezésre.

Ezután figyelje a távoli végpont kiválasztását

remote_allow_list kiszűri azokat a címeket, amelyeket ez a gazdagép egy távoli társ számára figyelembe vesz a kézfogás alatt. Az alapul szolgáló hálózat címére vonatkozik, nem arra az overlay-címre, amelyet a társ az alagút felállása után használni fog.

Egy privát tartomány tökéletesen használható lehet egy közös irodai hálózaton, és értelmetlen, ha a két gazdagép olyan független hálózatokban van, amelyek mindkettő a 10.0.0.0/8-at használja. A szűrő lehetővé teszi, hogy előnyben részesítse az útvonalazható utat, és figyelmen kívül hagyja a véletlent.

Ha egy társ nem tud csatlakozni, hasonlítsa össze a próbált címet a hozzá illeszkedő szabállyal. Kapcsolja be a kézfogási naplókat, és olvassa ki a kiválasztott távoli címet; a naplósor megnevezi a szűrést túlélő végpontot, ami hasznosabb, mint a társ birtokában lévő címek listája.

Egy interfésznév-szűrő a bejelentő oldalon eltávolíthatja a végpontot, mielőtt a fogadó oldal egyáltalán látná. Ellenőrizze mindkét csomópontot, ha csak egy irány hibásodik meg.

A kézfogás után az overlay hozzáférési szabályai érvényesek

A Nebula tűzfalszabályai az overlay belsejében működnek, az alagút létrejötte után. Gazdagépeket, csoportokat, portokat és protokollokat illesztenek, és eldöntik, hogy egy csomag beléphet-e a helyi gazdagépre vagy elhagyhatja-e azt. Nem választanak ki végpontot az alapul szolgáló hálózatban.

Ez a szétválasztás magyaráz egy gyakori téves diagnózist. Egy üzemeltető tűzfalszabályt ad hozzá egy portra, és mégsem tud csatlakozni, mert a világítótorony-szűrő eltávolította az egyetlen elérhető végpontot. Egy másik üzemeltető megnyitja a cím-szűrőt, és mégsem éri el a szolgáltatást, mert az overlay tűzfala elutasítja a portot.

A hibát a megfelelő rétegen olvassa. Egy soha be nem fejeződő kézfogás a felderítésre, a végpontszűrésre vagy a hálózati útvonalra mutat. Egy befejezett kézfogás, amelyet elutasított vagy eldobott szolgáltatás-kapcsolat követ, az overlay tűzfalára vagy az alkalmazásra mutat.

Olvassa az alapértelmezést, amikor engedélyt és tiltást kever

A világítótorony konfigurációja támogatja a csak engedélyező, csak tiltó és vegyes listákat, és a meg nem adott rész alapértelmezése eltér ezek között a formák között. Egy vegyes listának kifejezett alapértelmezésre van szüksége a címcsaládhoz; azt feltételezni, hogy a fennmaradó rész úgy viselkedik, mint az előző konfiguráció, az az út, amelyen egy működő végpont csendesen eltűnik.

lighthouse:
  local_allow_list:
    interfaces:
      docker0: false
  remote_allow_list:
    192.168.0.0/16: true
    default: false

Kezelje az alapértelmezést a szabály részeként, nem sablonszövegként. Ha a család alapértelmezése tiltás, minden fel nem sorolt cím kimarad, beleértve egy új irodai tartományt is, amelyet a konfiguráció megírása után adtak hozzá.

Jegyezze fel, mely címeknek kellett elérhetőnek lenniük, és tesztelje mindkét oldalról. Egy szűrő, amely egy társ-párnál működik, meghiúsulhat egy másik párnál, amelynek egyetlen közös útja olyan címet használ, amelyet a lista kizár.

Használjon relayt, ha egyetlen közvetlen végpont sem érhető el

Ha minden jelölt végpont kiszűrődik vagy elérhetetlen, a válasz nem egy szélesebb engedélyezési lista, amely újra beengedi azokat a címeket, amelyekben nem bízik. A Nebula relay-konfigurációja alternatív társ-útvonalat biztosít, ha a közvetlen kapcsolat nem megvalósítható.

A relay a szállítást és a felderítést oldja meg, nem az engedélyezést, és nem szélesíti a tűzfalat. Az overlay tűzfala továbbra is eldönti, mely szolgáltatások használhatók, és a relay nem teszi a világítótorony-szűrést hozzáférés-vezérlési mechanizmussá.

Tesztelje a relay útvonalat a közvetlen végpontok kikapcsolásával, és erősítse meg, hogy a szándékolt szolgáltatás továbbra is működik, egy nem szándékolt pedig nem. Az az egyetlen teszt elválasztja a szállítási javítást a szabályzatváltozástól, és becsületben tartja a két réteget.