Miért adja hozzá a VPN-tűzfal horog ugyanazt a szabályt kétszer

A horog elsőre működik, és három újracsatlakozás után a lánc ugyanannak a szabálynak három példányát tartalmazza. Semmi sem vallott kudarcot hangosan; a szkript minden futáskor egyszerűen azt tette, amit mondtak neki. A VPN-horog olyan konfigurációs művelet, amely többször is lefuthat, ezért tulajdonosra, kívánt állapotra és sorosított változtatásra van szüksége. Kövesd ezt a sorrendet, és a duplikátumok megszűnnek.

Adj tulajdonost a szabályoknak, mielőtt bármelyiket megírod

Döntsd el, melyik lánc vagy tábla tartozik ehhez az integrációhoz, mielőtt egyetlen szabályt megírnál. Az a saját lánc, amelyet a horog létrehoz és ürít, a tulajdonlás legvilágosabb formája, mert a tisztítás aztán eltávolíthatja ezt a láncot anélkül, hogy bárki más szabályzatához nyúlna. Ha mégis megosztott lánchoz kell szabályokat adnod, jelöld meg őket megjegyzéssel, hogy egy későbbi keresés pontosan a tieidet találja meg. A tulajdonlás teszi biztonságossá a bontást, a bontás pedig az a rész, amely csendben meghiúsul.

iptables -N VPN_HOOK 2>/dev/null || true
iptables -C INPUT -j VPN_HOOK 2>/dev/null || iptables -I INPUT -j VPN_HOOK
iptables -S VPN_HOOK

A megjegyzés itt nem díszítés. Ez a különbség a saját szabályod eltávolítása és egy véletlenül hasonlónak tűnő szabály eltávolítása között, és megmarad a mentett szabálykészletben. Írd meg a megjegyzést egyszer egy változóba, és használd ugyanazt a karakterláncot minden parancsban, amely hozzáad, tesztel vagy töröl.

A kívánt állapotot teszteld ahelyett, hogy újra hozzáadnád

Írd le, minek kell léteznie, amíg az alagút fent van: mely interfészek, mely forrás és cél, mely protokoll és mely port. Ezután fejezd ki minden szabályt tesztként, amelyet beszúrás követ, hogy egy második futás megtalálja a szabályt, és ne tegyen semmit. Az ellenőrző parancs nullával lép ki, ha a szabály létezik, és pontosan ez az a jel, amelyre a szkriptnek szüksége van. Az iptables-referencia dokumentálja az itt használt ellenőrzési, hozzáfűzési és beszúrási formákat.

iptables -C VPN_HOOK -i tun0 -p tcp --dport 443 -j ACCEPT ||
  iptables -A VPN_HOOK -i tun0 -p tcp --dport 443 -j ACCEPT

Légy óvatos a pozícióval. Egy szabály ellenőrzése és a lista élére szúrása egy korábban elöl álló szándékos elutasítás elé mozdíthat egy engedélyt, így a második futás megváltoztatja a viselkedést, pedig semmit nem ad hozzá. A saját láncodon belül a végére fűzz, és a sorrendet azzal szabályozd, hol van az ugrás ebbe a láncba. Ha a láncon belüli sorrend számít, egy ismert listából építsd újra a láncot, ahelyett hogy szabályonként foltoznád.

Állj meg, ha a szükséges szabály nem fejezhető ki stabil tesztként. Ez általában azt jelenti, hogy a kívánt állapot még homályos.

Sorosítsd a változtatást ahelyett, hogy bízol a megmaradásában

Két horoghívás átfedheti egymást, és mindkettő láthat egy hiányzó szabályt, mielőtt bármelyik hozzáadná. Az xtables várakozási opciója arra készteti a parancsot, hogy várjon a zárra, de nem teszi két parancson át atomivá az ellenőrizd-majd-add hozzá sorozatot. Sorosítsd az egész műveletet a saját záraddal, vagy használj olyan kezelőt, amely egy deklarált köteget egyetlen tranzakcióként alkalmaz. Az nftables tudja az utóbbit, ami az egyik ok, hogy előnyben részesítsd azokon a gazdagépeken, ahol elérhető.

flock /run/vpn-hook.lock /usr/local/sbin/vpn-firewall-apply
nft -f /etc/nftables/vpn-hook.nft

Bármelyik mechanizmust választod is, tartsd rövidnek a kritikus szakaszt, és tedd újrabeléphetővé: a félúton meghiúsuló horgot biztonságosnak kell lennie újra futtatni. Naplózd az eredményt, hogy az ismételt futás látható legyen a naplóban, ne szabályszámból kelljen kikövetkeztetni. Ha két különböző felügyelő hívhatja a horgot, először azt javítsd; egyetlen zár sem javít meg két tulajdonost.

Csak azt bontsd le, ami a tiéd

A bontásnak meg kell különböztetnie a helyettesítő kapcsolatot attól, amelyet nyugdíjazott, és túl kell élnie egy olyan eseményt, amely soha nem kap szabályos tisztítást. Ugyanazokkal az azonosítókkal törölj, amelyeket a hozzáadáshoz használtál, és soha ne üríts ki megosztott láncot a tisztítás egyszerűsítése érdekében. Kemény leállás után a következő indításkor futtass egyeztetési kört, ahelyett hogy feltételeznéd, hogy a lehúzó horog lefutott.

iptables -D VPN_HOOK -i tun0 -p tcp --dport 443 -j ACCEPT
iptables -F VPN_HOOK
ip -brief link show type tun

Az interfész élettartama is a tervezés része. Az újracsatlakozás más nevű eszközt hozhat létre, így a második alagút nevét keményen kódoló szabály elavul, miközben még érvényesnek látszik. Részesítsd előnyben azt az identitást, amelyet maga a kapcsolat tár fel, és minden futáskor olvasd újra. Teszteld a három eseményt külön: ismételt kapcsolódás, helyettesítő kapcsolódás és leállítás. Az engedélyezett forgalomnak mindhármat túl kell élnie duplikátumok nélkül, a nem kapcsolódó szolgáltatásoknak pedig érintetlennek kell maradniuk.

A bejárás akkor ér véget, amikor a horognak van tulajdonosa, tesztje minden hozzáadott szabályra, egy sorosított útvonala és olyan bontása, amely csak a saját állapotát távolítja el. Egy horog, amelyet biztonságos kétszer futtatni, többet ér, mint egy horog, amely egyszer okos.