Client VPN bloccati dal profilo Pubblico del firewall di Windows
Windows classifica l’adattatore VPN come Pubblico, quindi le regole LAN non si applicano mai. Controllate il profilo, limitate una regola in ingresso al pool, poi verificate la porta.
Il tunnel è attivo, il gateway risponde al ping e la condivisione file va comunque in timeout. Questa combinazione raramente è un problema di routing: Windows ha inserito la subnet dell’adattatore VPN nel profilo Pubblico, e ogni regola di autorizzazione scritta per Privato o Dominio non è mai stata applicata. L’ho riscontrato su portatili che raggiungono l’ufficio senza problemi e su server RRAS che servono tutti gli altri client, e la riparazione è breve una volta individuato il profilo in gioco. Ecco l’ordine in cui lavoro, con il controllo che vi dice quando fermarvi prima del passo successivo.
Scoprire su quale profilo arriva davvero il traffico
Il Firewall di Windows non ha un unico modo globale. Ogni interfaccia connessa porta una categoria, e i pacchetti in ingresso vengono filtrati in base alla categoria dell’interfaccia da cui arrivano, quindi è il profilo dell’adattatore VPN a decidere cosa può raggiungere un client in tunnel, non l’adattatore Wi-Fi o Ethernet che gli sta accanto. Leggete entrambi i dati prima di modificare qualsiasi cosa:
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction
Con un’installazione standard di OpenVPN o WireGuard, l’adattatore VPN compare come rete non identificata e finisce in Pubblico, l’impostazione predefinita per qualsiasi rete che Windows non riesce a classificare: nessun controller di dominio ha risposto su quella rete e nessun profilo del gateway corrispondeva. Il nome dell’interfaccia qui non conta, quindi chiamare l’adattatore «VPN» o «Corp» non cambia nulla. DomainAuthenticated richiede una macchina aggiunta al dominio , che riesca davvero a raggiungere un controller di dominio su quell’interfaccia; un tunnel split che trasporta una sola subnet non basta.
Se la regola che serve è già limitata al pool VPN e si applica già alla categoria appena letta, fermatevi qui: il filtro non è il vostro livello, e il prossimo posto da guardare è la configurazione del servizio. Quel controllo richiede dieci secondi e fa risparmiare un’ora di modifiche alle regole. I nomi delle categorie e ciò che ciascuna copre sono documentati nella documentazione di riferimento di Get-NetConnectionProfile.
Confermate il filtro, non il routing, prima di modificare le regole
Il ping è un test debole. ICMP può passare mentre la porta del servizio viene scartata, e un host può rispondere dalla LAN pur rifiutando la stessa richiesta sul tunnel. Provate la porta che serve al client, dal client:
Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed
Se il test della porta fallisce, separate i due livelli. Un guasto del tunnel o della rotta di solito si manifesta come nessuna risposta dall’indirizzo del gateway, mentre uno scarto del firewall mostra un gateway che risponde e una porta di servizio che non risponde. Su un server Windows che pubblica il pool tramite RRAS, eseguite lo stesso test da un client e leggete il profilo del server stesso: l’interfaccia RAS può trovarsi in una categoria le cui regole in ingresso non citano mai l’intervallo dei client, ed è per questo che la macchina serve la propria LAN e rifiuta ogni client in tunnel.
Se il risultato è ancora ambiguo, registrate nel log gli scarti del profilo in gioco e leggeteli:
Set-NetFirewallProfile -Name Public -LogBlocked True `
-LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"
Le voci che riportano indirizzo e porta del client con DROP sono conclusive, e indicano anche quale regola mancava. Un log vuoto mentre il SYN del client non compare mai punta a monte dell’host, quindi tornate al tunnel, alla regola NAT o alla rotta del pool prima di toccare un altro oggetto del firewall.
Limitate una regola in ingresso al pool di client
La riparazione è una sola regola di autorizzazione in ingresso il cui indirizzo remoto è il pool, non il mondo intero. Da una sessione con privilegi elevati:
New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
-Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
-RemoteAddress 10.8.0.0/24 -Profile PublicQuando il servizio è un singolo binario, preferite una regola limitata al programma con -Program anziché un elenco di porte; così l’eccezione resta limitata sia al processo sia all’intervallo di origine.
La scelta del profilo è il punto in cui lo stesso errore si commette nella direzione opposta. -Profile Public è sufficiente quando l’adattatore è Pubblico e resta Pubblico. -Profile Any è difendibile quando il servizio deve funzionare indipendentemente da come Windows classifica l’adattatore, ma solo finché resta il limite remoto. Ciò che non è mai difendibile è -RemoteAddress Any nel profilo Pubblico: quella regola segue il portatile in ogni rete di bar e alberghi a cui si collega e apre la porta a chiunque condivida quella subnet.
Annotate il pool accanto alla regola. -RemoteAddress 10.8.0.0/24 smette silenziosamente di corrispondere il giorno in cui il pool VPN viene rinumerato, e il guasto sembra esattamente il bug originale, per cui costa un secondo pomeriggio. Assegnate alle regole il nome del servizio e dell’intervallo di origine, tenetele insieme con -Group, e rileggetele ogni volta che la definizione del pool cambia. Un inventario di regole verificabile in una sola schermata vale più di una regola corretta che nessuno riesce a trovare.
Cambiate la categoria solo quando la categoria è la decisione
Portare l’interfaccia su Privato funziona ugualmente, ma è l’impostazione predefinita sbagliata. Il profilo Privato contiene un lungo elenco di regole di autorizzazione predefinite, che coprono condivisione di file e stampanti, individuazione rete, desktop remoto e altro a seconda della baseline, quindi riclassificare l’adattatore VPN le abilita tutte insieme per ogni client del tunnel. Una regola limitata concede un servizio a un intervallo. Su un portatile che si collega anche a reti non affidabili, questa differenza non è cosmetica.
Ci sono casi in cui la classificazione è davvero sbagliata: un tunnel sempre attivo o site-to-site che trasporta una subnet d’ufficio è infrastruttura fidata, e contrassegnare quell’adattatore come Privato è una scelta di progetto legittima, fatta una volta per policy e non per singolo ticket. Quando la fate, fatela in modo esplicito:
Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory PrivateSu un dispositivo gestito, verificate prima se il criterio di gruppo o una baseline MDM possiede l’impostazione. Se è così, la modifica locale viene annullata al successivo aggiornamento e gpresult /h indicherà il criterio che la possiede; correggete lì, non sull’endpoint.
Verificate da entrambe le estremità e lasciate traccia
Verificate il flusso segnalato dall’utente, dal client, dopo la modifica:
Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort
Chiudete poi il cerchio sulle cose che si romperanno la settimana prossima. Riavviate l’host e ripetete il test, perché una regola limitata al profilo sbagliato continua a funzionare finché l’adattatore non ritorna in un’altra categoria. Provate da un secondo client, dato che un client che conserva un lease obsoleto può mascherare una discrepanza del pool. Contate le regole aggiunte rispetto a quelle rimosse, perché le eccezioni sovrapposte sono il modo in cui una correzione di due righe diventa una politica di filtro che nessuno può rivedere.
Prima di dichiararlo concluso:
- Il profilo indicato nella regola è quello dell’interfaccia da cui arriva il traffico.
- Il limite remoto è il pool VPN, e quel pool corrisponde a ciò che il server assegna davvero.
- Nessuna regola che avete aggiunto usa
-RemoteAddress Anynel profilo Pubblico. - Non è stato disattivato nulla per far passare il test, e ogni cambio di categoria registra chi lo ha approvato.