Solo il firewall di Windows come interruttore di emergenza VPN: regge?

Chiedete se il firewall di Windows possa da solo fungere da interruttore di emergenza e otterrete due risposte sicure e incompatibili. Una dice che la regola per tipo di interfaccia fa tutto il lavoro; l’altra che senza script non funziona. Entrambe descrivono metà dello stesso meccanismo. Il firewall può esprimere il blocco, e se il risultato fallisca davvero in modo chiuso dipende da tre cose: come Windows classifica l’adattatore del tunnel, se l’eccezione dell’endpoint sopravvive e se risoluzione dei nomi e IPv6 sono coperte. Sbagliatene una e la macchina o perde dati o perde ogni connettività.

Tre condizioni, in questo ordine

La prima condizione è la classificazione, e decide se la regola che volete è persino esprimibile. Le regole del firewall di Windows possono essere limitate per tipo di interfaccia: cablata, wireless o accesso remoto. Una politica che blocca il traffico in uscita sui tipi fisici e consente il tunnel funziona solo se Windows riconosce il tunnel come accesso remoto.

La seconda condizione è l’eccezione dell’endpoint. Prima che esista un tunnel, il client deve raggiungere il server VPN tramite la scheda fisica, quindi un blocco totale su quella scheda impedisce proprio la connessione che renderebbe inutile il blocco. L’eccezione deve nominare il server e la sua porta, e il pacchetto deve uscire dal gateway fisico invece di entrare in un tunnel non ancora attivo.

La terza è la copertura. Un insieme di regole che blocca IPv4 e dimentica IPv6, o che consente al resolver locale la ricerca dell’endpoint e quindi consente ogni altra ricerca, fallisce aperto esattamente nella finestra che l’interruttore esiste per coprire. È una lacuna di progettazione, non un difetto del firewall. È anche la lacuna che sopravvive a ogni prova su una scrivania.

La classificazione è il primo cancello

Guardate cosa pensa Windows degli adattatori prima di scrivere una sola regola. Una connessione VPN nativa di Windows appare normalmente come accesso remoto. Un client di terze parti che crea il proprio adattatore virtuale appare spesso come cablato, il che significa che un blocco limitato alle schede cablate blocca anche il tunnel.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundAction

Il terzo comando indica se è già in vigore un blocco in uscita predefinito, il che cambia tutta la forma del progetto. Se il valore predefinito è già bloccare, state scrivendo regole di autorizzazione anziché eccezioni a una base permissiva, e questa è una posizione molto più facile da ragionare.

Se il vostro adattatore tunnel si dichiara cablato, solo il firewall non è lo strumento giusto per un progetto a fallimento chiuso, e nessun ritocco delle regole lo cambia. È il caso in cui il secondo parere in ogni discussione del forum è corretto.

L’eccezione dell’endpoint ha bisogno di una rotta oltre che di una regola

Supponiamo che la classificazione funzioni. L’eccezione è composta da due pezzi, e vivono in sottosistemi diversi. La regola del firewall consente il traffico; la rotta dell’host lo fa uscire dall’interfaccia giusta mentre il tunnel è abbassato.

New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
  -Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32

Senza la rotta, l’eccezione aiuta solo finché una rotta predefinita punta ancora al gateway fisico. Quando il client installa la propria rotta predefinita e poi muore, i pacchetti consentiti non hanno un posto sensato dove andare e la connessione non può essere ristabilita. Quel guasto sembra un client rotto ed è in realtà una rotta mancante.

Mantenete l’eccezione stretta quanto il client consente. Un indirizzo e una porta sono verificabili; un intervallo che copre tutta la rete del fornitore no. Quella regola più ampia consente anche qualunque altra cosa ospitata presso lo stesso fornitore, che di solito è più di quanto intendevate.

DNS e IPv6 sono dove fallisce aperto

La risoluzione dei nomi è la fuga classica. Se l’endpoint è un nome host, il client deve risolverlo prima che il tunnel esista, il che significa che alla scheda fisica va consentito di raggiungere un resolver. Lo stesso permesso lascia uscire ogni altra ricerca mentre il tunnel è abbassato, e una ricerca basta a rivelare cosa stavate per visitare.

IPv6 è il secondo. Le regole scritte per IPv4 non coprono l’altra famiglia, e molti client installano solo rotte IPv4. Una macchina con connettività IPv6 nativa può quindi continuare a parlare con internet mentre il lato IPv4 è saldamente bloccato, e l’interruttore segnala successo per tutto il tempo.

La terza riga merita di essere capita invece che aggirata. Un firewall decide dei pacchetti, non dell’interfaccia che un’applicazione ha chiesto di usare, e un programma che si lega esplicitamente può essere difficile da contenere. È un argomento a favore di un interruttore lato client che opera sotto l’applicazione, non di più regole.

Provate fermando il client, non tirando il cavo

L’unica prova significativa è quella che imita il guasto da cui vi proteggete. Fermate il servizio, uccidete il processo o disattivate l’adattatore creato dal client, poi provate a raggiungere internet e un nome:

Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443

Tutte e tre dovrebbero fallire. Se la prima riesce, il blocco non è in vigore; se la seconda riesce dove la prima ha fallito, avete una fuga DNS; se la terza riesce, IPv6 non è coperto. Ogni esito indica esattamente una delle lacune sopra.

Ripetete la prova dopo sospensione e ripresa, perché il profilo del firewall può cambiare quando Windows decide che una rete è pubblica o privata, e le regole limitate a un profilo lo seguono. Un progetto che regge su una scrivania e fallisce in treno è un progetto provato una volta.

Se il cancello di classificazione o il requisito DNS rendono inapplicabile l’approccio solo firewall, un interruttore lato client è la risposta onesta. Se il tunnel termina invece su un router, la politica dovrebbe appartenere al router, perché una regola lì copre ogni dispositivo dietro di esso e non dipende da come Windows etichetta un adattatore.