Kill switch su Windows senza software aggiuntivo: profili o route?
I profili del firewall seguono la categoria della rete, le route seguono l’adattatore. Confrontate entrambi, poi provate il caso del crash con il tunnel sparito e l’icona che mente.
Il client muore a metà download e l’icona nella barra delle applicazioni svanisce. Il trasferimento continua sulla connessione di casa. È proprio questa sequenza il motivo per cui esiste un kill switch, e Windows può avvicinarsi a uno senza un secondo prodotto.
Due metodi meritano di essere conosciuti. Falliscono in punti diversi, e nessuno dei due è una risposta completa.
Metodo uno: consentire il programma su un solo profilo
Il firewall di Windows limita le regole ai profili Domain, Private e Public. Il trucco è dare una categoria all’adattatore del tunnel e un’altra all’adattatore fisico. Poi si scrive una regola in uscita che consente il programma protetto sul profilo del tunnel e lo blocca ovunque altro. Il firewall legge la categoria, non il nome dell’adattatore.
Impostate prima la connessione VPN su Private e la rete fisica su Public. Poi aggiungete una regola di blocco per il programma valida per i profili che non volete. Infine confermate l’assegnazione con Get-NetConnectionProfile, perché è quella assegnazione che la regola segue.
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
New-NetFirewallRule -DisplayName 'Block browser off VPN' -Direction Outbound `
-Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Block -Profile Public
New-NetFirewallRule -DisplayName 'Allow browser on VPN' -Direction Outbound `
-Program 'C:\Program Files\Mozilla Firefox\firefox.exe' -Action Allow -Profile Private
La debolezza è strutturale. Una regola di profilo segue la categoria, quindi quando Windows riclassifica una rete d’albergo il blocco può smettere di valere. Nulla nella lista delle regole cambia quando accade.
Metodo due: rimuovere la route predefinita fisica
L’approccio per route è più brutale e molto più facile da verificare. Annotate il gateway fisico, lasciate che la VPN installi la propria route predefinita con metrica più bassa, poi cancellate la predefinita fisica. Nient’altro può più trasportare traffico.
route print -4
route delete 0.0.0.0 mask 0.0.0.0 192.168.50.1
route print -4 | findstr /c:"0.0.0.0"
Quando il client muore, la route della VPN se ne va con il suo adattatore. La macchina va offline invece di perdere dati, ed è esattamente ciò che un kill switch deve produrre.
Due dettagli decidono se resiste una settimana. Il DHCP rimette il gateway ogni volta che il collegamento vacilla. Un adattatore fisico con indirizzo statico evita quella sorpresa. Anche l’indirizzo del server VPN stesso deve restare raggiungibile. Senza quel percorso verso l’host il client non potrà mai riconnettersi dopo la caduta che ha attivato il blocco.
Metodo tre: nessun gateway, una route host persistente
La terza opzione inizia cancellando il gateway dalle impostazioni dell’adattatore. Poi una sola route persistente verso l’endpoint della VPN lo sostituisce. La macchina può quindi parlare con il server e con nient’altro finché il tunnel non sale.
route -p add 198.51.100.44 mask 255.255.255.255 192.168.50.1 metric 1
route print -4 | findstr 198.51.100.44
Ripristinare il gateway ripristina l’internet normale, il che lo rende un interruttore pulito di accensione e spegnimento. Non dipende da uno script che osserva gli eventi dell’interfaccia. Non gli importa nemmeno come viene categorizzata la rete.
Il prezzo è un isolamento totale mentre il tunnel è giù. Gli aggiornamenti si fermano, e così anche il download che ha motivato l’esercizio. Su un portatile da lavoro è spesso corretto, mentre su una macchina personale è una decisione da prendere deliberatamente.
Perché l’icona del globo non dimostra nulla
Windows segnala la raggiungibilità con una sonda verso un endpoint Microsoft. Quella sonda non dice nulla sul vostro tunnel. Un tunnel connesso può stare dietro un globo che segnala assenza di internet, e uno morto può mostrare una connessione sana.
Provate a uccidere il processo del client e poi cercate di raggiungere un indirizzo pubblico per numero. Una ricerca di nome può essere risolta dalla cache, quindi né l’icona né una risposta DNS sono prove.
Cosa registrare dopo una caduta reale
Eseguite il test come sequenza e non come singolo controllo. Uccidete il processo invece di disconnettere, poi provate un indirizzo numerico su entrambe le famiglie. Ripristinate poi il client e confermate che raggiunge ancora il proprio server tramite la route conservata.
taskkill /IM openvpn-gui.exe /F
ping -4 198.51.100.44
ping -6 2606:4700:4700::1111
route print -4 | findstr /c:"0.0.0.0"
Ripetete la sequenza dopo la sospensione, dopo un cambio di Wi-Fi e dopo il passaggio da cavo a wireless. È in queste transizioni che falliscono insieme il metodo dei profili e il comportamento del DHCP. Una regola che tiene su una scrivania non tiene necessariamente in albergo.
Scrivete il passo di annullamento accanto a ogni regola e route. Microsoft documenta la creazione delle regole in uscita nella sua referenza sulle regole del firewall di Windows, e quella è una fonte migliore di un tutorial fatto solo di schermate.