Script de oprire sau regulă de firewall: care oprește scurgerea?

Două modele promit același lucru: când tunelul cade, nimic nu iese afară în clar. Unul rulează un script la oprire și taie interfețele. Celălalt lasă o regulă de firewall în vigoare și nu cere nimic de la clientul VPN. Ele diferă prin cine are privilegiul de a acționa, prin ce se întâmplă în timpul golului și prin modul în care mașina revine online după aceea. Compararea lor pe aceste trei puncte este mai utilă decât disputa despre care este mai strict.

Aceeași muncă prin două mecanisme

Clientul poate rula cârlige când tunelul urcă și când este oprit, cu condiția ca profilul să permită execuția de scripturi. Cârligul rulează în ciclul de viață al clientului, în momentul în care conexiunea se închide. O regulă de firewall, dimpotrivă, aparține sistemului și nu o interesează dacă clientul rulează, a căzut sau a fost omorât.

Acest tabel este întregul argument. Un script care rulează doar la o închidere curată acoperă cazul care vă îngrijora cel mai puțin; cazul care contează este căderea sau rețeaua care dispare, iar niciunul nu produce o oprire curată.

Ce poate și ce nu poate face cârligul de oprire

Modelul documentat parcurge interfețele de rețea și coboară tot, în afară de loopback. Cu dispozitivul fizic coborât, nimic nu poate scăpa în afara tunelului, iar aceasta este exact intenția.

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

Coboară și rețeaua locală, orice serviciu găzduit de mașină și calea pe care ați folosi-o pentru a repara problema. Pe un laptop, dispozitivul wireless are uneori nevoie de o comutare manuală după aceea, așa că o întrerupere scurtă devine o sesiune de reparații. Mai rău, cârligului i-ar putea să nu i se permită nimic din toate acestea: când clientul renunță la privilegii, scriptul de oprire rulează sub contul neprivilegiat, iar fiecare modificare de interfață eșuează cu o eroare de permisiuni scrisă exact în momentul în care nimeni nu citește jurnalul.

Verificați cum este pornit clientul înainte să aveți încredere în cârlig. Un script care funcționează când îl rulați manual ca root nu dovedește nimic despre serviciul care pornește la boot.

Ce face diferit regula de firewall

O regulă care permite doar traficul tunelului continuă să funcționeze când procesul clientului a dispărut, pentru că nucleul nu depinde de acel proces. Regula este și mai îngustă: blochează exact fluxurile pe care le potrivește și lasă în pace loopback, subrețeaua locală și calea de recuperare, de aceea nu lasă mașina fără ieșire.

Prețul este că regula trebuie scrisă și întreținută de cel care deține firewall-ul gazdei, și trebuie să numească dispozitivul de tunel pe care clientul îl creează de fapt. Asta înseamnă că regula și profilul trebuie întreținute împreună; o interfață redenumită lasă un firewall care blochează tot și nu explică nimic.

Niciun mecanism nu îl face pe celălalt de prisos. O regulă de firewall care nu este reîncărcată niciodată după o modificare este la fel de fictivă ca un script care nu rulează niciodată.

persist-tun decide dacă există un gol

Când dispozitivul de tunel supraviețuiește unei deconectări, supraviețuiesc și rutele care duc în el. Traficul este atunci aruncat în loc să fie redirecționat, așa că ruta implicită nu revine la poarta fizică. Acesta este comportamentul care face o scurgere improbabilă chiar înainte ca vreo regulă de firewall să intre în joc.

Fără această setare, dispozitivul este eliminat împreună cu rutele, iar ruta implicită poate arăta din nou spre poarta fizică. Dacă o face depinde de platformă și de client, și exact de aceea starea trebuie observată, nu presupusă. Tratați setarea ca parte a kill switch-ului, nu ca opțiune de performanță.

Mențineți vie calea de reconectare, apoi testați patru stări

Un blocaj strict poate împiedica și reconectarea clientului, pentru că clientul are în continuare nevoie de o rută către server prin poarta fizică în timp ce tot restul este refuzat. Instalați o rută de gazdă pentru acea singură adresă înainte ca tunelul să urce, și rezolvați mai întâi numele, pentru că DNS poate fi blocat până în momentul în care aveți nevoie de el.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Apoi verificați stările, nu eticheta. Exersați deliberat patru momente: o pornire la rece fără tunel, o sesiune sănătoasă, o cădere pe care nimeni nu a cerut-o și sesiunea după ce își revine. În fiecare moment citiți ruta implicită și faceți o cerere al cărei adresă de ieșire este vizibilă. O aplicație care renunță cât timp tunelul este coborât nu spune nimic despre un client de e-mail sau un actualizator, așa că repetați ultima verificare cu o aplicație de fundal. Notați regula, numele interfețelor și pașii de recuperare, pentru că un kill switch pe care nimeni nu îl poate verifica este doar un zvon.