Waarom 'n VPN-firewallhaak dieselfde reël twee keer byvoeg

Die haak werk die eerste keer, en ná drie herverbindings hou die ketting drie kopieë van dieselfde reël. Niks het hardop misluk nie; die skrip het bloot elke keer gedoen wat hom gesê is. 'n VPN-haak is 'n konfigurasiebewerking wat meer as een keer kan loop, dus het dit 'n eienaar, 'n verlangde toestand en een geserialiseerde verandering nodig. Gaan in daardie volgorde te werk, en die duplikate stop.

Gee die reëls 'n eienaar voordat jy enigeen skryf

Bepaal watter ketting of tabel hierdie integrasie besit voordat jy 'n enkele reël skryf. 'n Toegewyde ketting wat die haak skep en leegmaak, is die duidelikste vorm van eienaarskap, want opruiming kan dan daardie ketting verwyder sonder om iemand anders se beleid te raak. As jy reëls by 'n gedeelde ketting moet voeg, merk hulle met 'n opmerking sodat 'n latere soektog presies joune kan vind. Eienaarskap is wat opruiming veilig maak, en opruiming is die deel wat stilweg misluk.

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

'n Opmerking is hier nie versiering nie. Dit is die verskil tussen jou reël verwyder en 'n reël verwyder wat toevallig soortgelyk lyk, en dit oorleef in die gestoorde reëlstel. Skryf die opmerking een keer in 'n veranderlike en gebruik dieselfde string in elke opdrag wat byvoeg, toets of uitvee.

Toets vir die verlangde toestand in plaas van om weer by te voeg

Skryf neer wat moet bestaan terwyl die tonnel op is: watter koppelvlakke, watter bron en bestemming, watter protokol en watter poort. Druk dan elke reël uit as 'n toets gevolg deur 'n invoeging, sodat 'n tweede loop die reël vind en niks doen nie. Die toetsopdrag eindig op nul wanneer die reël bestaan, en dit is presies die sein wat die skrip nodig het. Die iptables-verwysing dokumenteer die toets-, byvoeg- en invoegvorms wat hier gebruik word.

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

Wees versigtig oor posisie. Om 'n reël te toets en boaan in te voeg kan 'n toestaan voor 'n doelbewuste weiering skuif wat eerste gekom het, so die tweede loop verander gedrag selfs al voeg dit niks by nie. Voeg binne jou eie ketting by, en beheer ordening deur waar die sprong na daardie ketting sit. As ordening binne die ketting saak maak, bou die ketting uit 'n bekende lys oor eerder as om dit reël vir reël te lap.

Stop as die reël wat jy nodig het nie as 'n stabiele toets uitgedruk kan word nie. Dit beteken gewoonlik dat die verlangde toestand nog vaag is.

Serialiseer die verandering in plaas daarvan om te hoop dit hou

Twee aanroepende van die haak kan oorvleuel, en albei kan 'n afwesige reël sien voordat enigeen dit byvoeg. Die wagopsie van xtables laat 'n opdrag op die slot wag, maar dit maak 'n toets-dan-byvoeg-reeks nie atomies oor twee opdragte nie. Serialiseer die hele bewerking met jou eie slot, of gebruik 'n bestuurder wat 'n verklaarde bondel as een transaksie toepas. nftables kan laasgenoemde doen, wat een rede is om dit te verkies op gashere waar dit beskikbaar is.

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

Watter meganisme jy ook kies, hou die kritieke afdeling kort en maak dit herbetreebaar: 'n haak wat halfpad misluk, moet veilig wees om weer te loop. Teken die uitkoms aan sodat 'n herhaalde loop in die joernaal sigbaar is eerder as om uit 'n reëltelling afgelei te word. As twee verskillende toesighouers die haak kan aanroep, regstel dit eerste; geen slot herstel twee eienaars nie.

Breek net af wat joune is

Opruiming moet 'n vervangingsverbinding van die een wat dit afgelê het onderskei, en dit moet 'n gebeurtenis oorleef wat nooit 'n ordentlike skoonmaak kry nie. Vee uit met dieselfde identifiseerders wat jy gebruik het om by te voeg, en maak nooit 'n gedeelde ketting leeg om opruiming eenvoudig te maak nie. Nadat 'n harde stop plaasgevind het, hardloop 'n versoeningsronde by die volgende begin eerder as om aan te neem die af-haak het geloop.

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

Die leeftyd van die koppelvlak hoort ook by die ontwerp. 'n Herverbinding kan 'n toestel met 'n ander naam skep, so 'n reël wat die tweede tonnel se naam hardkodeer, word verouderd terwyl dit nog geldig lyk. Verkies die identiteit wat die verbinding self blootlê, en lees dit by elke loop weer. Toets die drie gebeurtenisse afsonderlik: 'n herhaalde verbinding, 'n vervangingsverbinding en 'n afskakeling. Die toegelate verkeer moet al drie oorleef sonder duplikate, en onverwante dienste moet onaangeraak bly.

Die deurloop eindig wanneer die haak 'n eienaar, 'n toets vir elke reël wat dit byvoeg, een geserialiseerde pad en 'n opruiming het wat net sy eie toestand verwyder. 'n Haak wat veilig is om twee keer te loop, is meer werd as 'n haak wat een keer slim is.