Uwierzytelnianie klienta Azure P2S: Entra, certyfikat czy RADIUS
Logowanie Entra, certyfikaty klienta i RADIUS wymagają różnych klientów i profili Azure VPN. Wybierz metodę, potem klienta, na końcu profil.
Instalator się uruchamia, profil importuje się, a połączenie kończy się niepowodzeniem na etapie logowania. Większość takich zgłoszeń nie jest błędem klienta: aplikacja zgodna z OpenVPN może przenosić tunel, a mimo to nie wiedzieć, jak wykonać logowanie Microsoft Entra. Kolejność, która pozwala uniknąć pętli, to metoda, potem klient, potem profil. Wybierz metodę uwierzytelniania, dla której skonfigurowana jest brama, wybierz klienta, którego Microsoft dokumentuje dla tej metody, i dopiero potem wygeneruj profil, którego oczekuje ten klient. Wszystko poniżej zachowuje tę kolejność.
Zacznij od metody, nie od instalatora
Brama jest skonfigurowana z jednym lub kilkoma typami tunelu i metodami uwierzytelniania. To ta para, a nie rozszerzenie pliku na pulpicie, decyduje, które klienty są obsługiwane.
Zapisz parę, zanim cokolwiek pobierzesz, bo macierz obsługi jest wąska, a zły start kosztuje popołudnie.
Oto mapowanie, które trzymam w notatkach wdrożeniowych:
| Authentication | Tunnel type | Documented client |
|---|---|---|
| Microsoft Entra ID | OpenVPN | Azure VPN Client on Windows and macOS |
| Client certificate | OpenVPN or IKEv2 | Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux |
| RADIUS | IKEv2 or OpenVPN, per the current matrix | Native IKEv2 client, strongSwan, or the OpenVPN client the matrix names |
Czytaj tę tabelę jako ograniczenie, nie jako menu. Każdy wiersz to udokumentowana kombinacja, a mieszanie klienta z jednego wiersza z metodą z innego to dokładnie ten błąd, któremu ten artykuł ma zapobiegać.
Entra ID oznacza OpenVPN plus Azure VPN Client
Dla uwierzytelniania Entra w połączeniu punkt-lokacja obsługiwany układ używa typu tunelu OpenVPN i Azure VPN Client. Ogólne okno nazwy użytkownika i hasła nie zastępuje tej integracji, a natywny IKEv2 systemu Windows nie jest wymiennym sposobem wykonania tego samego logowania. Jeśli klient innej firmy oferuje opcję Entra lub Azure AD, zweryfikuj ją w aktualnej dokumentacji Microsoft, a nie po etykiecie. Etykieta to marketing, a udokumentowana kombinacja to umowa.
Na macOS Azure VPN Client jest również udokumentowaną ścieżką dla tej metody.
Certyfikaty wymagają poświadczenia klienta, nie tylko korzenia
Uwierzytelnianie certyfikatami to osobny obsługiwany model i działa z klientami OpenVPN dokumentowanymi przez Microsoft oraz z Azure VPN Client na obsługiwanych platformach. W systemie Windows Azure VPN Client nie jest tylko dla Entra: ma też udokumentowany przepływ pracy z certyfikatami. Potrzebuje zamierzonego certyfikatu klienta z użytecznym kluczem prywatnym, któremu ufa brama. Zaufany korzeń bramy nie jest poświadczeniem klienta, a klucz podpisywania wystawcy nigdy nie należy do pakietu klienta.
Sprawdź łańcuch, zanim zaczniesz debugować profil. Certyfikat wystawiony przez korzeń, któremu brama nie ufa, daje błąd wyglądający jak zły profil, a w rzeczywistości będący problemem zaufania.
Trzymaj klucz prywatny nieeksportowalny tam, gdzie platforma na to pozwala, i testuj z certyfikatem faktycznie zainstalowanym dla bieżącego użytkownika.
RADIUS to wybór backendu z własnymi kombinacjami
RADIUS przenosi decyzję o poświadczeniach na serwer, którym sam zarządzasz, i jest udokumentowany z konkretnymi typami tunelu i klientami. Nie jest automatycznie właściwą odpowiedzią tylko dlatego, że środowisko ma kilka systemów operacyjnych. Ustal, co rzeczywisty klient może przedstawić, zanim zmienisz politykę uwierzytelniania bramy, bo przełączenie bramy na RADIUS nie dostosuje każdego istniejącego profilu. Klient nadal musi umieć poprosić o te poświadczenia lub je dostarczyć.
Jeśli przyczyną jest środowisko mieszane, rozwiąż to per platforma, zamiast osłabiać politykę bramy dla wszystkich.
Linux po wycofaniu podglądu w 2026 r.
Wskazówki Microsoft dotyczące wycofania Linux podają 31 sierpnia 2026 r. jako datę wycofania podglądu Azure VPN Client dla Linux, więc od listopada 2026 r. ten podgląd jest już za tobą. Istniejące instalacje mogą nadal działać, ale nie otrzymują już wsparcia, aktualizacji ani poprawek bezpieczeństwa. Nie rozdawaj starego instalatora Linux jako obsługiwanego nowego wdrożenia. To wycofanie klienta, a nie Azure VPN Gateway ani klientów Windows i macOS.
Udokumentowane alternatywy dla Linux to klient OpenVPN z uwierzytelnianiem certyfikatem albo strongSwan z IKEv2 i uwierzytelnianiem certyfikatem lub RADIUS. Obie to inne konfiguracje wymagające zatwierdzenia organizacyjnego, a nie konwersja uzyskana przez zmianę nazwy starego profilu Entra.
Jeśli logowanie Entra jest obowiązkowe ze względów polityki, właściciel musi wybrać obsługiwaną platformę lub zatwierdzony projekt alternatywny. To decyzja, nie obejście.
Wygeneruj profil i wykonaj cztery kontrole
Gdy kombinacja jest ustalona, wygeneruj konfigurację klienta z zamierzonej bramy i zaimportuj reprezentację udokumentowaną dla tego klienta i metody. Ogólny folder OpenVPN i profil XML Azure VPN Client nie są wymienne. Jeśli brama celowo włącza kilka typów uwierzytelniania, wybierz pasujący profil i ścieżkę poświadczeń, zamiast oczekiwać, że jedno połączenie zaspokoi wszystkie. Następnie wykonaj kontrole w tej kolejności:
- Obsługiwany klient importuje wygenerowany profil bez jego edycji.
- Zamierzona tożsamość uwierzytelnia się metodą oczekiwaną przez ten profil.
- Wymagana polityka tras i resolvera pojawia się na kliencie.
- Dozwolona aplikacja dociera do swojego zasobu prywatnego.
Udany import nie dowodzi ani zgodności uwierzytelniania, ani autoryzacji do zasobu prywatnego, dlatego te cztery kontrole pozostają osobne.