Tunel urządzenia w Windows Pro? Sprawdź matrycę wersji
Wdrożony profil nie dowodzi uprawnień. Porównaj matrycę wersji, węzeł CSP i wymagania przed logowaniem, zanim zaczniesz debugować tunel.
Profil trafia na laptopa, strona ustawień VPN go pokazuje, a tunel urządzenia nadal nigdy nie łączy się na ekranie logowania. W Windows Pro to często nie jest błąd konfiguracji. Natywny tunel urządzenia jest licencjonowany według wersji, a tunel użytkownika działający po zalogowaniu dowodzi innej możliwości. Przeczytaj wymaganie, zanim zaczniesz debugować certyfikat.
Objaw pojawia się, zanim ktokolwiek się zaloguje
Tunel użytkownika łączy się w kontekście użytkownika po zalogowaniu, dlatego działa normalnie w Pro. Tunel urządzenia ma nawiązać łączność maszyny, zanim zaloguje się jakikolwiek użytkownik, przy użyciu certyfikatu maszyny i IKEv2. To są różne etapy cyklu życia, a nie dwie nazwy tego samego profilu.
W nieodpowiedniej wersji profil nadal można wdrożyć i wyświetlić na liście, ale połączenie przed logowaniem nie pojawia się. Po zalogowaniu tunel użytkownika może działać bezbłędnie, przez co wdrożenie wygląda zdrowo w każdym sprawdzeniu wykonywanym przez właściciela konta. Awaria jest niewidoczna z wnętrza sesji, w której ktoś już się zalogował.
Udostępnienie profilu wszystkim użytkownikom zmienia to, kto może go używać. Nie zmienia kontekstu uwierzytelniania z użytkownika na maszynę, więc nie może zamienić tunelu użytkownika w tunel urządzenia. Różnica dotyczy kontekstu uwierzytelniania, a nie widoczności profilu.
Czytaj matrycę, nie tylko węzeł CSP
Matryca funkcji Windows 11 firmy Microsoft wymienia natywny tunel urządzenia Always On VPN dla wersji Enterprise i Education. Dostawca usługi konfiguracji VPNv2 osobno dokumentuje węzeł DeviceTunnel, którego zakres obejmuje Pro, i ten wiersz jest często cytowany jako dowód, że funkcja działa. Powierzchnia konfiguracji i licencjonowanie funkcji odpowiadają na różne pytania: jedno mówi, że ustawienie można wyrazić, drugie, że wersja ma prawo do tej możliwości.
Potwierdź rzeczywistą wersję i kompilację, zamiast ufać zapisowi zakupu. Aktywacja zarządzana, trwająca aktualizacja lub odtworzony obraz mogą pozostawić maszynę w innej wersji niż podana na liście zasobów:
winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumberJeśli dane wyjściowe mówią Pro, natywny tunel urządzenia jest poza udokumentowanym zestawem funkcji dla tej maszyny. Ten wniosek nie wymaga zmiany profilu i nie zostanie przez nią naprawiony. Zapisz to ustalenie, zanim zmienisz cokolwiek innego.
Cztery wymagania za flagą funkcji
Wersja jest bramą, a pozostałe wymagania wyjaśniają, dlaczego maszyna w odpowiedniej wersji nadal zawodzi. Sprawdzaj je po kolei, ponieważ każde może dać ten sam cichy wynik. Pominięcie wiersza marnuje wysiłek włożony w wiersze poniżej. Wersja jest pierwsza nie bez powodu.
| 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 |
Sprawdzenie certyfikatu jest tym, które ludzie pomijają. Klucz prywatny musi znajdować się w magazynie maszyny i być użyteczny dla kontekstu systemu przed logowaniem, co jest innym magazynem niż ten, który użytkownik widzi w swoim oknie certyfikatów:
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfterCertyfikat, który wygląda poprawnie w magazynie użytkownika, może całkowicie nie występować w magazynie maszyny. Tunel urządzenia nie przechodzi wtedy uwierzytelniania, zanim pojawi się ekran logowania, i żaden ponowny import profilu tego nie zmieni. Sprawdzaj magazyn używany przez usługę, a nie ten, który widzi użytkownik.
Zaplanowane zadanie jako SYSTEM nie jest tą funkcją
Krąży obejście, które uruchamia profil VPN z zaplanowanego zadania działającego jako SYSTEM, przez co tunel pojawia się wkrótce po rozruchu. To nie jest natywny tunel urządzenia. Silnik zadań startuje w innym momencie, połączenie jest profilem w trybie użytkownika uruchomionym przez konto usługi, a cykl życia nie odpowiada tunelowi uwierzytelnionemu przez maszynę, który musi istnieć na ekranie logowania.
Może przejść powierzchowny test, ponieważ tunel działa już, gdy ktoś się loguje i sprawdza. Ten sukces mierzy opóźnienie między rozruchem a zadaniem, a nie łączność przed logowaniem, i pozostawia maszynę bez tunelu w oknie, które funkcja miała obejmować.
Traktuj obejście jako nieobsługiwane w produkcji. Jeśli projekt od niego zależy, wymaganiem jest prawdopodobnie połączenie przed logowaniem, co wraca do kwestii uprawnień wersji.
Wybierz wymaganie przed technologią
Zapisz wymaganie w jednym zdaniu: urządzenie musi dotrzeć do nazwanego zasobu, zanim zaloguje się jakikolwiek użytkownik, albo użytkownik potrzebuje dostępu po zalogowaniu. Jeśli drugie zdanie jest prawdziwe, tunel użytkownika Always On w Pro jest obsługiwanym projektem, a tunel urządzenia to niepotrzebna złożoność.
Jeśli pierwsze zdanie jest prawdziwe, wersja jest twardą bramą. Wybierz odpowiednią wersję lub udokumentowaną architekturę przed logowaniem, którą organizacja obsługuje, i zaplanuj zmianę licencji, zanim zbudujesz profile i certyfikaty wokół możliwości, której maszyna nie może uruchomić.
Zapisz wersję, stan przyłączenia do domeny, lokalizację certyfikatu i kanał aprowizacji w notatkach wdrożeniowych. Następny inżynier będzie mógł wtedy potwierdzić uprawnienia w kilka minut, zamiast powtarzać to samo rozwiązywanie problemów z profilem na maszynie, która nigdy by się nie połączyła.