Down skripta ili firewall pravilo: šta zaustavlja curenje?

Dva dizajna obećavaju isto: kada tunel padne, ništa ne izlazi napolje u otvorenom obliku. Jedan pokreće skriptu pri rušenju i siječe interfejse. Drugi ostavlja firewall pravilo na snazi i ne traži ništa od VPN klijenta. Razlikuju se po tome ko ima privilegiju da djeluje, šta se dešava tokom praznine i kako se mašina poslije vraća na mrežu. Upoređivati ih po te tri tačke korisnije je nego raspravljati koje je strože.

Isti posao kroz dva mehanizma

Klijent može pokretati kuke kada se tunel podigne i kada se ruši, ako profil dozvoljava izvršavanje skripti. Ta kuka radi unutar klijentovog životnog ciklusa, u trenutku kada se veza zatvara. Firewall pravilo, nasuprot tome, pripada sistemu i ne zanima ga da li klijent radi, srušio se ili je ubijen.

Ta tabela je cijeli argument. Skripta koja radi samo pri urednom zatvaranju pokriva slučaj koji vas je najmanje brinuo; slučaj koji je važan je pad ili nestanak mreže, a nijedan od njih ne daje čisto rušenje.

Šta kuka za rušenje može, a šta ne može

Dokumentovani obrazac prolazi kroz mrežne interfejse i ruši sve osim loopback-a. Kada je fizički uređaj spušten, ništa ne može pobjeći izvan tunela, što je upravo namjera.

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

Ona ruši i lokalnu mrežu, svaku uslugu koju mašina hostuje i putanju koju biste koristili da popravite problem. Na laptopu bežični uređaj ponekad poslije treba ručno prebaciti, pa kratki prekid postaje sesija popravke. Gore od toga, kuki možda nije dozvoljeno da radi bilo šta od toga: kada klijent odbaci privilegije, skripta za rušenje radi pod neprivilegovanim računom i svaka promjena interfejsa pada s greškom dozvole ispisanom u trenutku kada niko ne čita dnevnik.

Provjerite kako se klijent pokreće prije nego povjerujete kuki. Skripta koja radi kada je pokrenete ručno kao root ne dokazuje ništa o servisu koji se pokreće pri podizanju.

Šta firewall pravilo radi drugačije

Pravilo koje dozvoljava samo tunelski saobraćaj nastavlja raditi kada klijentski proces nestane, jer kernel ne zavisi od tog procesa. Pravilo je i uže: blokira tačno tokove koje pokriva i ostavlja loopback, lokalnu podmrežu i putanju oporavka na miru, zato mašinu ne ostavlja bez izlaza.

Cijena je da pravilo mora napisati i održavati onaj koji posjeduje host firewall, i ono mora imenovati tunelski uređaj koji klijent zaista stvara. To znači da se pravilo i profil moraju održavati zajedno; preimenovan interfejs ostavlja firewall koji blokira sve i ne objašnjava ništa.

Nijedan mehanizam ne čini drugi suvišnim. Firewall pravilo koje se nikada ne učita ponovo poslije izmjene jednako je izmišljeno kao skripta koja nikada ne radi.

persist-tun odlučuje postoji li praznina

Kada tunelski uređaj preživi prekid, preživljavaju i rute koje pokazuju u njega. Saobraćaj se tada odbacuje umjesto preusmjerava, pa podrazumijevana ruta ne pada nazad na fizički gateway. To je ponašanje koje curenje čini malo vjerovatnim i prije nego što ikakvo firewall pravilo uđe u igru.

Bez te postavke uređaj se uklanja zajedno s rutama, a podrazumijevana ruta može ponovo pokazati na fizički gateway. Da li hoće zavisi od platforme i klijenta, i upravo zato stanje treba posmatrati, a ne pretpostavljati. Tretirajte postavku kao dio kill switch-a, ne kao opciju performansi.

Održite putanju ponovnog povezivanja živom, pa testirajte četiri stanja

Strog blok može spriječiti i ponovno povezivanje klijenta, jer klijentu i dalje treba ruta do servera kroz fizički gateway dok je sve ostalo zabranjeno. Instalirajte host rutu za tu jednu adresu prije nego se tunel podigne i prvo razriješite ime, jer DNS može biti blokiran do trenutka kada vam zatreba.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Zatim provjerite stanja, a ne oznaku. Namjerno prođite kroz četiri trenutka: hladni start bez tunela, zdrava sesija, prekid koji niko nije tražio i sesija nakon oporavka. U svakom trenutku pročitajte podrazumijevanu rutu i uputite jedan zahtjev čija je izlazna adresa vidljiva. Aplikacija koja odustane dok je tunel spušten ne govori ništa o poštanskom klijentu ili ažuriranju, pa ponovite posljednju provjeru s jednom pozadinskom aplikacijom. Zapišite pravilo, nazive interfejsa i korake oporavka, jer kill switch koji niko ne može provjeriti je glasina.