Always On VPN nėra LAN prieiga: išteklių kontrolinis sąrašas

Always On yra ryšio gyvavimo ciklas: profilis prisijungia prisijungiant arba prieš tai ir vėl prisijungia pačiam vartotojui nieko nespausdant. Tai nereiškia, kad leidžiama kiekviena privati paskirtis, protokolas ir vartotojas. Praktinis klausimas yra, kokius išteklius diegtas profilis iš tikrųjų pristato, ir tam reikia patikros pagal kiekvieną išteklių, o ne žvilgsnio į Connected žymą.

1 žingsnis: užsirašykite išteklių prieš jį tikrindami

Pradėkite nuo trumpo įrašo kiekvienai programai, paimto iš tikros aplinkos: pavadinimas, paskirties priešdėlis, paslauga ir prievadas, tunelio vaidmuo, tapatybės grupė ir resolverio kelias.

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

Įrašas verčia kelti keturis atskirus klausimus. Maršrutas nusprendžia, kur eina adresas; DNS politika nusprendžia, kaip klientas sužino adresą; srauto filtras nusprendžia, ar tas srautas gali naudoti ryšį; paskirties ugniasienė ir programos leidimai nusprendžia, ar užklausa bus priimta. Nė vienas iš keturių neišplaukia iš prisijungto tunelio.

2 žingsnis: nustatykite, kuris tunelis turi jį nešti

Windows Always On VPN turi įrenginio tunelį ir vartotojo tunelį, sukonfigūruotus kaip atskiri profiliai su atskirais sertifikatais ir apimtimis. Įrenginio tunelis paprastai neša tik infrastruktūrą, reikalingą prieš prisijungimą, pavyzdžiui, valdymą ir domeno paslaugas; platus darbuotojų programų pasiekiamumas priklauso vartotojo tuneliui.

Srauto filtrai yra įrenginio tunelio funkcija, todėl Microsoft pavyzdys juos naudoja valdymo srautui. Nukopijavus tą pavyzdį į bendrą išteklių profilį gaunamas tunelis, kuris prisijungia, bet neša netinkamą rinkinį. Patvirtinkite aktyvų ryšį su Get-VpnConnection ir tikrinkite būtent tuo ryšiu.

3 žingsnis: patikrinkite maršrutą tikram adresui

Išspręskite vardą vieną kartą, tada patikrinkite maršrutą: Find-NetRoute -RemoteIPAddress 10.20.5.10 parodo pasirinktą sąsają, kitą šuolį ir šaltinio adresą. Jei sąsaja yra fizinis adapteris, priešdėlio nėra tunelio maršrutų rinkinyje arba klientas jį pašalino skaidytu tuneliu. Palyginkite su profilio aprašu, o ne pridėkite vietinį maršrutą.

Vietinis route add gali leisti testui praeiti ir išnykti kitą kartą atnaujinant politiką, todėl pakeitimas priklauso valdomam profiliui. Patikrinkite priešdėlį vartotojo ir įrenginio profiliuose bei skaidyto tunelio nustatymą: pilnam tuneliui nereikia maršruto kiekvienam priešdėliui, skaidytam reikia vieno kiekvienam privačiam priešdėliui.

4 žingsnis: atskirai patikrinkite privačių vardų sprendimą

Privatūs vardai turi savo politikos kelią. Profilis gali pateikti NRPT taisykles ir DNS priesagos paieškos sąrašą, galiojančius, kol tunelis pakeltas. Perskaitykite su Get-DnsClientNrptPolicy, ką klientas tikrai gavo, tada toje pačioje sesijoje patikrinkite vardą ir adresą. Jei vardai krenta, o adresai veikia, kaltas resolveris; jei abu, maršrutas.

Vardas gali išsispręsti ir į adresą už tunelio maršrutų, o tai sumaišo sėkmę su laukimo pabaiga. Palyginkite grąžintą adresą su įrašo priešdėliu; jei jie skiriasi, privati zona atsako viešu arba alternatyviu adresu, o sutapęs maršrutas nėra suprojektuotasis.

5 žingsnis: patikrinkite filtrus, tapatybę ir pačios programos vartus

Srauto filtrai riboja, kurie protokolai ir prievadai gali naudoti įrenginio tunelį, o siauras rinkinys gali užblokuoti išteklių, kurį maršrutas neštų. Profilis priskiria ryšį grupei, bet išteklius turi savo autorizaciją: vartotojas, kuris gali prisijungti, nebūtinai priimamas failų serverio.

Keiskite valdomą profilį per jo savininką, ar tai būtų Intune, ProfileXML diegimas ar operacijų scenarijus, tada pakartokite testą po įprasto prisijungimo iš naujo ir po perkrovimo: įprasta klaida yra pasenęs vietinis maršrutas arba vieną kartą pritaikytas profilis. Laikykite profilio versiją šalia testo rezultato.