Down-skrip of firewall-reël: watter een stop die lek?

Twee ontwerpe belowe dieselfde ding: wanneer die tonnel val, verlaat niks die netwerk onversleutel. Die een loop ’n skrip by die aftakeling en sny koppelvlakke af. Die ander laat ’n firewall-reël van krag en vra die VPN-kliënt vir niks. Hulle verskil in wie die voorreg het om op te tree, in wat tydens die gaping gebeur, en in hoe die masjien daarna weer aanlyn kom. Om hulle op daardie drie punte te vergelyk is nuttiger as om te redeneer oor wie strenger is.

Dieselfde werk deur twee meganismes

Die kliënt kan hake loop wanneer die tonnel opkom en wanneer dit afgetakel word, mits die profiel skripuitvoering toelaat. Daardie haak loop binne die kliënt se lewensiklus, op die oomblik dat die verbinding sluit. ’n Firewall-reël, daarenteen, word deur die stelsel besit en gee nie om of die kliënt loop, omgeval het of doodgemaak is nie.

Daardie tabel is die hele argument. ’n Skrip wat net op ’n ordentlike afsluiting loop, dek die geval waaroor jy jou die minste bekommer het; die geval wat saak maak is die ineenstorting of die netwerk wat verdwyn, en nie een lewer ’n skoon aftakeling nie.

Wat die aftakelingshaak kan doen en wat nie

Die gedokumenteerde patroon loop deur die netwerkkoppelvlakke en skakel alles behalwe loopback af. Met die fisiese toestel af kan niks buite die tonnel ontsnap nie, wat presies die bedoeling is.

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

Dit skakel ook die plaaslike netwerk af, enige diens wat die masjien huisves, en die pad wat jy sou gebruik om die probleem reg te maak. Op ’n skootrekenaar moet die draadlose toestel soms daarna met die hand omgeskakel word, so ’n kort onderbreking word ’n herstelsessie. Erger nog, die haak mag dalk nie toegelaat word om enigiets daarvan te doen nie: wanneer die kliënt voorregte laat vaar, loop die aftakelingskrip as die ongeprivilegieerde rekening, en elke koppelvlakverandering misluk met ’n toestemmingsfout wat geskryf word op die oomblik dat niemand die log lees nie.

Kyk hoe die kliënt begin word voordat jy die haak vertrou. ’n Skrip wat werk wanneer jy dit met die hand as root uitvoer, bewys niks oor die diens wat by die opstart begin nie.

Wat die firewall-reël anders doen

’n Reël wat net tonnelverkeer toelaat, bly werk wanneer die kliëntproses weg is, want die kernel is nie afhanklik van daardie proses nie. Die reël is ook smaller: dit blokkeer presies die strome wat dit pas en laat loopback, die plaaslike subnet en die herstelpad alleen, wat is hoekom dit nie die masjien gestrand laat nie.

Die ruil is dat die reël geskryf en volgehou moet word deur wie ook al die gasheer-firewall besit, en dit moet die tonneltoestel benoem wat die kliënt werklik skep. Dit beteken die reël en die profiel moet saam onderhou word; ’n herdoopte koppelvlak laat ’n firewall wat alles blokkeer en niks verduidelik nie.

Geen van die twee meganismes maak die ander oorbodig nie. ’n Firewall-reël wat nooit herlaai word ná ’n wysiging nie, is net so fiktief soos ’n skrip wat nooit loop nie.

persist-tun bepaal of daar ’n gaping is

Wanneer die tonneltoestel ’n ontkoppeling oorleef, oorleef die roetes wat daarin wys ook. Verkeer word dan laat val eerder as herlei, so die verstekroete val nie terug na die fisiese gateway nie. Dit is die gedrag wat ’n lek onwaarskynlik maak selfs voordat enige firewall-reël betrokke is.

Sonder daardie instelling word die toestel verwyder en die roetes saam daarmee, en die verstekroete kan terug na die fisiese gateway oplos. Of dit gebeur hang van die platform en die kliënt af, wat juis is hoekom die toestand waargeneem moet word eerder as aangeneem. Behandel die instelling as deel van die kill switch, nie as ’n werkverrigtingopsie nie.

Hou die herverbindingspad lewendig en toets dan vier toestande

’n Streng blok kan ook verhoed dat die kliënt weer verbind, want die kliënt het steeds ’n roete na die bediener deur die fisiese gateway nodig terwyl alles anders geweier word. Installeer ’n gasheerroete vir daardie een adres voordat die tonnel opkom, en los die naam eerste op, want DNS kan geblokkeer wees teen die tyd dat jy dit nodig het.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Verifieer dan die toestande eerder as die etiket. Oefen vier oomblikke doelbewus: ’n koue begin sonder tonnel, ’n gesonde sessie, ’n onderbreking wat niemand aangevra het nie, en die sessie nadat dit herstel. Lees op elke oomblik die verstekroete en maak een versoek waarvan die uitgangsadres sigbaar is. ’n Toepassing wat moed opgee terwyl die tonnel af is, sê niks oor ’n e-poskliënt of ’n opdateringsprogram nie, so herhaal die laaste kontrole met een agtergrondtoepassing. Skryf die reël, die koppelvlakname en die herstelstappe neer, want ’n kill switch wat niemand kan verifieer nie, is ’n gerug.