Leállító szkript vagy tűzfal-szabály: melyik állítja meg a szivárgást?

Két megoldás ugyanazt ígéri: amikor az alagút elesik, semmi nem jut ki nyílt formában. Az egyik szkriptet futtat a bontáskor, és elvágja az interfészeket. A másik hatályban hagy egy tűzfal-szabályt, és semmit sem kér a VPN-kliensől. Abban különböznek, kinek van jogosultsága cselekedni, mi történik a rés alatt, és hogyan kerül a gép utána vissza a hálózatra. Ezen a három ponton összevetni őket hasznosabb, mint arról vitatkozni, melyik szigorúbb.

Ugyanaz a feladat két mechanizmuson át

A kliens horgokat futtathat, amikor az alagút feljön és amikor lebontják, feltéve hogy a profil engedélyezi a szkriptfuttatást. Az a horog a kliens életciklusán belül fut, abban a pillanatban, amikor a kapcsolat zárul. A tűzfal-szabály ezzel szemben a rendszer tulajdona, és nem érdekli, hogy a kliens fut, összeomlott vagy megölték.

Ez a táblázat a teljes érv. Egy szkript, amely csak rendezett leálláskor fut, azt az esetet fedi le, ami a legkevésbé aggasztotta; a fontos eset az összeomlás vagy a hálózat eltűnése, és egyik sem ad tiszta bontást.

Mit tud és mit nem tud a bontási horog

A dokumentált minta végigmegy a hálózati interfészeken, és mindent leállít a loopback kivételével. Ha a fizikai eszköz le van állítva, semmi sem szökhet ki az alagúton kívülre, és pontosan ez a szándék.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Leállítja a helyi hálózatot is, minden szolgáltatást, amelyet a gép üzemeltet, és azt az útvonalat, amelyen a problémát megoldaná. Hordozható gépen a vezeték nélküli eszközt utána néha kézzel kell átkapcsolni, így egy rövid kiesés javítási munkamenetté válik. Ráadásul lehet, hogy a horgonak mindezt nem is engedik meg: amikor a kliens lemond a jogosultságairól, a bontási szkript a nem privilegizált fiókkal fut, és minden interfész-változtatás engedélyhibával bukik el, amely abban a pillanatban íródik, amikor senki sem olvassa a naplót.

Ellenőrizze, hogyan indul a kliens, mielőtt megbízik a horogban. Egy szkript, amely kézi root futtatáskor működik, semmit sem bizonyít az indításkor elinduló szolgáltatásról.

Mit tesz másként a tűzfal-szabály

Az a szabály, amely csak az alagút forgalmát engedi, akkor is működik, amikor a kliens folyamata eltűnt, mert a kernel nem függ attól a folyamattól. A szabály szűkebb is: pontosan azokat a folyamokat blokkolja, amelyekre illik, és békén hagyja a loopbacket, a helyi alhálózatot és a helyreállítási útvonalat, ezért nem hagyja elakadva a gépet.

Az ár az, hogy a szabályt annak kell megírnia és karbantartania, aki a gazdagép tűzfalát birtokolja, és meg kell neveznie az alagút-eszközt, amelyet a kliens valóban létrehoz. Ez azt jelenti, hogy a szabályt és a profilt együtt kell karbantartani; egy átnevezett interfész olyan tűzfalat hagy maga után, amely mindent blokkol és semmit nem magyaráz.

Egyik mechanizmus sem teszi feleslegessé a másikat. Az a tűzfal-szabály, amelyet szerkesztés után soha nem töltenek újra, ugyanolyan fiktív, mint egy szkript, amely soha nem fut.

A persist-tun dönti el, van-e rés

Amikor az alagút-eszköz túléli a bontást, a rá mutató útvonalak is túlélik. A forgalom ilyenkor eldobódik ahelyett, hogy átirányítanák, így az alapértelmezett útvonal nem esik vissza a fizikai átjáróra. Ez az a viselkedés, amely már bármilyen tűzfal-szabály előtt valószínűtlenné teszi a szivárgást.

E beállítás nélkül az eszköz és vele az útvonalak eltávolítódnak, és az alapértelmezett útvonal újra a fizikai átjáróra mutathat. Hogy megteszi-e, a platformtól és a klienstől függ, és éppen ezért kell az állapotot megfigyelni, nem feltételezni. Tekintse a beállítást a kill switch részének, nem teljesítményopciónak.

Tartsa életben az újracsatlakozás útvonalát, majd teszteljen négy állapotot

Szigorú blokk megakadályozhatja a kliens újracsatlakozását is, mert a kliensnek továbbra is kell egy útvonal a kiszolgálóhoz a fizikai átjárón át, miközben minden más elutasításra kerül. Telepítsen gazdagép-útvonalat arra az egy címre, mielőtt az alagút feljön, és előbb oldja fel a nevet, mert a DNS addigra blokkolva lehet, mire szüksége lesz rá.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Aztán az állapotokat ellenőrizze, ne a címkét. Gyakoroljon be szándékosan négy pillanatot: hideg indítás alagút nélkül, egészséges munkamenet, senki által nem kért kiesés, és a munkamenet a helyreállás után. Minden pillanatban olvassa ki az alapértelmezett útvonalat, és indítson egy kérést, amelynek kilépési címe látható. Egy alkalmazás, amely feladja, amíg az alagút le van állítva, semmit sem mond egy levelező kliensről vagy egy frissítőről, ezért ismételje meg az utolsó ellenőrzést egy háttéralkalmazással. Írja le a szabályt, az interfészek nevét és a helyreállítás lépéseit, mert az a kill switch, amelyet senki sem tud ellenőrizni, csak pletyka.