Co skonfigurować z góry przed pierwszym połączeniem VPN użytkownika

Pierwsze połączenie VPN rzadko zawodzi na tunelu. Zawodzi, gdy zwykły użytkownik w niezarządzanej sieci wykonuje instrukcje napisane przez kogoś, kto miał już zainstalowany certyfikat. Profil, łańcuch zaufania i dane logowania to konfiguracja, a wszystkie trzy można dostarczyć, zanim użytkownik zostanie w to wciągnięty. Dla tego użytkownika powinny zostać cztery czynności bez żadnych decyzji w środku. Każdy dodatkowy krok zostawiony w przekazaniu staje się zgłoszeniem do pomocy, które zaczyna się od kogoś czytającego na głos okno dialogowe.

Co naprawdę zawiera profil połączenia

Profil VPN to nie skrót ani zakładka. To nazwany obiekt w magazynie połączeń systemu operacyjnego, zawierający adres serwera, typ tunelu, metodę uwierzytelniania, a często także trasy, sufiksy DNS i reguły wyzwalania, które decydują, kiedy się łączy. W Windows te pola odpowiadają węzłom dostawcy usługi konfiguracji VPNv2, dlatego jeden profil może trafić przez Intune, Configuration Manager, pakiet aprowizacji lub ręcznie zaimportowany plik XML.

Klient stosuje ten obiekt w ustalonej kolejności: sprawdza certyfikat serwera wobec zaufanych głównych ośrodków, negocjuje tunel i dopiero potem stosuje routing oraz rozwiązywanie nazw, zanim aplikacja zobaczy sieć. Ta kolejność wyjaśnia większość zgłoszeń o połączeniu, które twierdzi, że jest aktywne, podczas gdy nic się nie wczytuje: uwierzytelnianie się powiodło, a naprawdę zawiodły DNS lub lista tras. Czytaj profil jako jeden obiekt z sekwencją, a nie jako zestaw niezależnych przełączników. Brakujący główny ośrodek zaufania zawodzi już w pierwszym kroku, przed zaproponowaniem jakichkolwiek danych logowania, dlatego daje ogólny błąd zamiast prośby o zalogowanie.

Materiał zaufania to pole, które najczęściej przemyca się ręcznie. Certyfikat CA podpisujący bramę musi być obecny przed pierwszą próbą, a walidacja nazwy serwera musi pozostać włączona z pasującą nazwą; wyłączenie walidacji, aby test przeszedł, zamienia problem uwierzytelniania w ciche przechwycenie, którego żaden użytkownik nie wykryje.

Cztery wybory, których użytkownicy nigdy nie powinni podejmować

Protokół i typ tunelu są pierwsze: wybierz jedną obsługiwaną kombinację na platformę i udokumentuj stronę bramy, bo znana nazwa marki nie jest oświadczeniem o zgodności. Następnie punkt końcowy: jedna nazwa hosta, która rozwiązuje się publicznie i pasuje do certyfikatu przedstawianego przez bramę. Uwierzytelnianie należy do systemu tożsamości, czy to certyfikat, nazwa użytkownika z drugim składnikiem, czy oba. Żaden z tych elementów nie jest preferencją użytkownika i żaden nie powinien pojawiać się jako pytanie w instrukcji.

Czwarty wybór to zakres: tunel pełny albo tunel dzielony, oraz które prefiksy i sufiksy DNS podróżują w środku. Tunel dzielony bez sufiksów wewnętrznych wycieka rozwiązywanie nazw do dowolnego resolvera oferowanego przez sieć lokalną, a tunel pełny bez planu zasobów lokalnych psuje drukarki i portale przechwytujące. Oba są decyzjami administratora o skutkach widocznych dla użytkownika, i właśnie dlatego użytkownik powinien otrzymać je już rozstrzygnięte.

Trzymaj nazwę połączenia nudną i stabilną. Użytkownicy czytają ją na głos pomocy, szukają jej na liście klienta i pamiętają między resetami hasła; zmiana jej w trakcie migracji tworzy skok zgłoszeń, który nie ma nic wspólnego z tym, czy VPN działa.

Dostarczaj tożsamość na osobę albo na urządzenie

Profil jest publiczny, a klucz prywatny nie. Częstym błędem wdrożenia jest wyeksportowanie jednego działającego profilu razem z jego certyfikatem i przekazywanie pliku z rąk do rąk, co czyni każdy laptop klonem jednej tożsamości i zmienia unieważnienie w decyzję wszystko-albo-nic. Rejestruj dane logowania zgodnie z obsługiwanym procesem: certyfikat na urządzenie z kanału zarządzania albo dane logowania na użytkownika od dostawcy tożsamości.

Tunele urządzeń i tunele użytkowników uwierzytelniają się w różnych momentach, a ta różnica decyduje, jakich danych logowania potrzebujesz. Tunel urządzenia łączący się przed zalogowaniem wymaga certyfikatu maszyny i profilu dostępnego dla systemu. Tunel użytkownika uruchamiany po zalogowaniu może użyć własnych danych logowania użytkownika i nie powinien wymagać uprawnień administratora. Dodawanie dostępu sieciowego na poziomie maszyny tylko po to, by usunąć jedno kliknięcie z czyjegoś poranka, to zła wymiana, bo poszerza to, do czego może dotrzeć urządzenie bez nadzoru.

Rejestracja to także miejsce, w którym rozstrzyga się ścieżka odzyskiwania. Odnowienie certyfikatu lub zmiana hasła musi dotrzeć do urządzenia, gdy tunel leży, więc aprowizacja, dostawca tożsamości i brama muszą uzgodnić, jak to się dzieje; jeśli jedynym sposobem naprawy profilu jest tunel, który ten profil zapewnia, klucz jest zamknięty w pudełku.

Dopasuj kanał dostarczania do klienta

Klienci natywni i firm trzecich są dostarczani różnie. Profile Windows można dostarczać jako VPNv2 ProfileXML przez Intune lub Configuration Manager, ale nie każdy węzeł jest wystawiony na każdej powierzchni zarządzania, a ustawienia routingu, DNS i wyzwalania różnią się w zależności od narzędzia i wersji Windows. Potwierdź, które pole da się wdrożyć, zanim obiecasz wdrożenie bezdotykowe, bo odnośnik do opcji profilu dokumentuje ustawienia, których niektóre ścieżki dostarczania wciąż nie potrafią ustawić.

Klienci dostawców dokładają drugą warstwę, ponieważ plik binarny, profil i polityka koncentratora to osobne artefakty. Cisco Secure Client na przykład obsługuje wstępne wdrożenie zarówno pakietu, jak i jego profilu, a wersję klienta trzeba skoordynować z konfiguracją bramy; zainstalowanie samego pakietu zostawia użytkownika w kreatorze.

Niezależnie od wybranego kanału trzymaj jedno źródło prawdy dla profilu. Naprawiony profil, który starszy pakiet nadpisuje przy następnym sprawdzeniu, to powracający incydent, a trwałym rozwiązaniem jest konfiguracja wersjonowana, a nie ręczna edycja na każdej maszynie.

Przetestuj przekazanie jako nowy użytkownik, a potem przetestuj odzyskiwanie

Zrób pilotaż ze zwykłym kontem na urządzeniu, które nigdy się nie łączyło, bez zapisanej sesji administratora i bez wcześniej zarejestrowanego certyfikatu. Potwierdź, że profil pojawia się na liście, prośba o zalogowanie pasuje do instrukcji, a nazwany zasób wewnętrzny się otwiera, potem sprawdź rozwiązywanie nazw i zakres routingu, zamiast zatrzymywać się na ikonie połączenia.

Odpytaj magazyn profili urządzenia, aby test dawał dowody, a nie wrażenie.

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType, AuthenticationMethod, SplitTunneling
Get-VpnConnection -Name "Corp VPN" | Format-List
Test-NetConnection intranet.example.com -Port 443

Potem przejdź przez zdarzenia, które użytkownicy naprawdę napotykają: wymuszony reset hasła, odnowiony certyfikat, wypchnięta aktualizacja klienta i sieć, której nikt w pilocie wcześniej nie używał. Każde powinno albo działać, albo zawieść tak, jak opisuje instrukcja. Spróbuj też sieci blokującej port VPN, bo pierwsza próba w Wi-Fi hotelowym to miejsce, gdzie sukces w domu przestaje pomagać. Zapisz wersję klienta i kompilację systemu obok każdego wyniku, ponieważ następny raport przyjdzie bez nich.

Trzymaj przekazanie dla użytkownika w czterech linijkach: nazwa połączenia, oczekiwane logowanie, zasób dowodzący sukcesu i gdzie wysłać treść błędu. Nikt nie powinien być proszony o hasło ani wyeksportowany klucz, aby pokazać awarię. Architektura, wnętrze profilu i procedura odzyskiwania należą do podręcznika administratora, złożonego obok wersji klienta, z którą je testowano.