Profilul ajunge pe laptop, pagina de setări VPN îl afișează, iar tunelul de dispozitiv tot nu se conectează niciodată pe ecranul de conectare. În Windows Pro acesta nu este adesea o eroare de configurare. Tunelul de dispozitiv nativ este licențiat în funcție de ediție, iar un tunel de utilizator care funcționează după conectare dovedește o altă capacitate. Citiți cerința înainte de a depana certificatul.

Simptomul apare înainte ca cineva să se conecteze

Un tunel de utilizator se conectează în contextul utilizatorului după autentificare, de aceea funcționează normal pe Pro. Un tunel de dispozitiv ar trebui să stabilească conectivitatea mașinii înainte ca vreun utilizator să se conecteze, folosind un certificat de mașină și IKEv2. Acestea sunt etape diferite ale ciclului de viață, nu două nume pentru același profil.

Pe o ediție neeligibilă profilul poate fi totuși implementat și listat, dar conexiunea dinaintea autentificării nu apare. După conectare, tunelul de utilizator poate funcționa perfect, ceea ce face implementarea să pară sănătoasă în fiecare verificare efectuată de proprietarul contului. Defecțiunea este invizibilă din interiorul unei sesiuni deja conectate.

Punerea unui profil la dispoziția tuturor utilizatorilor schimbă cine îl poate folosi. Nu schimbă contextul de autentificare de la utilizator la mașină, așa că nu poate transforma un tunel de utilizator într-un tunel de dispozitiv. Diferența este contextul de autentificare, nu vizibilitatea profilului.

Citiți matricea, nu doar nodul CSP

Matricea de funcții Windows 11 de la Microsoft listează tunelul de dispozitiv Always On VPN nativ pentru Enterprise și Education. Furnizorul serviciului de configurare VPNv2 documentează separat un nod DeviceTunnel a cărui aplicabilitate include Pro, iar acea linie este adesea citată ca dovadă că funcția funcționează. Suprafața de configurare și licențierea funcției răspund la întrebări diferite: una spune că o setare poate fi exprimată, cealaltă că ediția are dreptul la capacitate.

Confirmați ediția și compilarea efective în loc să vă bazați pe înregistrarea achiziției. Activarea gestionată, o actualizare în curs sau o imagine reconstruită pot lăsa o mașină pe o altă ediție decât cea din lista de active:

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

Dacă rezultatul spune Pro, tunelul de dispozitiv nativ este în afara setului de funcții documentat pentru acea mașină. Această concluzie nu necesită o modificare de profil și nu va fi corectată de una. Notați această constatare înainte de a schimba orice altceva.

Patru cerințe din spatele indicatorului de funcție

Ediția este poarta, iar celelalte cerințe explică de ce o mașină pe o ediție eligibilă tot eșuează. Verificați-le în ordine, deoarece fiecare poate produce același rezultat silențios. Sărirea unui rând irosește efortul depus pentru rândurile de dedesubt. Ediția vine prima dintr-un motiv.

PrerequisiteHow to verifyCommon failure
Edition and buildDISM /online /get-currenteditionPro image with an Enterprise asset record
Join stateDomain membership in system informationMicrosoft Entra join treated as domain join
Machine certificateCertificate store in the local machine contextCertificate issued to the user store
Profile contextProvisioned through the machine channelDelivered as a user tunnel profile

Verificarea certificatului este cea pe care oamenii o sar. Cheia privată trebuie să fie prezentă în magazinul mașinii și utilizabilă de contextul sistemului înainte de conectare, ceea ce este un magazin diferit de cel pe care un utilizator îl vede în propriul dialog de certificate:

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

Un certificat care pare corect în magazinul utilizatorului poate fi complet absent din magazinul mașinii. Tunelul de dispozitiv eșuează atunci autentificarea înainte de apariția ecranului de conectare, iar nicio reimportare a profilului nu schimbă asta. Verificați magazinul folosit de serviciu, nu pe cel văzut de utilizator.

O sarcină programată ca SYSTEM nu este funcția

Circulă o soluție ocolitoare care lansează un profil VPN dintr-o sarcină programată rulează ca SYSTEM, astfel încât un tunel apare la scurt timp după pornire. Nu este tunelul de dispozitiv nativ. Motorul de sarcini pornește într-un alt moment, conexiunea este un profil în modul utilizator lansat de un cont de serviciu, iar ciclul de viață nu corespunde unui tunel autentificat de mașină care trebuie să existe pe ecranul de conectare.

Poate trece un test superficial pentru că tunelul este activ până când cineva se conectează și verifică. Acel succes măsoară întârzierea dintre pornire și sarcină, nu conectivitatea dinaintea autentificării, și lasă mașina fără tunel în fereastra pe care funcția ar fi trebuit să o acopere.

Tratați soluția ocolitoare ca neacceptată pentru producție. Dacă un proiect depinde de ea, cerința este probabil o conexiune înainte de autentificare, ceea ce readuce discuția la eligibilitatea ediției.

Alegeți cerința înainte de tehnologie

Scrieți cerința într-o propoziție: dispozitivul trebuie să atingă o resursă numită înainte ca vreun utilizator să se conecteze, sau utilizatorul are nevoie de acces după conectare. Dacă a doua propoziție este adevărată, un tunel de utilizator Always On pe Pro este un proiect acceptat, iar tunelul de dispozitiv este o complexitate inutilă.

Dacă prima propoziție este adevărată, ediția este o poartă dură. Alegeți o ediție eligibilă sau o arhitectură documentată dinaintea autentificării pe care organizația o acceptă și planificați schimbarea licenței înainte de a construi profiluri și certificate în jurul unei capacități pe care mașina nu o poate rula.

Notați ediția, starea de înscriere, locația certificatului și canalul de provizionare în notele de implementare. Următorul inginer va putea apoi confirma eligibilitatea în câteva minute în loc să repete aceeași depanare a profilului pe o mașină care nu s-ar fi conectat niciodată.

Articole similare