Tunnel del dispositivo su Windows Pro? Controllate la matrice delle edizioni

Il profilo arriva sul portatile, la pagina delle impostazioni VPN lo mostra, e il tunnel del dispositivo non si connette mai nella schermata di accesso. Su Windows Pro spesso non è un errore di configurazione. Il tunnel del dispositivo nativo è concesso in licenza per edizione, e un tunnel utente che funziona dopo l’accesso prova una capacità diversa. Leggete il requisito prima di eseguire il debug del certificato.

Il sintomo compare prima che qualcuno acceda

Un tunnel utente si connette nel contesto dell’utente dopo l’accesso, ed è per questo che funziona normalmente su Pro. Un tunnel del dispositivo dovrebbe stabilire la connettività della macchina prima che qualsiasi utente acceda, usando un certificato macchina e IKEv2. Queste sono fasi diverse del ciclo di vita, non due nomi dello stesso profilo.

Su un’edizione non idonea il profilo può comunque essere distribuito ed elencato, ma la connessione prima dell’accesso non compare. Dopo l’accesso il tunnel utente può funzionare perfettamente, il che fa sembrare la distribuzione sana in ogni controllo eseguito dal proprietario dell’account. L’errore è invisibile dall’interno di una sessione già connessa.

Rendere un profilo disponibile a tutti gli utenti cambia chi può usarlo. Non cambia il contesto di autenticazione da utente a macchina, quindi non può trasformare un tunnel utente in un tunnel del dispositivo. La differenza è il contesto di autenticazione, non la visibilità del profilo.

Leggete la matrice, non solo il nodo CSP

La matrice delle funzionalità di Windows 11 di Microsoft elenca il tunnel del dispositivo Always On VPN nativo per Enterprise ed Education. Il provider del servizio di configurazione VPNv2 documenta separatamente un nodo DeviceTunnel la cui applicabilità include Pro, e quella riga viene spesso citata come prova che la funzionalità funziona. Superficie di configurazione e licenza della funzionalità rispondono a domande diverse: una dice che un’impostazione può essere espressa, l’altra che l’edizione ha diritto alla capacità.

Verificate l’edizione e la build effettive invece di fidarvi del registro di acquisto. L’attivazione gestita, un aggiornamento in corso o un’immagine ricostruita possono lasciare una macchina su un’edizione diversa da quella indicata nell’elenco degli asset:

winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumber

Se l’output dice Pro, il tunnel del dispositivo nativo è fuori dal set di funzionalità documentato per quella macchina. Questa conclusione non richiede una modifica del profilo e non verrà corretta da una. Registrate questo risultato prima di cambiare qualsiasi altra cosa.

Quattro prerequisiti dietro il flag della funzionalità

L’edizione è il cancello, e i requisiti rimanenti spiegano perché una macchina su un’edizione idonea fallisce comunque. Controllateli in ordine, perché ciascuno può produrre lo stesso risultato silenzioso. Saltare una riga spreca lo sforzo dedicato alle righe sottostanti. L’edizione viene per prima per una ragione.

Il controllo del certificato è quello che le persone saltano. La chiave privata deve essere presente nell’archivio della macchina e utilizzabile dal contesto di sistema prima dell’accesso, che è un archivio diverso da quello che un utente vede nella propria finestra dei certificati:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfter

Un certificato che sembra corretto nell’archivio dell’utente può essere completamente assente dall’archivio della macchina. Il tunnel del dispositivo fallisce allora l’autenticazione prima che compaia la schermata di accesso, e nessuna reimportazione del profilo lo cambia. Controllate l’archivio usato dal servizio, non quello che vede l’utente.

Un’attività pianificata come SYSTEM non è la funzionalità

Circola una soluzione alternativa che avvia un profilo VPN da un’attività pianificata eseguita come SYSTEM, facendo comparire un tunnel poco dopo l’avvio. Non è il tunnel del dispositivo nativo. Il motore delle attività si avvia in un altro momento, la connessione è un profilo in modalità utente avviato da un account di servizio e il ciclo di vita non corrisponde a un tunnel autenticato dalla macchina che deve esistere nella schermata di accesso.

Può superare un test superficiale perché il tunnel è attivo quando qualcuno accede e controlla. Quel successo misura il ritardo tra l’avvio e l’attività, non la connettività prima dell’accesso, e lascia la macchina senza tunnel durante la finestra che la funzionalità avrebbe dovuto coprire.

Considerate la soluzione alternativa non supportata per la produzione. Se un progetto dipende da essa, il requisito è probabilmente una connessione prima dell’accesso, il che riporta la discussione all’idoneità dell’edizione.

Scegliete il requisito prima della tecnologia

Scrivete il requisito in una frase: il dispositivo deve raggiungere una risorsa denominata prima che qualsiasi utente acceda, oppure l’utente ha bisogno di accesso dopo l’accesso. Se la seconda frase è vera, un tunnel utente Always On su Pro è un progetto supportato e il tunnel del dispositivo è una complessità inutile.

Se la prima frase è vera, l’edizione è un cancello rigido. Scegliete un’edizione idonea o un’architettura documentata prima dell’accesso supportata dall’organizzazione, e pianificate la modifica della licenza prima di costruire profili e certificati attorno a una capacità che la macchina non può eseguire.

Registrate l’edizione, lo stato di join, la posizione del certificato e il canale di provisioning nelle note di distribuzione. Il prossimo ingegnere potrà così confermare l’idoneità in pochi minuti invece di ripetere la stessa risoluzione dei problemi del profilo su una macchina che non si sarebbe mai connessa.