Sammutusskripti vai palomuurisääntö: kumpi pysäyttää vuodon?

Kaksi rakennetta lupaa saman: kun tunneli kaatuu, mitään ei poistu selväkielisenä. Toinen ajaa skriptin purussa ja katkaisee liitännät. Toinen jättää palomuurisäännön voimaan eikä pyydä VPN-asiakkaalta mitään. Ne eroavat siinä, kenellä on oikeus toimia, mitä aukon aikana tapahtuu ja miten kone palaa sen jälkeen verkkoon. Niiden vertaaminen näillä kolmella kohdalla on hyödyllisempää kuin kiistely siitä, kumpi on tiukempi.

Sama työ kahdella mekanismilla

Asiakas voi ajaa koukkuja, kun tunneli nousee ja kun se puretaan, jos profiili sallii skriptien suorittamisen. Tämä koukku ajetaan asiakkaan elinkaaren sisällä hetkellä, jolloin yhteys sulkeutuu. Palomuurisääntö sitä vastoin kuuluu järjestelmälle eikä välitä siitä, onko asiakas käynnissä, kaatunut vai tapettu.

Tuo taulukko on koko argumentti. Skripti, joka ajetaan vain siistissä sulkemisessa, kattaa tapauksen, josta olit vähiten huolissasi; tärkeä tapaus on kaatuminen tai verkon katoaminen, eikä kumpikaan tuota puhdasta purkua.

Mitä purkukoukku voi tehdä ja mitä ei

Dokumentoitu malli käy verkkoliitännät läpi ja ajaa alas kaiken paitsi loopbackin. Kun fyysinen laite on alhaalla, mikään ei voi paeta tunnelin ulkopuolelle, ja juuri se on tarkoitus.

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

Se ajaa alas myös lähiverkon, jokaisen koneen tarjoaman palvelun ja polun, jota käyttäisit ongelman korjaamiseen. Kannettavassa langaton laite tarvitsee joskus sen jälkeen manuaalisen kytkennän, joten lyhyt katkos muuttuu korjausistunnoksi. Pahempaa, koukulle ei ehkä sallita mitään tästä: kun asiakas luopuu oikeuksistaan, purkuskripti ajetaan ilman oikeuksia olevalla tilillä, ja jokainen liitännän muutos epäonnistuu käyttöoikeusvirheeseen, joka kirjoitetaan hetkellä, jolloin kukaan ei lue lokia.

Tarkista, miten asiakas käynnistetään, ennen kuin luotat koukkuun. Skripti, joka toimii käsin rootina ajettaessa, ei todista mitään palvelusta, joka käynnistyy laitteen käynnistyessä.

Mitä palomuurisääntö tekee toisin

Sääntö, joka sallii vain tunnelin liikenteen, toimii edelleen, kun asiakasprosessi on poissa, koska ydin ei riipu siitä prosessista. Sääntö on myös kapeampi: se estää täsmälleen ne virrat, joihin se sopii, ja jättää loopbackin, paikallisen aliverkon ja palautumispolun rauhaan, minkä vuoksi se ei jätä konetta pulaan.

Hinta on, että säännön täytyy kirjoittaa ja pitää yllä sen, joka omistaa isäntäkoneen palomuurin, ja sen täytyy nimetä tunnelilaite, jonka asiakas todella luo. Se tarkoittaa, että sääntöä ja profiilia on ylläpidettävä yhdessä; uudelleen nimetty liitäntä jättää palomuurin, joka estää kaiken eikä selitä mitään.

Kumpikaan mekanismi ei tee toista tarpeettomaksi. Palomuurisääntö, jota ei koskaan ladata uudelleen muokkauksen jälkeen, on yhtä kuvitteellinen kuin skripti, joka ei koskaan aja.

persist-tun ratkaisee, onko aukko olemassa

Kun tunnelilaite kestää katkoksen, myös siihen osoittavat reitit kestävät. Liikenne silloin pudotetaan sen sijaan että se ohjattaisiin uudelleen, joten oletusreitti ei putoa takaisin fyysiselle yhdyskäytävälle. Juuri tämä käyttäytyminen tekee vuodosta epätodennäköisen jo ennen kuin mikään palomuurisääntö tulee peliin.

Ilman tätä asetusta laite poistetaan ja reitit sen mukana, ja oletusreitti voi jälleen osoittaa fyysiselle yhdyskäytävälle. Se, tekeekö se niin, riippuu alustasta ja asiakkaasta, ja juuri siksi tilaa on tarkkailtava eikä oletettava. Käsittele asetusta osana kill switchiä, älä suorituskykyvalintana.

Pidä uudelleenyhdistämispolku elossa ja testaa sitten neljä tilaa

Tiukka esto voi estää asiakasta yhdistämästä uudelleen, koska asiakas tarvitsee yhä reitin palvelimelle fyysisen yhdyskäytävän kautta, kun kaikki muu hylätään. Asenna isäntäreitti tuolle yhdelle osoitteelle ennen kuin tunneli nousee, ja ratkaise nimi ensin, koska DNS voi olla estetty siihen mennessä, kun tarvitset sitä.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Tarkista sitten tilat, älä merkintää. Käy tarkoituksella läpi neljä hetkeä: kylmäkäynnistys ilman tunnelia, terve istunto, katkos jota kukaan ei pyytänyt ja istunto sen palauduttua. Lue joka hetkellä oletusreitti ja tee yksi pyyntö, jonka lähtöosoite on näkyvissä. Sovellus, joka antaa periksi tunnelin ollessa alhaalla, ei kerro mitään sähköpostiohjelmasta tai päivittäjästä, joten toista viimeinen tarkistus yhdellä taustasovelluksella. Kirjoita muistiin sääntö, liitäntöjen nimet ja palautumisvaiheet, sillä kill switch, jota kukaan ei voi tarkistaa, on huhu.