Always On VPN is nie LAN-toegang nie: ’n kontrolelys per hulpbron

Always On is ’n verbindingslewensiklus: die profiel koppel by of voor aanmelding en herkoppel sonder dat die gebruiker iets hoef te doen. Dit beteken nie dat elke private bestemming, protokol en gebruiker toegelaat word nie. Die praktiese vraag is watter hulpbronne die ontplooide profiel werklik lewer, en dié antwoord vereis ’n kontrole per hulpbron, nie ’n blik op die Connected-kenteken nie.

Stap 1: Skryf die hulpbron neer voordat jy dit toets

Begin met een kort rekord per program, uit die werklike omgewing: naam, bestemmingsprefiks, diens en poort, tonnelrol, identiteitsgroep en resolver-pad.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Die rekord dwing vier afsonderlike vrae af. ’n Roete bepaal waar die adres heen gaan; DNS-beleid bepaal hoe die kliënt die adres leer; ’n verkeersfilter bepaal of daardie verkeer die verbinding mag gebruik; die bestemming se firewall en programtoestemmings bepaal of die versoek aanvaar word. Nie een van die vier volg uit ’n gekoppelde tonnel nie.

Stap 2: Bepaal watter tonnel dit moet dra

Windows Always On VPN het ’n toesteltonnel en ’n gebruikerstonnel, wat as aparte profiele met aparte sertifikate en omvang gekonfigureer word. Die toesteltonnel dra gewoonlik net infrastruktuur voor aanmelding soos bestuur en domeindienste; breë programtoegang vir werknemers hoort by die gebruikerstonnel.

Verkeersfilters is ’n kenmerk van die toesteltonnel, en daarom gebruik Microsoft dit vir bestuursverkeer. Kopieer jy daardie voorbeeld na ’n algemene hulpbronprofiel, kry jy ’n tonnel wat koppel maar die verkeerde stel dra. Bevestig die aktiewe verbinding met Get-VpnConnection en toets onder daardie verbinding.

Stap 3: Verifieer die roete vir die werklike adres

Los die naam een keer op en kontroleer dan die roete: Find-NetRoute -RemoteIPAddress 10.20.5.10 wys die gekose koppelvlak, volgende sprong en bronadres. Is die koppelvlak die fisiese adapter, dan ontbreek die prefiks in die tonnel se roetestel, of die kliënt het dit deur split-tunnelling uitgesluit. Vergelyk met die profieldefinisie eerder as om ’n plaaslike roete by te voeg.

’n Plaaslike route add kan die toets laat slaag en by die volgende beleidsverfrissing verdwyn, daarom hoort die wysiging in die bestuurde profiel. Kontroleer die prefiks in beide die gebruiker- en toestelprofiel, en kyk na die split-tunnel-instelling: vol tonnel het geen roete per prefiks nodig nie, split-tonnel een vir elke private prefiks.

Stap 4: Toets private naamoplossing apart

Private name het ’n eie beleidspad. Die profiel kan NRPT-reëls en ’n DNS-agtervoegsellys lewer, geldig terwyl die tonnel op is. Lees met Get-DnsClientNrptPolicy wat die kliënt ontvang het, en toets dan ’n naam en ’n adres in dieselfde sessie. Name wat faal terwyl adresse werk, wys na die resolver; albei wat faal, wys na die roete.

’n Naam kan ook na ’n adres buite die tonnelroetes oplos, wat sukses en tydsverloop meng. Vergelyk die teruggegewe adres met die prefiks in jou rekord; verskil hulle, antwoord die private sone met ’n openbare of alternatiewe adres en is die pasgemaakte roete nie die ontwerpte een nie.

Stap 5: Kontroleer filters, identiteit en die program se eie hek

Verkeersfilters beperk watter protokolle en poorte die toesteltonnel mag gebruik, en ’n smal stel kan ’n hulpbron blokkeer wat die roete sou dra. Die profiel wys die verbinding aan ’n groep toe, maar die hulpbron het sy eie magtiging: iemand wat kan koppel, word nie outomaties deur die lêerbediener aanvaar nie.

Verander die bestuurde profiel deur sy eienaar, of dit Intune, ’n ProfileXML-ontplooiing of ’n bedryfskrip is, en toets weer ná ’n normale herkoppeling en ná ’n herlaai: die gewone fout is ’n verouderde plaaslike roete of ’n profiel wat een keer toegepas is. Hou die profielweergawe langs die toetsresultaat.