Malŝalta skripto aŭ fajroŝirma regulo: kio haltigas la likon?

Du dezajnoj promesas la saman aferon: kiam la tunelo falas, nenio eliras malferme. Unu ruligas skripton ĉe malŝalto kaj tranĉas interfacojn. La alia lasas fajroŝirman regulon en valido kaj petas nenion de la VPN-kliento. Ili diferencas en tio, kiu havas la privilegion agi, kio okazas dum la breĉo, kaj kiel la maŝino revenas enrete poste. Kompari ilin laŭ tiuj tri punktoj estas pli utila ol disputi, kiu estas pli severa.

La sama tasko per du mekanismoj

La kliento povas ruli hokojn kiam la tunelo leviĝas kaj kiam ĝi malŝaltiĝas, se la profilo permesas skriptan plenumon. Tiu hoko kuras ene de la vivociklo de la kliento, en la momento kiam la konekto fermiĝas. Fajroŝirma regulo, kontraste, apartenas al la sistemo kaj ne zorgas, ĉu la kliento funkcias, kraŝis aŭ estis mortigita.

Tiu tabelo estas la tuta argumento. Skripto, kiu kuras nur ĉe ordema fermo, kovras la kazon pri kiu vi malplej maltrankviliĝis; la grava kazo estas la kraŝo aŭ la malaperanta reto, kaj neniu el ili produktas puran malŝalton.

Kion la malŝalta hoko povas kaj kion ne

La dokumentita ŝablono trairas la retajn interfacojn kaj mallevas ĉion krom loopback. Kun la fizika aparato mallevita, nenio povas eskapi ekster la tunelon, kio estas ĝuste la intenco.

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

Ĝi ankaŭ mallevas la lokan reton, ĉiun servon kiun la maŝino gastigas, kaj la vojon kiun vi uzus por ripari la problemon. Sur tekkomputilo la sendrata aparato foje bezonas manan ŝaltadon poste, do mallonga paneo fariĝas riparsesio. Pli malbone, la hoko eble tute ne rajtas fari ion el tio: kiam la kliento rezignas privilegiojn, la malŝalta skripto kuras sub la neprivilegia konto, kaj ĉiu interfaca ŝanĝo malsukcesas per permesa eraro skribita en la momento kiam neniu legas la protokolon.

Kontrolu kiel la kliento estas lanĉata antaŭ ol fidi la hokon. Skripto kiu funkcias kiam vi rulas ĝin mane kiel root pruvas nenion pri la servo kiu startas ĉe la praŝargo.

Kion la fajroŝirma regulo faras alie

Regulo kiu permesas nur tunelan trafikon daŭre funkcias kiam la klienta procezo malaperis, ĉar la kerno ne dependas de tiu procezo. La regulo ankaŭ estas pli mallarĝa: ĝi blokas ĝuste la fluojn kiujn ĝi kongruas kaj lasas loopback, la lokan subreton kaj la restarigan vojon trankvile, tial ĝi ne izolas la maŝinon.

La kosto estas, ke la regulon devas skribi kaj prizorgi tiu, kiu posedas la gastigan fajroŝirmilon, kaj ĝi devas nomigi la tunelan aparaton kiun la kliento efektive kreas. Tio signifas, ke la regulo kaj la profilo devas esti prizorgataj kune; alinomita interfaco lasas fajroŝirmilon kiu blokas ĉion kaj klarigas nenion.

Neniu mekanismo faras la alian superflua. Fajroŝirma regulo kiu neniam estas reŝargita post redakto estas same fikcia kiel skripto kiu neniam kuras.

persist-tun decidas ĉu breĉo ekzistas

Kiam la tunela aparato postvivas malkonekton, la vojoj kiuj montras en ĝin ankaŭ postvivas. La trafiko tiam estas forĵetata anstataŭ redirektata, do la defaŭlta vojo ne falas reen al la fizika enirejo. Tiu konduto igas likon neverŝajna eĉ antaŭ ol iu fajroŝirma regulo eniras la ludon.

Sen tiu agordo la aparato estas forigita kune kun la vojoj, kaj la defaŭlta vojo povas denove montri al la fizika enirejo. Ĉu ĝi faros tion dependas de la platformo kaj la kliento, kaj ĝuste tial la stato devas esti observata anstataŭ supozata. Traktu la agordon kiel parton de la kill switch, ne kiel agadan opcion.

Tenu la rekonektan vojon viva, poste testu kvar statojn

Severa blokado ankaŭ povas malhelpi la klienton rekonekti, ĉar la kliento ankoraŭ bezonas vojon al la servilo tra la fizika enirejo dum ĉio alia estas rifuzata. Instalu gastigan vojon por tiu unu adreso antaŭ ol la tunelo leviĝas, kaj unue solvu la nomon, ĉar DNS povas esti blokita ĝis la momento kiam vi bezonos ĝin.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Poste kontrolu la statojn anstataŭ la etikedon. Praktiku kvar momentojn intence: malvarma starto sen tunelo, sana sesio, falo kiun neniu petis, kaj la sesio post kiam ĝi resaniĝas. En ĉiu momento legu la defaŭltan vojon kaj faru unu peton kies elira adreso estas videbla. Aplikaĵo kiu rezignas dum la tunelo estas malsupre diras nenion pri retpoŝta kliento aŭ ĝisdatigilo, do ripetu la lastan kontrolon kun unu fona aplikaĵo. Skribu la regulon, la interfacajn nomojn kaj la restarigajn paŝojn, ĉar kill switch kiun neniu povas kontroli estas onidiro.