Always On VPN to nie dostęp do LAN: lista kontrolna zasobów

Always On to cykl życia połączenia: profil łączy się przy lub przed zalogowaniem i wznawia połączenie bez żadnego działania użytkownika. Nie oznacza to, że każde prywatne miejsce docelowe, protokół i użytkownik są dozwolone. Praktyczne pytanie brzmi, jakie zasoby wdrożony profil naprawdę dostarcza, a odpowiedź wymaga sprawdzenia po zasobie, a nie spojrzenia na plakietkę Connected.

Krok 1: Zapisz zasób, zanim go przetestujesz

Zacznij od krótkiego wpisu dla każdej aplikacji, wziętego z rzeczywistego środowiska: nazwa, prefiks miejsca docelowego, usługa i port, rola tunelu, grupa tożsamości i ścieżka solvera.

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

Wpis wymusza cztery osobne pytania. Trasa decyduje, dokąd trafia adres; zasady DNS decydują, skąd klient zna adres; filtr ruchu decyduje, czy ten ruch może korzystać z połączenia; zapora i uprawnienia aplikacji w miejscu docelowym decydują, czy żądanie zostanie przyjęte. Żadne z tych czterech nie wynika z połączonego tunelu.

Krok 2: Ustal, który tunel ma go przenosić

Windows Always On VPN ma tunel urządzenia i tunel użytkownika, konfigurowane jako osobne profile z osobnymi certyfikatami i zakresami. Tunel urządzenia zwykle przenosi tylko infrastrukturę potrzebną przed zalogowaniem, na przykład zarządzanie i usługi domenowe; szeroki dostęp pracowników do aplikacji należy do tunelu użytkownika.

Filtry ruchu są funkcją tunelu urządzenia, dlatego przykład Microsoftu używa ich do ruchu zarządzania. Skopiowanie tego przykładu do ogólnego profilu zasobów daje tunel, który się łączy, ale przenosi zły zestaw. Potwierdź aktywne połączenie za pomocą Get-VpnConnection i testuj pod tym połączeniem.

Krok 3: Sprawdź trasę dla rzeczywistego adresu

Rozwiąż nazwę raz, a następnie sprawdź trasę: Find-NetRoute -RemoteIPAddress 10.20.5.10 pokazuje wybrany interfejs, następny skok i adres źródłowy. Jeśli interfejsem jest karta fizyczna, prefiksu nie ma w zestawie tras tunelu albo klient wyłączył go przez tunel dzielony. Porównaj z definicją profilu, zamiast dodawać trasę lokalną.

Lokalny route add może sprawić, że test przejdzie, i zniknąć przy następnym odświeżeniu zasad, dlatego zmiana należy do profilu zarządzanego. Sprawdź prefiks zarówno w profilu użytkownika, jak i urządzenia, oraz ustawienie tunelu dzielonego: pełny tunel nie potrzebuje trasy na prefiks, dzielony potrzebuje jednej dla każdego prywatnego prefiksu.

Krok 4: Przetestuj rozwiązywanie nazw prywatnych osobno

Nazwy prywatne mają własną ścieżkę zasad. Profil może dostarczyć reguły NRPT i listę wyszukiwania sufiksów DNS, ważne dopóki tunel jest aktywny. Odczytaj za pomocą Get-DnsClientNrptPolicy, co klient rzeczywiście otrzymał, a potem przetestuj nazwę i adres w tej samej sesji. Jeśli nazwy zawodzą, gdy adresy działają, winny jest solver; jeśli oba, trasa.

Nazwa może też rozwiązać się na adres spoza tras tunelu, co miesza sukces z przekroczeniem czasu. Porównaj zwrócony adres z prefiksem we wpisie; jeśli się różnią, strefa prywatna odpowiada adresem publicznym lub alternatywnym, a dopasowana trasa nie jest tą zaprojektowaną.

Krok 5: Sprawdź filtry, tożsamość i własną bramę aplikacji

Filtry ruchu ograniczają, które protokoły i porty mogą używać tunelu urządzenia, a wąski zestaw może zablokować zasób, który trasa by przenosiła. Profil przypisuje połączenie do grupy, ale zasób ma własną autoryzację: użytkownik, który może się połączyć, nie jest automatycznie akceptowany przez serwer plików.

Zmieniaj profil zarządzany przez jego właściciela, czy to Intune, wdrożenie ProfileXML, czy skrypt operacyjny, a potem testuj ponownie po normalnym ponownym połączeniu i po restarcie: typowa awaria to nieaktualna trasa lokalna albo profil zastosowany tylko raz. Trzymaj wersję profilu obok wyniku testu.