Perché l’adattatore VPN resta sul profilo pubblico del firewall

Il tunnel è attivo, l’account è stato autenticato sul dominio e Windows etichetta ancora la connessione come pubblica. Una regola del firewall scritta per il profilo di dominio non si applica, quindi, e la condivisione file resta irraggiungibile. Il tentativo di correzione abituale è impostare l’adattatore su privato, il che cambia quali regole si applicano senza cambiare nulla dell’autenticazione. Sia l’etichetta sia la correzione sono ampiamente fraintese, e separarle richiede tre comandi.

L’account che si è connesso non è la categoria della rete

Durante una connessione VPN vengono prese due decisioni diverse ed è facile confonderle. Il gateway decide se l’account può connettersi. Windows decide come classificare la rete risultante, e quella classificazione determina quali regole del firewall si applicano all’interfaccia.

Un’autenticazione di dominio riuscita sul gateway è una prova sull’account. Non è una prova che l’endpoint abbia autenticato la rete presso un controller di dominio, ed è esattamente ciò che rappresenta la categoria di dominio.

Per questo una macchina può essere aggiunta a un dominio, connettersi con un account di dominio e mostrare comunque Pubblico. La classificazione è una determinazione locale sulla rete, non un’affermazione sulle credenziali che hanno aperto il tunnel. L’account può essere del tutto valido mentre l’etichetta resta dov’era.

Tre categorie, una delle quali non può essere impostata

Windows espone tre categorie e solo due possono essere assegnate da un amministratore. La terza è decisa dal sistema operativo dopo che ha autenticato con successo la rete presso un controller di dominio.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

Il terzo comando fallisce, e questo è il comportamento documentato, non un problema di autorizzazioni. Il riferimento del cmdlet stesso afferma che la categoria di dominio non può essere assegnata in questo modo, perché Windows la deriva dall’autenticazione di dominio. Vedere l’errore è una conferma utile che la categoria è una conseguenza e non un’impostazione.

Leggi il primo comando sull’endpoint il cui traffico è bloccato. La classificazione dell’interfaccia del gateway stesso non dice nulla su come ogni workstation connessa ha classificato il proprio tunnel.

Le regole seguono il profilo per cui sono state scritte

Una volta nota la categoria, l’accesso mancante di solito si spiega da solo. Ogni regola di Windows Firewall porta un ambito di profilo, e una regola limitata al dominio non si applica quando l’interfaccia è pubblica. Tre comandi trasformano questo in una risposta anziché in una teoria, e il terzo intercetta il caso in cui il profilo non è mai stato il problema:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

Il secondo comando è quello che trasforma un resoconto vago in una correzione. Se la regola è limitata a un intervallo di indirizzi remoti che non include il pool VPN, anche cambiare il profilo non aiuterà.

Controlla anche l’azione in entrata predefinita. Su una macchina dove il traffico in entrata è bloccato per impostazione predefinita, una regola di autorizzazione mancante produce silenzio anziché un rifiuto. Dal lato client sembra identico a un errore di routing, ed è per questo che tanti di questi ticket iniziano con l’ipotesi sbagliata.

Stabilisci quale macchina applica la regola

Prima di cambiare categoria, stabilisci dove avviene il blocco. Il server che ospita la condivisione può avere un proprio firewall, e le sue regole si applicano al traffico che arriva dal pool VPN indipendentemente da come il client ha etichettato il proprio adattatore. Un rifiuto lì è invisibile a ogni comando locale che esegui, e il lato client segnala soltanto che la risorsa non è disponibile. Prova le regole della destinazione prima di toccare la classificazione del client.

Prova dal client verso la porta specifica, poi confronta con una prova da un altro host sulla stessa VPN. Se falliscono entrambe, il problema è alla destinazione o sul percorso. Se fallisce solo una, la differenza è locale a quella macchina, e la categoria del profilo diventa una causa plausibile.

Tieni presente anche la direzione. Una regola che consente SMB in entrata non fa nulla per un client la cui regola in uscita blocca lo stesso traffico. Da una finestra di Esplora file i due guasti sono indistinguibili, quindi prova ogni direzione separatamente prima di modificare qualsiasi cosa.

Cosa fare invece di rietichettare tutto

Rendere privata una rete non identificata per soddisfare una regola ampia è un cambiamento reale con conseguenze reali. Il profilo privato in genere consente più individuazione e più traffico in entrata di quello pubblico.

Se l’obiettivo è lasciare che un servizio specifico raggiunga i client VPN, limita la regola per indirizzo remoto anziché per profilo. Questo esprime l’intento con precisione, funziona indipendentemente dalla classificazione e non dipende dal fatto che Windows indovini correttamente un adattatore virtuale. Sopravvive anche a un aggiornamento del client che riclassifica l’interfaccia. Scrivi il pool nella regola e la persona successiva potrà leggere l’intento senza chiedere.

Se la categoria di dominio è davvero attesa e non compare mai, si tratta di un’indagine separata. Verifica che la macchina sia aggiunta al dominio, che possa raggiungere un controller di dominio attraverso il tunnel e che il canale sicuro sia in salute. Questi tre comandi rispondono senza una sola modifica al registro:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Questi tre rispondono alla domanda se l’endpoint potesse autenticare la rete. Se non riesce a raggiungere un controller, la categoria di dominio non sarà mai assegnata, per quante volte si reimposti l’adattatore. La regola del firewall che stavi inseguendo non è mai stata il vero problema, e l’etichetta era un sintomo di un percorso rotto, non una causa.