Enhetstunnel på Windows Pro? Kontrollera utgåvematrisen
En distribuerad profil är inte bevis på behörighet. Jämför utgåvematrisen, CSP-noden och förutsättningarna före inloggning innan du felsöker tunneln.
Profilen landar på den bärbara datorn, sidan för VPN-inställningar visar den, och enhetstunneln ansluter ändå aldrig på inloggningsskärmen. På Windows Pro är detta ofta inte ett konfigurationsfel. Den inbyggda enhetstunneln licensieras per utgåva, och en användartunnel som fungerar efter inloggning bevisar en annan förmåga. Läs kravet innan du felsöker certifikatet.
Symtomet visas innan någon loggar in
En användartunnel ansluter i användarens kontext efter inloggning, vilket är varför den fungerar normalt på Pro. En enhetstunnel ska upprätta maskinanslutning innan någon användare loggar in, med ett maskincertifikat och IKEv2. Dessa är olika faser i livscykeln, inte två namn för samma profil.
På en utgåva som inte är behörig kan profilen fortfarande distribueras och listas, men anslutningen före inloggning visas inte. Efter inloggning kan användartunneln fungera perfekt, vilket får distributionen att se frisk ut i varje kontroll som kontoinnehavaren gör. Felet är osynligt inifrån en session som redan är inloggad.
Att göra en profil tillgänglig för alla användare ändrar vem som får använda den. Det ändrar inte autentiseringskontexten från användare till maskin, så det kan inte göra en användartunnel till en enhetstunnel. Skillnaden är autentiseringskontext, inte profilens synlighet.
Läs matrisen, inte bara CSP-noden
Microsofts funktionsmatris för Windows 11 listar den inbyggda Always On VPN-enhetstunneln för Enterprise och Education. Konfigurationstjänstleverantören VPNv2 dokumenterar separat en DeviceTunnel-nod vars tillämplighet omfattar Pro, och den raden citeras ofta som bevis på att funktionen fungerar. Konfigurationsyta och funktionslicensiering svarar på olika frågor: den ena säger att en inställning kan uttryckas, den andra att utgåvan har rätt till förmågan.
Bekräfta den faktiska utgåvan och builden i stället för att lita på inköpsposten. Hanterad aktivering, en pågående uppgradering eller en återuppbyggd avbildning kan alla lämna en maskin på en annan utgåva än den tillgångslistan anger:
winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumberOm utdata säger Pro ligger den inbyggda enhetstunneln utanför den dokumenterade funktionsuppsättningen för den maskinen. Den slutsatsen kräver ingen profiländring och kommer inte att åtgärdas av en. Anteckna fyndet innan du ändrar något annat.
Fyra förutsättningar bakom funktionsflaggan
Utgåvan är porten, och de återstående kraven förklarar varför en maskin på en behörig utgåva ändå misslyckas. Kontrollera dem i ordning, eftersom var och en kan ge samma tysta resultat. Att hoppa över en rad slösar bort arbetet som lagts på raderna under. Utgåvan kommer först av en anledning.
| Prerequisite | How to verify | Common failure |
|---|---|---|
| Edition and build | DISM /online /get-currentedition | Pro image with an Enterprise asset record |
| Join state | Domain membership in system information | Microsoft Entra join treated as domain join |
| Machine certificate | Certificate store in the local machine context | Certificate issued to the user store |
| Profile context | Provisioned through the machine channel | Delivered as a user tunnel profile |
Certifikatkontrollen är den som folk hoppar över. Den privata nyckeln måste finnas i maskinarkivet och vara användbar för systemkontexten före inloggning, vilket är ett annat arkiv än det en användare ser i sin egen certifikatdialog:
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfterEtt certifikat som ser korrekt ut i användarens arkiv kan helt saknas i maskinarkivet. Enhetstunneln misslyckas då med autentiseringen innan inloggningsskärmen visas, och ingen ny import av profilen ändrar det. Kontrollera arkivet som tjänsten använder, inte det användaren ser.
En schemalagd uppgift som SYSTEM är inte funktionen
Det cirkulerar en kringgång som startar en VPN-profil från en schemalagd uppgift som körs som SYSTEM, vilket gör att en tunnel visas strax efter start. Det är inte den inbyggda enhetstunneln. Uppgiftsmotorn startar vid en annan tidpunkt, anslutningen är en profil i användarläge som startas av ett tjänstekonto, och livscykeln matchar inte en maskinautentiserad tunnel som måste finnas på inloggningsskärmen.
Den kan klara ett ytligt test eftersom tunneln är uppe när någon loggar in och kontrollerar. Den framgången mäter fördröjningen mellan start och uppgift, inte anslutningen före inloggning, och den lämnar maskinen utan tunnel under det fönster som funktionen skulle täcka.
Behandla kringgången som ej stödd för produktion. Om en design är beroende av den är kravet förmodligen en anslutning före inloggning, vilket för diskussionen tillbaka till utgåvans behörighet.
Välj kravet före tekniken
Skriv kravet som en mening: enheten måste nå en namngiven resurs innan någon användare loggar in, eller så behöver användaren åtkomst efter inloggning. Om den andra meningen är sann är en Always On-användartunnel på Pro en stödd design och enhetstunneln onödig komplexitet.
Om den första meningen är sann är utgåvan en hård port. Välj en behörig utgåva eller en dokumenterad arkitektur före inloggning som organisationen stöder, och planera licensändringen innan du bygger profiler och certifikat kring en förmåga som maskinen inte kan köra.
Anteckna utgåvan, domänanslutningsstatus, certifikatets plats och etableringskanalen i distributionsanteckningarna. Nästa ingenjör kan då bekräfta behörigheten på minuter i stället för att upprepa samma profilfelsökning på en maskin som aldrig skulle ha anslutit.