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 или операциска скрипта, потоа тестирајте повторно по нормално повторно поврзување и по рестарт: вообичаената грешка е застарена локална рута или профил применет само еднаш. Чувајте ја верзијата на профилот покрај резултатот од тестот.