Nedskript eller brannmurregel: hva stopper lekkasjen?

To design lover det samme: når tunnelen faller, går ingenting ut i klartekst. Det ene kjører et skript ved nedriving og kutter grensesnitt. Det andre lar en brannmurregel stå ved makt og ber ikke VPN-klienten om noe. De skiller seg i hvem som har rettigheten til å handle, i hva som skjer i gapet, og i hvordan maskinen kommer tilbake på nett etterpå. Å sammenligne dem på disse tre punktene er mer nyttig enn å krangle om hvilken som er strengest.

Samme arbeid gjennom to mekanismer

Klienten kan kjøre kroker når tunnelen kommer opp og når den rives ned, forutsatt at profilen tillater skriptkjøring. Den kroken kjører inne i klientens livssyklus, i det øyeblikket forbindelsen lukkes. En brannmurregel derimot eies av systemet og bryr seg ikke om klienten kjører, har krasjet eller ble drept.

Den tabellen er hele argumentet. Et skript som bare kjører ved en pen avslutning, dekker tilfellet du var minst bekymret for; tilfellet som betyr noe er krasjet eller nettet som forsvinner, og ingen av dem gir en ren nedriving.

Hva nedrivingskroken kan og ikke kan

Det dokumenterte mønsteret går gjennom nettverksgrensesnittene og tar ned alt unntatt loopback. Med den fysiske enheten nede kan ingenting slippe ut utenfor tunnelen, og det er nettopp hensikten.

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

Det tar også ned det lokale nettet, enhver tjeneste maskinen er vert for, og veien du ville brukt til å reparere problemet. På en bærbar PC må den trådløse enheten noen ganger slås av og på manuelt etterpå, så et kort avbrudd blir en reparasjonsøkt. Verre, kroken har kanskje ikke lov til å gjøre noe av dette: når klienten gir fra seg rettigheter, kjører nedskriptet som den uprivilegerte kontoen, og hver grensesnittendring feiler med en tillatelsesfeil som skrives i det øyeblikket ingen leser loggen.

Sjekk hvordan klienten startes før du stoler på kroken. Et skript som virker når du kjører det manuelt som root, beviser ingenting om tjenesten som starter ved oppstart.

Hva brannmurregelen gjør annerledes

En regel som bare tillater tunneltrafikk, fortsetter å virke når klientprosessen er borte, fordi kjernen ikke er avhengig av den prosessen. Regelen er også smalere: den blokkerer nøyaktig de strømmene den passer på og lar loopback, det lokale subnettet og gjenopprettingsveien være i fred, og derfor setter den ikke maskinen fast.

Prisen er at regelen må skrives og vedlikeholdes av den som eier vertens brannmur, og den må navngi tunneenheten klienten faktisk oppretter. Det betyr at regelen og profilen må vedlikeholdes sammen; et omdøpt grensesnitt etterlater en brannmur som blokkerer alt og ikke forklarer noe.

Ingen av mekanismene gjør den andre overflødig. En brannmurregel som aldri lastes på nytt etter en endring, er like fiktiv som et skript som aldri kjører.

persist-tun avgjør om det finnes et gap

Når tunneenheten overlever en frakobling, overlever også rutene som peker inn i den. Trafikken slippes da i stedet for å omdirigeres, så standardruten faller ikke tilbake til den fysiske gatewayen. Det er denne oppførselen som gjør en lekkasje lite sannsynlig allerede før noen brannmurregel er involvert.

Uten den innstillingen fjernes enheten og rutene med den, og standardruten kan peke tilbake til den fysiske gatewayen. Om den gjør det, avhenger av plattformen og klienten, og nettopp derfor må tilstanden observeres i stedet for å antas. Behandle innstillingen som en del av kill switch, ikke som et ytelsesvalg.

Hold gjenoppkoblingsveien levende, og test så fire tilstander

En streng blokkering kan også hindre klienten i å koble til på nytt, fordi klienten fortsatt trenger en rute til serveren gjennom den fysiske gatewayen mens alt annet nektes. Installer en vertsrute for den ene adressen før tunnelen kommer opp, og løs opp navnet først, fordi DNS kan være blokkert på det tidspunktet du trenger det.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Verifiser så tilstandene i stedet for etiketten. Gå gjennom fire øyeblikk med vilje: en kald start uten tunnel, en sunn økt, et brudd ingen ba om, og økten etter at den har kommet seg. Les standardruten i hvert øyeblikk og gjør én forespørsel der utgangsadressen er synlig. Et program som gir opp mens tunnelen er nede, sier ingenting om en e-postklient eller en oppdaterer, så gjenta den siste kontrollen med ett bakgrunnsprogram. Skriv ned regelen, grensesnittnavnene og gjenopprettingstrinnene, for en kill switch ingen kan verifisere er et rykte.