Az IPv6 blokkolása a WireGuard védelmében tönkreteszi a gazdagépet

A cél ésszerű: csak az alagút felhasználói érhessék el a gépen futó szolgáltatásokat. A megoldás, amelyhez nyúlnak, egy IPv6 bemeneti lánc, amely mindent eldob a WireGuardon kívül, és ezzel eldobja a forgalmat is, amely a gazdagépet a saját kapcsolatán tartja. A szomszéd-felderítés és az útvonal-karbantartó üzenetek nem szolgáltatás-hozzáférés, és eltávolításuk olyan gépet eredményez, amely a szabályzatától független okokból elérhetetlen. Az alagút feljön, a szolgáltatások helyesen korlátozottak, és a kapcsolaton semmi más nem működik.

Három felelősség, egy szabálykészlet

Az első felelősség a külső hálózat működtetése: a gazdagépnek a kapcsolatán kell maradnia, fel kell oldania a szomszédokat, és ismernie kell a kapcsolat útvonalhatárait. A második a titkosított figyelő, amely a kiválasztott címen és porton fogad UDP-t. A harmadik a visszafejtett szolgáltatások halmaza, amelyeket az alagút felhasználóinak el kell érniük.

Ez három különböző szabályzat, és csak a második és a harmadik szól a VPN-ről. Az a szabálykészlet, amely egyként kezeli őket, olyan hibaüzemmódot örököl, amelyben az alkalmazáskorlát szigorítása csendben megtöri a gazdagép csatlakozását.

Tartsa őket külön láncokban vagy legalább külön megjegyzésekben, hogy a következő ember lássa, melyik sor miért létezik.

Mit tesz az ICMPv6 a gazdagépért

Az IPv6 sokkal többre támaszkodik az ICMPv6-ra, mint az echo. A szomszédkérés és -hirdetés helyettesíti az ARP-t, és a helyi kézbesítéshez szükséges. A Packet Too Big az útvonal MTU-információját hordozza, és figyelmen kívül hagyása olyan átviteleket okoz, amelyek nagy csomagoknál elakadnak. Az útvonalfelhirdetések az alapértelmezett útvonalat és az előtag-információt hordozzák, amikor a kapcsolat automatikus konfigurációt használ.

Az RFC 4890 elválasztja azokat az üzeneteket, amelyeket a gazdagép-szűrőnek engedélyeznie kell, azoktól, amelyek adminisztratív döntés, és ezt a gazdagépre vonatkozó szakaszban teszi, amely eltér a hálózatok között továbbító útválasztó szabályaitól. Ha csak a továbbítási szakaszt olvassa, olyan bemeneti szabályzatot kap, amely a védett gazdagéphez túl szigorú.

A gyakorlati szabály az, hogy a lényeges hiba- és konfigurációs üzeneteket a szükséges interfészen engedélyezze, típus és forrás szerint korlátozva ahol a platform engedi, a többi részről pedig kifejezetten döntsön.

Mindezt egy általános ICMPv6-engedéllyel helyettesíteni megoldja az elérhetőségi problémát, és feladja a szűrést. Egy általános eldobással helyettesíteni megoldja a szűrési problémát, és feladja a gazdagépet.

Előbb engedjük be az alagutat, aztán a szolgáltatást

Fogadja el a WireGuard forgalmát a szándékolt külső címen és UDP-porton, a visszatérő forgalmat pedig kapcsolatkövetéssel. Utána engedje át az alkalmazásszolgáltatásokat az alagút interfészén, azokról a forrásokról, amelyeket valóban engedélyez.

A külső UDP-port engedélye nem engedélyezi a benne lévő visszafejtett kéréseket. Ez a különbség a teljes oka annak, hogy az alagút interfésze megjelenik a szolgáltatási szabályokban.

A szabálykészletet úgy olvassa, ahogy van, nem ahogy a fájl leírja:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

A fizikai címen figyelő külön kitettség ugyanahhoz a szolgáltatáshoz az alagút címén. Ha a gép más gépre is továbbít forgalmat, az továbbítási lánc döntése, nem ez a bemeneti szabályzat, és saját indoklást igényel.

A kapcsolatot tesztelje, ne csak az alagutat

A változtatás után működő alagút kevesebbet bizonyít, mint látszik, mert egy meglévő szomszédbejegyzés és egy felépült kapcsolat elrejthet egy vezérlőüzenetet, amelyet a szabályzat most eldob.

Ellenőrizze a csatlakozást közvetlenül, majd ellenőrizze, hogy a kizárt útvonal továbbra is meghiúsul:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Az újraindítás után is teljes szomszédtábla azt jelzi, hogy a felderítés még működik. A kiürülő és soha újra meg nem telő tábla azt jelzi, hogy kiszűrte. A harmadik parancs a szabálykészlet szintaxisát ellenőrzi alkalmazás nélkül, amit érdemes megtenni, amíg még van munkamenete.

Állítson helyre egy gazdagépet, amelyből kizárta magát

Mielőtt megváltoztatná azokat a tűzfalszabályokat, amelyek a saját adminisztrációs munkamenetét hordozzák, tartson második csatornát: konzolt, soros kapcsolatot vagy ütemezett visszaállítást, amely eltávolítja az új szabályokat, ha nem mondja le.

Ha a változtatás mégis kizárja, a helyreállítás azon a csatornán át megy, nem azon a hálózaton, amelyet épp eltávolított. Állítsa vissza az előző szabálykészletet mentett példányból, erősítse meg, hogy a gazdagép újra elérhető, és csak ezután alkalmazza a szándékolt szabályzatot kisebb darabokban.

A végső szabályzat nem univerzális. A címzés, az útválasztás és a tűzfal megvalósítása telepítési bemenet, de a határ mindenhol ugyanaz: tagadja meg a nem szándékolt alkalmazás-hozzáférést, miközben megtartja a vezérlőforgalmat, amely az engedélyezett alagutat hordozza.