Bi diseinuk gauza bera agintzen dute: tunela erortzen denean, ezer ez da kanpora irteten argi eta garbi. Batek script bat exekutatzen du jaistean eta interfazeak mozten ditu. Besteak suebakiko araua indarrean uzten du eta ez dio ezer eskatzen VPN bezeroari. Desberdinak dira nor den jarduteko pribilegioa duena, hutsunean zer gertatzen den eta makinak nola berreskuratzen duen sarea gero. Hiru puntu horietan alderatzea zorrotzagoa zein den eztabaidatzea baino erabilgarriagoa da.

Lan bera bi mekanismoren bidez

Bezeroak kakoak exekuta ditzake tunela igotzean eta jaistean, betiere profiletuko scripten exekuzioa baimenduta badago. Kako hori bezeroaren bizi-zikloaren barruan exekutatzen da, konexioa ixten den unean. Suebakiko araua, aldiz, sistemarena da eta ez zaio axola bezeroa martxan dagoen, kraskatu den edo hil den.

PropertyTeardown scriptFirewall unit
Runs when the client is killedNoYes
Needs privilege at teardown timeUsually yesConfigured once, at boot
Acts on the whole machineOften, including recovery pathsOnly on the flows it matches

Taula hori da argudio osoa. Itxiera ordenatuan bakarrik exekutatzen den script batek gutxien kezkatzen zintuen kasua estaltzen du; garrantzitsua den kasua kraskadura edo sarea desagertzea da, eta batek ere ez du jaitsiera garbirik ematen.

Zer egin dezakeen jaitsiera-kakoak eta zer ez

Dokumentatutako ereduak sareko interfazeak zeharkatzen ditu eta loopback izan ezik guztia jaisten du. Gailu fisikoa behera dagoenean, ezerk ezin du tunelatik kanpora ihes egin, eta hori da hain zuzen asmoa.

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

Sare lokala ere jaisten du, makinak ostatatzen duen edozein zerbitzu eta arazoa konpontzeko erabiliko zenukeen bidea. Eramangarrian haririk gabeko gailuak batzuetan eskuzko aldaketa behar izaten du gero, beraz etenaldi labur bat konponketa-saio bihurtzen da. Okerragoa da, agian kakoari ez zaio horrelakorik egiten uzten: bezeroak pribilegioak uzten dituenean, jaitsiera-scriptak pribilegiorik gabeko kontuarekin exekutatzen da, eta interfaze-aldaketa bakoitzak baimen-errore batekin huts egiten du inork erregistroa irakurtzen ez duen unean idatzita.

Egiaztatu nola abiarazten den bezeroa kakori fidatu aurretik. Eskuz root gisa exekutatzean funtzionatzen duen script batek ez du ezer frogatzen abiaraztean hasten den zerbitzuaz.

Zer egiten duen suebakiko arauak beste modu batera

Tunelaren trafikoa soilik baimetzen duen arauak lanean jarraitzen du bezeroaren prozesua desagertu denean, nukleoak ez baitu prozesu horren menpekotasunik. Araua estuagoa ere bada: bat datozen fluxuak blokeatzen ditu eta loopback, sare lokaleko azpisarea eta berreskuratze-bidea bakean uzten ditu, horregatik ez du makina isolatuta uzten.

Trukea da araua ostatuko suebakia duenari dagokiola idaztea eta mantentzea, eta bezeroak benetan sortzen duen tunel-gailua izendatu behar duela. Horrek esan nahi du araua eta profila elkarrekin mantendu behar direla; berrizendatutako interfaze batek dena blokeatzen duen eta ezer azaltzen ez duen suebaki bat uzten du.

Bi mekanismoetako batek ez du bestea alferrikako bihurtzen. Edizio baten ondoren inoiz berriz kargatzen ez den suebakiko araua inoiz exekutatzen ez den script bat bezain fikzioa da.

persist-tun-ek erabakitzen du hutsunerik dagoen

Tunel-gailuak deskonexioa gainditzen duenean, hara zuzentzen diren ibilbideek ere gainditzen dute. Trafikoa orduan baztertu egiten da birbideratu beharrean, beraz lehenespenezko ibilbidea ez da erortzen atzera pasabide fisikora. Jokabide horrek isuria gertagaitz egiten du edozein suebakiko arau sartu aurretik ere.

Ezarpen hori gabe gailua eta harekin batera ibilbideak kentzen dira, eta lehenespenezko ibilbidea berriro pasa daiteke pasabide fisikora. Hori egiten duen ala ez plataformaren eta bezeroaren araberakoa da, eta horregatik hain zuzen egoera behatu behar da, ez suposatu. Har ezazu ezarpena kill switch-aren zati gisa, ez errendimendu-aukeratzat.

Eutsi berrikonexio-bideari bizirik, eta gero probatu lau egoera

Blokeo zorrotzak bezeroa berriro konektatzea ere eragin dezake, bezeroak oraindik behar baitu zerbitzarirako ibilbide bat pasabide fisikoaren bidez, beste guztia ukatuta dagoen bitartean. Instalatu ostalari-ibilbide bat helbide horretarako tunela igo aurretik, eta ebatz ezazu izena lehenengo, DNS blokeatuta egon baitaiteke behar duzunerako.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Gero egiaztatu egoerak, ez etiketa. Probatu lau une nahita: hotzeko abiaraztea tunelik gabe, saio osasuntsua, inork eskatu gabeko erorketa eta berreskuratu ondorengo saioa. Une bakoitzean irakurri lehenespenezko ibilbidea eta egin irteerako helbidea ikusgai duen eskaera bat. Tunela behera dagoela amore ematen duen aplikazio batek ez du ezer esaten posta-bezero edo eguneratzaile bati buruz, beraz errepikatu azken egiaztapena atzeko planoan dagoen aplikazio batekin. Idatz itzazu araua, interfazeen izenak eta berreskuratze-urratsak, inork egiaztatu ezin duen kill switch bat zurrumurrua baita.

Erlazionatutako artikuluak