Always On VPN není přístup do LAN: kontrolní seznam zdrojů

Always On je životní cyklus připojení: profil se připojí při přihlášení nebo před ním a znovu se připojí, aniž by uživatel cokoli stiskl. Neznamená to, že je povolen každý privátní cíl, protokol a uživatel. Praktická otázka je, které zdroje nasazený profil skutečně doručí, a odpověď vyžaduje kontrolu po jednotlivých zdrojích, ne pohled na odznak Připojeno.

Krok 1: Zapište zdroj dřív, než ho otestujete

Začněte krátkým záznamem pro každou aplikaci, převzatým z reálného prostředí: název, prefix cíle, služba a port, role tunelu, skupina identity a cesta překladače.

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

Záznam vynutí čtyři oddělené otázky. Trasa rozhoduje, kam adresa jde; zásady DNS rozhodují, jak se klient adresu dozví; filtr provozu rozhoduje, zda tento provoz smí použít připojení; firewall cíle a oprávnění aplikace rozhodují, zda bude požadavek přijat. Nic z toho nevyplývá z připojeného tunelu.

Krok 2: Určete, který tunel to má nést

Windows Always On VPN má tunel zařízení a uživatelský tunel, konfigurované jako samostatné profily se samostatnými certifikáty a rozsahy. Tunel zařízení obvykle nese jen infrastrukturu potřebnou před přihlášením, například správu a doménové služby; široký přístup zaměstnanců k aplikacím patří uživatelskému tunelu.

Filtry provozu jsou funkcí tunelu zařízení, proto je příklad Microsoftu používá pro provoz správy. Zkopírování tohoto příkladu do obecného profilu přístupu ke zdrojům dá tunel, který se připojí, ale nese špatnou sadu. Ověřte aktivní připojení pomocí Get-VpnConnection a testujte pod ním.

Krok 3: Ověřte trasu pro skutečnou adresu

Přeložte název jednou a pak zkontrolujte trasu: Find-NetRoute -RemoteIPAddress 10.20.5.10 hlásí zvolené rozhraní, další skok a zdrojovou adresu. Pokud je rozhraním fyzický adaptér, prefix v sadě tras tunelu chybí nebo ho klient vyloučil rozděleným tunelem. Porovnejte s definicí profilu, místo abyste přidávali místní trasu.

Místní route add může test nechat projít a při další obnově zásad zmizet, proto změna patří do spravovaného profilu. Zkontrolujte prefix v uživatelském i v profilu zařízení a nastavení rozděleného tunelu: plný tunel nepotřebuje trasu pro každý prefix, rozdělený potřebuje jednu pro každý privátní prefix.

Krok 4: Otestujte překlad privátních názvů zvlášť

Privátní názvy mají vlastní cestu zásad. Profil může doručit pravidla NRPT a seznam hledaných přípon DNS, platné po dobu připojení tunelu. Přečtěte pomocí Get-DnsClientNrptPolicy, co klient skutečně dostal, a pak otestujte název i adresu v téže relaci. Když názvy selhávají a adresy fungují, jde o překladač; když obojí, o trasu.

Název se také může přeložit na adresu mimo trasy tunelu, což míchá úspěch s vypršením. Porovnejte vrácenou adresu s prefixem v záznamu; pokud se liší, privátní zóna odpovídá veřejnou nebo alternativní adresou a odpovídající trasa není ta navržená.

Krok 5: Zkontrolujte filtry, identitu a vlastní bránu aplikace

Filtry provozu omezují, které protokoly a porty smějí tunel zařízení používat, a úzká sada může zablokovat zdroj, který by trasa nesla. Profil přiřadí připojení skupině, ale zdroj má vlastní autorizaci: uživatel, který se připojí, nemusí být souborovým serverem přijat.

Měňte spravovaný profil přes jeho vlastníka, ať je to Intune, nasazení ProfileXML nebo skript provozu, a poté testujte znovu po běžném opětovném připojení a po restartu: obvyklá závada je zastaralá místní trasa nebo profil aplikovaný jednou. Uchovávejte verzi profilu vedle výsledku testu.