Kial VPN-firewall-hoko aldonas la saman regulon dufoje

La hoko funkcias la unuan fojon, kaj post tri rekonektoj la ĉeno enhavas tri kopiojn de la sama regulo. Nenio malsukcesis laŭte; la skripto simple faris tion, kion oni diris al ĝi ĉiufoje, kiam ĝi ruliĝis. VPN-hoko estas agordo-operacio, kiu povas ruliĝi pli ol unufoje, do ĝi bezonas posedanton, deziratan staton kaj serian ŝanĝon. Iru laŭ tiu ordo, kaj la duoblaĵoj ĉesas.

Donu posedanton al la reguloj antaŭ ol skribi iun ajn

Decidu, kiun ĉenon aŭ tabelon posedas ĉi tiu integriĝo, antaŭ ol skribi eĉ unu regulon. Dediĉita ĉeno, kiun la hoko kreas kaj malplenigas, estas la plej klara formo de posedo, ĉar purigado povas poste forigi tiun ĉenon sen tuŝi la politikon de iu ajn alia. Se vi devas aldoni regulojn al komuna ĉeno, marku ilin per komento, por ke posta serĉo trovu ĝuste viajn. Posedo estas tio, kio faras la malkonstruon sekura, kaj la malkonstruo estas la parto, kiu malsukcesas silente.

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

Komento ĉi tie ne estas ornamo. Ĝi estas la diferenco inter forigi vian regulon kaj forigi regulon, kiu hazarde aspektas simila, kaj ĝi postvivas en la konservita regularo. Skribu la komenton unufoje en variablon kaj uzu la saman ĉenon en ĉiu komando, kiu aldonas, provas aŭ forigas.

Provu la deziratan staton anstataŭ aldoni denove

Skribu, kio devus ekzisti dum la tunelo estas supren: kiuj interfacoj, kiu fonto kaj celo, kiu protokolo kaj kiu pordo. Poste esprimu ĉiun regulon kiel provon sekvatan de enmeto, por ke dua rulo trovu la regulon kaj faru nenion. La kontrola komando eliras kun nulo, kiam la regulo ekzistas, kaj tio estas ĝuste la signalo, kiun la skripto bezonas. La referenco pri iptables dokumentas la formojn de kontrolo, aldono kaj enmeto uzatajn ĉi tie.

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

Atentu la pozicion. Kontroli regulon kaj enmeti ĝin ĉe la kapo povas movi permeson antaŭ intenca malakcepto, kiu antaŭe venis unue, do la dua rulo ŝanĝas konduton eĉ se ĝi aldonas nenion. Aldonu interne de via propra ĉeno, kaj regu la ordon per la loko, kie sidas la salto al tiu ĉeno. Se la ordo interne de la ĉeno gravas, rekonstruu la ĉenon el konata listo anstataŭ fliki ĝin regulon post regulo.

Haltu, se la regulo, kiun vi bezonas, ne povas esti esprimita kiel stabila provo. Tio kutime signifas, ke la dezirata stato estas ankoraŭ malklara.

Seriigu la ŝanĝon anstataŭ esperi, ke ĝi teniĝos

Du alvokoj de la hoko povas interkovriĝi, kaj ambaŭ povas vidi forestantan regulon antaŭ ol iu ajn aldonas ĝin. La atendopcio de xtables igas komandon atendi la seruron, sed ĝi ne faras la sinsekvon kontroli-poste-aldoni atoma trans du komandoj. Seriigu la tutan operacion per via propra seruro, aŭ uzu administrilon, kiu aplikas deklaritajn taskojn kiel unu transakcion. nftables povas fari la lastan, kio estas unu kialo preferi ĝin sur gastigantoj, kie ĝi haveblas.

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

Kiun ajn mekanismon vi elektas, tenu la kritikan sekcion mallonga kaj faru ĝin reenirebla: hoko, kiu malsukcesas duonvoje, devus esti sekura por ruliĝi denove. Protokolu la rezulton, por ke ripetita rulo videblu en la ĵurnalo anstataŭ esti konkludita el nombro de reguloj. Se du malsamaj kontrolistoj povas alvoki la hokon, riparu tion unue; neniu seruro riparas du posedantojn.

Malkonstruu nur tion, kion vi posedas

Malkonstruo devas distingi anstataŭan konekton de tiu, kiun ĝi emeritigis, kaj ĝi devas postvivi eventon, kiu neniam ricevas puran purigadon. Forigu laŭ la samaj identigiloj, kiujn vi uzis por aldoni, kaj neniam malplenigu komunan ĉenon por simpligi purigadon. Post malmola halto, rulu kunordigan trairon ĉe la sekva starto anstataŭ supozi, ke la malsupren-hoko ruliĝis.

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

La vivdaŭro de la interfaco ankaŭ apartenas al la dezajno. Rekonekto povas krei aparaton kun malsama nomo, do regulo, kiu malmole kodas la nomon de la dua tunelo, malnoviĝas dum ĝi ankoraŭ aspektas valida. Preferu la identecon, kiun la konekto mem montras, kaj relegu ĝin ĉe ĉiu rulo. Provu la tri eventojn aparte: ripetita konekto, anstataŭa konekto kaj malŝalto. La permesita trafiko devus postvivi ĉiujn tri sen duoblaĵoj, kaj ne rilataj servoj devus resti netuŝitaj.

La promenado finiĝas, kiam la hoko havas posedanton, provon por ĉiu regulo, kiun ĝi aldonas, unu serian vojon kaj malkonstruon, kiu forigas nur sian propran staton. Hoko, kiu estas sekura ruliĝi dufoje, valoras pli ol hoko, kiu estas lerta unufoje.