Skripta za spuštanje ili firewall pravilo: što zaustavlja curenje?
Spuštanje sučelja pri prekidu je grubo i često radi bez ovlasti. Usporedite to s firewall pravilom koje preživi pad i zatvara prazninu.
Dva dizajna obećavaju isto: kada tunel padne, ništa ne izlazi van u otvorenom obliku. Jedan pokreće skriptu pri spuštanju i reže sučelja. Drugi ostavlja firewall pravilo na snazi i ne traži ništa od VPN klijenta. Razlikuju se po tome tko ima ovlast djelovati, što se događa tijekom praznine i kako se računalo poslije vraća na mrežu. Usporediti ih po te tri toč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 spušta, ako profil dopušta izvršavanje skripti. Ta kuka radi unutar klijentova životnog ciklusa, u trenutku kada se veza zatvara. Firewall pravilo, nasuprot tome, pripada sustavu i ne zanima ga radi li klijent, srušio se ili je ubijen.
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
Ta tablica 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 spuštanje.
Što kuka za spuštanje može, a što ne može
Dokumentirani obrazac prolazi kroz mrežna sučelja i spušta sve osim loopbacka. 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 spušta i lokalnu mrežu, svaku uslugu koju računalo hosta i putanju koju biste upotrijebili da popravite problem. Na prijenosnom računalu bežični uređaj ponekad poslije treba ručno prebaciti, pa kratki prekid postaje sesija popravka. Gore od toga, kuki možda nije dopušteno raditi bilo što od toga: kada klijent odbaci ovlasti, skripta za spuštanje radi pod neprivilegiranim računom i svaka promjena sučelja pada s greškom dopuštenja ispisanom u trenutku kada nitko 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.
Što firewall pravilo radi drugačije
Pravilo koje dopušta samo tunelski promet nastavlja raditi kada klijentski proces nestane, jer jezgra ne zavisi od tog procesa. Pravilo je i uže: blokira točno tokove koje pokriva i ostavlja loopback, lokalnu podmrežu i putanju oporavka na miru, zato računalo 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 doista stvara. To znači da se pravilo i profil moraju održavati zajedno; preimenovano sučelje 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 ponovno nakon 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. Promet se tada odbacuje umjesto preusmjerava, pa zadana ruta ne pada natrag na fizički gateway. To je ponašanje koje curenje čini malo vjerojatnim i prije nego što ikakvo firewall pravilo uđe u igru.
Bez te postavke uređaj se uklanja zajedno s rutama, a zadana ruta može ponovno pokazati na fizički gateway. Hoće li to učiniti zavisi od platforme i klijenta, i upravo zato stanje treba promatrati, a ne pretpostavljati. Tretirajte postavku kao dio kill switcha, 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 poslužitelja 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, zdravu sesiju, prekid koji nitko nije tražio i sesiju nakon oporavka. U svakom trenutku pročitajte zadanu 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 sučelja i korake oporavka, jer kill switch koji nitko ne može provjeriti je glasina.