Kill switch a routeren, amely lefedi a FORWARD, OUTPUT és IPv6 láncokat

Bejelentkezik a routerre, beilleszt egy fórumbejegyzésből származó kill switch szabálykészletet, és a LAN abban a pillanatban leáll a böngészéssel, amikor a tunnel leesik. Két nappal később a router még mindig a szokásos WAN-on keresztül frissíti a dinamikus DNS rekordját, a vendég laptop pedig még mindig eléri az IPv6-os oldalakat. Mindkét viselkedés normális, mert a beillesztett szabályok egy láncot és egy címcsaládot fedtek le, és egyik sem az egész router. A csomagútvonalak sorrend szerinti végigjárása pontosan megmutatja, mi maradt ki.

A routernél kezdje, ne a laptopnál

A router szintű szabályzat azért vonzó egy kis irodának, mert minden mögötte lévő eszköz ugyanazt a viselkedést örökli, és senki sem felejtheti el bekapcsolni egy kliens kapcsolóját. Egyetlen helyet is ad a tesztelésre minden firmware-frissítés után. Amit nem ad, az a router saját forgalmának vagy egy második címcsaládnak az automatikus lefedése, és ez a két hiányosság áll a legtöbb sikertelen telepítés mögött.

Mielőtt bármit szerkesztene, írjon fel három tényt papírra: a WAN interfész nevét, a LAN híd nevét, valamint a VPN végpont címét és portját. Mindháromra szüksége lesz a szabályokban, és az interfésznevek találgatása a leggyakoribb oka annak, hogy egy helyesnek látszó szabálykészlet semmit sem tesz.

Járja végig a három útvonalat, amelyen egy csomag haladhat

A laptopról az internetre menő forgalom továbbítódik, tehát a FORWARD láncon halad át. A router által maga generált forgalom, például a DNS-továbbítás, az NTP-lekérdezések, a DDNS-frissítések és a VPN vezérlőcsatorna, az OUTPUT-on halad át. A routernek címzett kezelési forgalom az INPUT-on érkezik.

A csak FORWARD-ban felépített kill switch tehát a klienseket védi, és semmi mást. A táblázat megmutatja, miért kiszámítható, és nem titokzatos a nyitójelenet szivárgása.

A legtöbb tervben nincs szükség kill switchre az INPUT-on, de a kezelési hozzáférést működőképesen kell tartania, amíg a tunnel le van kapcsolva. Különben az első VPN-hiba alkalmával konzolkábellel indul az irodába.

Rendezze a szabályokat, hogy a tunnel még fel tudjon jönni

Egy működő kill switch engedélylista, amely elutasítással végződik, és a sorrend teszi kill switchsé, nem téglává. Először engedélyezze a loopbacket, a VPN végpontot, a létrejött folyamatok válaszait és a tunnel interfészt; a többit utolsóként utasítsa el.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

A végpontnak ezen a ponton címnek kell lennie, nem hosztnévnek. Amint a záró elutasítás blokkolja a DNS-t, a szolgáltató hosztnevét tartalmazó szabály már nem oldható fel, és a tunnel újraindítás után soha többé nem indul el. Ha a szolgáltató végpontokat váltogat, oldja fel a nevet a szabályzat alkalmazása előtt, és frissítse azt a szabályt ugyanabból a szkriptből.

Tükrözze a formát a FORWARD-ban az ügyfélforgalomra, és helyezzen kifejezett kezelési szabályt az elutasítás fölé. Tartsa ezt a kezelési szabályt szűken, de elérhetően, és erősítse meg egy második SSH-munkamenet megnyitásával, mielőtt bezárja az elsőt. A kill switch módosítása közbeni kizárás elég gyakori ahhoz, hogy tervezzen rá. WireGuardot futtató routeren a peer allowed-ips értékei döntik el, mi lép be a tunnelbe, míg ezek a szabályok döntik el, mi hagyhatja el azt anélkül.

Az IPv6-nak saját ajtóra van szüksége

Minden fenti IPv4. Ha a LAN-jában működik az IPv6, és a tunnel csak IPv4-et szállít, minden lefedett eszköznek még mindig van közvetlen útvonala az internetre, amelyet az új szabályok soha nem látnak. Egy dual-stack laptop szívesen választaná, és a kill switch csak annak tűnik hibásnak, aki IPv4-gyel tesztel.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Itt is számít a sorrend: a loopback engedélyezésének meg kell előznie a WAN elutasítását, különben a router helyi szolgáltatásai furcsán kezdenek meghibásodni. Ha a hálózat egyáltalán nem használ IPv6-ot, egyszerűbb kikapcsolni a WAN-on és a LAN-on, és nem marad semmi, amit el lehetne felejteni.

Egyes VPN-kliensek csak IPv4-hez telepítenek alapértelmezett útvonalat, és érintetlenül hagyják a meglévő IPv6-os alapértelmezett útvonalat. A tunnel csatlakozása után ellenőrizze az útválasztási táblázatot, ahelyett hogy feltételezné, hogy a kliens elintézte.

Bizonyítsa lekapcsolt tunnellel

Állítsa le a tunnelt a routerről, és teszteljen három helyről ebben a sorrendben:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Az útvonal-keresés megmondja, hová menne egy csomag, a számlálók pedig azt, hogy a szabályai valaha egyeztek-e. Egy nulla csomagot számláló szabály egy sikertelen teszt után semmit sem véd, és a szokásos ok egy olyan interfésznév, amely eltér a beírtól. Kifejezetten tesztelje a router által generált forgalmat, mert a LAN felőli teszt nem tudja gyakorolni az OUTPUT-ot.

A meghibásodási módot még a szükség előtt döntse el. A fail-closed offline tartja a klienseket, amíg a tunnel vissza nem tér; a fail-open visszaállítja a szokásos WAN-hozzáférést, és aláássa a célt az Önnek fontos forgalom esetében. A magas metrikájú blackhole útvonal a VPN poolhoz hasznos második réteg a fail-closed tervekhez, mivel túléli, amikor a tunnel útvonala eltűnik, ahelyett hogy visszaesne az alapértelmezettre.

Csak akkor fogadja el a beállítást, ha egy LAN-kliens, egy router által generált kérés és egy IPv6-kérés mind elbukik lekapcsolt tunnellel, és mindhárom újra működik, amint feljön.