Always On VPN није приступ LAN-у: контролна листа ресурса

Always On је животни циклус везе: профил се повезује при или пре пријаве и поново се повезује без икаквог притиска корисника. То не значи да су дозвољени свако приватно одредиште, протокол и корисник. Практично питање је које ресурсе распоређени профил заиста испоручује, а одговор тражи проверу по ресурсу, а не поглед на значку Connected.

Корак 1: Запишите ресурс пре тестирања

Почните са кратким записом по апликацији, преузетим из стварног окружења: назив, префикс одредишта, сервис и порт, улога тунела, група идентитета и путања разрешивача.

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

Запис намеће четири одвојена питања. Рута одлучује куда иде адреса; DNS политика одлучује како клијент сазнаје адресу; филтер саобраћаја одлучује сме ли тај саобраћај да користи везу; заштитни зид одредишта и дозволе апликације одлучују хоће ли захтев бити прихваћен. Ништа од тога не следи из повезаног тунела.

Корак 2: Одредите који тунел треба да га носи

Windows Always On VPN има тунел уређаја и кориснички тунел, конфигурисане као одвојени профили са одвојеним сертификатима и обухватима. Тунел уређаја обично носи само инфраструктуру потребну пре пријаве, попут управљања и доменских сервиса; широк приступ запослених апликацијама припада корисничком тунелу.

Филтери саобраћаја су функција тунела уређаја, зато Microsoft-ов пример њима покрива управљачки саобраћај. Копирање тог примера у општи профил приступа ресурсима даје тунел који се повезује али носи погрешан скуп. Проверите активну везу помоћу Get-VpnConnection и тестирајте под том везом.

Корак 3: Проверите руту за стварну адресу

Разрешите назив једном, затим проверите руту: Find-NetRoute -RemoteIPAddress 10.20.5.10 приказује изабрани интерфејс, следећи скок и изворну адресу. Ако је интерфејс физички адаптер, префикс недостаје у скупу рута тунела или га је клијент искључио кроз подељени тунел. Упоредите са дефиницијом профила уместо да додајете локалну руту.

Локална route add може учинити да тест прође и нестати при следећем освежавању политике, зато промена припада управљаном профилу. Проверите префикс у корисничком и профилу уређаја, и проверите подешавање подељеног тунела: пуни тунел не треба руту по префиксу, подељени треба једну за сваки приватни префикс.

Корак 4: Тестирајте разрешавање приватних назива одвојено

Приватни називи имају сопствену путању политике. Профил може испоручити NRPT правила и листу за претрагу DNS наставака, важећу док је тунел повезан. Прочитајте помоћу Get-DnsClientNrptPolicy шта је клијент заиста примио, па тестирајте назив и адресу у истој сесији. Називи који падају док адресе раде упућују на разрешивач; обоје што пада упућује на руту.

Назив се може разрешити и у адресу изван рута тунела, што меша успех и истек времена. Упоредите враћену адресу са префиксом у запису; ако се разликују, приватна зона одговара јавном или алтернативном адресом и рута која се поклопила није пројектована.

Корак 5: Проверите филтере, идентитет и сопствена врата апликације

Филтери саобраћаја ограничавају који протоколи и портови смеју користити тунел уређаја, а узак скуп може блокирати ресурс који би рута носила. Профил додељује везу групи, али ресурс има сопствену ауторизацију: корисник који може да се повеже није аутоматски прихваћен на серверу датотека.

Мењајте управљани профил кроз његовог власника, било Intune, ProfileXML имплементацију или оперативну скрипту, па поново тестирајте након нормалног поновног повезивања и након рестарта: уобичајени квар је застарела локална рута или профил примењен само једном. Држите верзију профила уз резултат теста.