Nedskript eller brandväggsregel: vad stoppar läckan?

Två konstruktioner lovar samma sak: när tunneln faller, går ingenting ut i klartext. Den ena kör ett skript vid nedtagningen och klipper gränssnitten. Den andra låter en brandväggsregel stå kvar och ber inte VPN-klienten om något. De skiljer sig i vem som har rättigheten att agera, i vad som händer under gapet och i hur maskinen kommer tillbaka online efteråt. Att jämföra dem på dessa tre punkter är mer användbart än att diskutera vilken som är strängast.

Samma arbete genom två mekanismer

Klienten kan köra krokar när tunneln kommer upp och när den tas ner, förutsatt att profilen tillåter skriptkörning. Den kroken körs inom klientens livscykel, i det ögonblick då anslutningen stängs. En brandväggsregel däremot ägs av systemet och bryr sig inte om klienten kör, har kraschat eller dödats.

Den tabellen är hela argumentet. Ett skript som bara körs vid en snygg avstängning täcker fallet du var minst orolig för; fallet som spelar roll är kraschen eller nätet som försvinner, och ingen av dem ger en ren nedtagning.

Vad nedtagningskroken kan och inte kan

Det dokumenterade mönstret går igenom nätverksgränssnitten och tar ner allt utom loopback. Med den fysiska enheten nere kan ingenting slippa ut utanför tunneln, och det är precis avsikten.

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

Det tar också ner det lokala nätet, varje tjänst som maskinen är värd för, och den väg du skulle använda för att åtgärda problemet. På en bärbar dator måste den trådlösa enheten ibland slås av och på manuellt efteråt, så ett kort avbrott blir en reparationssession. Värre, kroken kanske inte får göra något av detta: när klienten släpper rättigheter körs nedskriptet under det oprivilegierade kontot, och varje gränssnittsändring misslyckas med ett behörighetsfel som skrivs i det ögonblick ingen läser loggen.

Kontrollera hur klienten startas innan du litar på kroken. Ett skript som fungerar när du kör det manuellt som root bevisar ingenting om tjänsten som startar vid uppstart.

Vad brandväggsregeln gör annorlunda

En regel som bara tillåter tunneltrafik fortsätter att fungera när klientprocessen är borta, eftersom kärnan inte är beroende av den processen. Regeln är också smalare: den blockerar exakt de flöden den matchar och lämnar loopback, det lokala subnätet och återställningsvägen i fred, och därför sätter den inte maskinen på bar backe.

Priset är att regeln måste skrivas och underhållas av den som äger värdens brandvägg, och den måste namnge den tunnelenhet som klienten faktiskt skapar. Det betyder att regeln och profilen måste underhållas tillsammans; ett gränssnitt som bytt namn lämnar en brandvägg som blockerar allt och inte förklarar något.

Ingen av mekanismerna gör den andra överflödig. En brandväggsregel som aldrig läses in igen efter en ändring är lika fiktiv som ett skript som aldrig körs.

persist-tun avgör om det finns ett gap

När tunnelenheten överlever en frånkoppling överlever också rutterna som pekar in i den. Trafiken släpps då i stället för att omdirigeras, så standardrutten faller inte tillbaka på den fysiska gatewayen. Det är detta beteende som gör en läcka osannolik redan innan någon brandväggsregel är inblandad.

Utan den inställningen tas enheten bort och rutterna med den, och standardrutten kan peka tillbaka på den fysiska gatewayen. Om den gör det beror på plattformen och klienten, och just därför måste tillståndet observeras i stället för antas. Behandla inställningen som en del av kill switch, inte som ett prestandaval.

Håll återanslutningsvägen levande och testa sedan fyra tillstånd

En strikt blockering kan också hindra klienten från att återansluta, eftersom klienten fortfarande behöver en rutt till servern via den fysiska gatewayen medan allt annat nekas. Installera en värdrutt för den enda adressen innan tunneln kommer upp, och lös upp namnet först, eftersom DNS kan vara blockerat när du behöver det.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Verifiera sedan tillstånden i stället för etiketten. Gå igenom fyra ögonblick med avsikt: en kall start utan tunnel, en frisk session, ett brott som ingen bad om, och sessionen efter att den återhämtat sig. Läs standardrutten i varje ögonblick och gör en begäran vars utgångsadress är synlig. Ett program som ger upp medan tunneln är nere säger ingenting om en e-postklient eller en uppdaterare, så upprepa den sista kontrollen med ett bakgrundsprogram. Skriv ner regeln, gränssnittsnamnen och återställningsstegen, för en kill switch som ingen kan verifiera är ett rykte.