Nedlukningsscript eller firewallregel: hvad stopper lækken?

To design lover det samme: når tunnelen falder, forlader intet maskinen i klartekst. Det ene kører et script ved nedlukning og skærer netværkskortene over. Det andet lader en firewallregel stå ved magt og beder VPN-klienten om ingenting. De adskiller sig i, hvem der har rettigheden til at handle, i hvad der sker i hullet, og i hvordan maskinen kommer online igen bagefter. At sammenligne dem på de tre punkter er mere nyttigt end at diskutere, hvilken der er strengest.

Samme arbejde gennem to mekanismer

Klienten kan køre hooks, når tunnelen kommer op, og når den rives ned, forudsat at profilen tillader scriptkørsel. Det hook kører inde i klientens livscyklus på det tidspunkt, hvor forbindelsen lukker. En firewallregel derimod ejes af systemet og er ligeglad med, om klienten kører, er styrtet eller blev dræbt.

Den tabel er hele argumentet. Et script, der kun kører ved en pæn nedlukning, dækker det tilfælde, du var mindst bekymret for; det tilfælde, der betyder noget, er styrtet eller netværket, der forsvinder, og ingen af dem giver en ren nedrivning.

Hvad nedrivningshooket kan og ikke kan

Det dokumenterede mønster går netværkskortene igennem og tager alt ned undtagen loopback. Når den fysiske enhed er nede, kan intet undslippe uden for tunnelen, hvilket er præcis hensigten.

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

Det tager også det lokale netværk ned, enhver tjeneste maskinen hoster, og den vej, du ville bruge til at reparere problemet. På en bærbar skal den trådløse enhed nogle gange skiftes manuelt bagefter, så et kort udfald bliver en reparationssession. Værre, hooket har måske slet ikke lov til at gøre noget af det: når klienten opgiver rettigheder, kører nedlukningsscriptet som den uprivilegerede konto, og hver grænsefladeændring fejler med en tilladelsesfejl, der skrives i det øjeblik, ingen læser loggen.

Kontroller, hvordan klienten startes, før du stoler på hooket. Et script, der virker, når du kører det manuelt som root, beviser intet om den tjeneste, der starter ved opstart.

Hvad firewallreglen gør anderledes

En regel, der kun tillader tunneltrafik, bliver ved med at virke, når klientprocessen er væk, fordi kernen ikke afhænger af den proces. Reglen er også snævrere: den blokerer præcis de strømme, den matcher, og lader loopback, det lokale subnet og reparationsvejen være i fred, og derfor efterlader den ikke maskinen isoleret.

Prisen er, at reglen skal skrives og vedligeholdes af den, der ejer værtens firewall, og den skal navngive den tunne-enhed, klienten faktisk opretter. Det betyder, at reglen og profilen skal vedligeholdes sammen; en omdøbt grænseflade efterlader en firewall, der blokerer alt og forklarer intet.

Ingen af mekanismerne gør den anden overflødig. En firewallregel, der aldrig genindlæses efter en ændring, er lige så fiktiv som et script, der aldrig kører.

persist-tun afgør, om der er et hul

Når tunne-enheden overlever en afbrydelse, overlever ruterne ind i den også. Trafikken smides så væk i stedet for at blive omdirigeret, så standardruten falder ikke tilbage til den fysiske gateway. Det er den adfærd, der gør en lække usandsynlig, allerede før nogen firewallregel er involveret.

Uden den indstilling fjernes enheden og ruterne med den, og standardruten kan igen pege på den fysiske gateway. Om den gør det, afhænger af platformen og klienten, og det er netop derfor, tilstanden skal iagttages i stedet for at antages. Behandl indstillingen som en del af kill switch, ikke som en ydelsesindstilling.

Hold genopkoblingsvejen i live, og test så fire tilstande

En streng blokering kan også forhindre klienten i at genopkoble, fordi klienten stadig har brug for en rute til serveren gennem den fysiske gateway, mens alt andet afvises. Installer en værtsrute til den ene adresse, før tunnelen kommer op, og slå navnet op først, fordi DNS kan være blokeret på det tidspunkt, du har brug for det.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Verificer så tilstandene i stedet for etiketten. Gennemfør fire øjeblikke med vilje: en kold start uden tunnel, en sund session, et brud som ingen bad om, og sessionen efter den kommer sig. Læs standardruten ved hvert øjeblik, og lav en anmodning, hvis udgangsadresse er synlig. Et program, der giver op, mens tunnelen er nede, siger intet om en mailklient eller en opdatering, så gentag den sidste kontrol med et baggrundsprogram. Skriv reglen, grænsefladenavnene og gendannelsestrinene ned, for en kill switch, som ingen kan verificere, er et rygte.