Azure P2S-kliëntverifikasie: Entra, sertifikaat of RADIUS
Entra-aanmelding, kliëntsertifikate en RADIUS vereis verskillende Azure VPN-kliënte en -profiele. Kies die metode, dan die kliënt, dan die profiel.
Die installeerder loop, die profiel voer in, en die verbinding misluk by die aanmeldstap. Die meeste van hierdie kaartjies is nie 'n fout in die kliënt nie: 'n OpenVPN-versoenbare toepassing kan die tonnel dra en steeds geen idee hê hoe om 'n Microsoft Entra-aanmelding uit te voer nie. Die volgorde wat die lus vermy, is metode, dan kliënt, dan profiel. Kies die verifikasiemetode waarvoor die poort geconfigureer is, kies 'n kliënt wat Microsoft vir daardie metode dokumenteer, en genereer eers daarna die profiel wat daardie kliënt verwag. Alles hieronder volg daardie volgorde.
Begin by die metode, nie by die installeerder nie
Die poort is met een of meer tonneltipes en verifikasiemetodes geconfigureer. Daardie paar, nie die lêeruitbreiding op jou lessenaar nie, bepaal watter kliënte ondersteun word.
Skryf die paar neer voordat jy enigiets aflaai, want die ondersteuningsmatriks is smal en 'n verkeerde begin kos 'n middag.
Hier is die kartering wat ek in die ontplooiingsnotas hou:
| 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 |
Lees daardie tabel as 'n beperking, nie as 'n spyskaart nie. Elke ry is 'n gedokumenteerde kombinasie, en om 'n kliënt uit een ry met die metode van 'n ander te meng, is presies die fout wat hierdie artikel wil voorkom.
Entra ID beteken OpenVPN plus die Azure VPN Client
Vir Entra-verifikasie op punt-tot-terrein gebruik die ondersteunde reëling die OpenVPN-tonneltipe en die Azure VPN Client. 'n Algemene gebruikersnaam- en wagwoorddialoog is nie 'n plaasvervanger vir daardie integrasie nie, en Windows se inheemse IKEv2 is nie 'n verwisselbare manier om dieselfde aanmelding uit te voer nie. As 'n derdeparty-kliënt 'n Entra- of Azure AD-opsie bied, verifieer dit teen Microsoft se huidige dokumentasie eerder as teen die etiket. Die etiket is bemarking, terwyl die gedokumenteerde kombinasie die kontrak is.
Op macOS is die Azure VPN Client ook die gedokumenteerde pad vir hierdie metode.
Sertifikate vereis 'n kliëntbewys, nie net 'n wortel nie
Sertifikaatverifikasie is 'n aparte ondersteunde model, en dit werk met OpenVPN-kliënte wat Microsoft dokumenteer en met die Azure VPN Client op ondersteunde platforms. Op Windows is die Azure VPN Client nie net vir Entra nie: dit het ook 'n gedokumenteerde sertifikaatwerkvloei. Wat dit nodig het, is die beoogde kliëntsertifikaat met 'n bruikbare private sleutel, wat deur die poort vertrou word. Die poort se vertroude wortel is nie 'n kliëntbewys nie, en die uitreiker se ondertekeningsleutel hoort nooit in 'n kliëntpakket nie.
Kontroleer die ketting voordat jy die profiel ontfout. 'n Sertifikaat wat deur 'n wortel uitgereik is wat die poort nie vertrou nie, veroorsaak 'n mislukking wat soos 'n slegte profiel lyk en eintlik 'n vertrouensprobleem is.
Hou die private sleutel nie-uitvoerbaar waar die platform dit toelaat, en toets met die sertifikaat wat werklik vir die huidige gebruiker geïnstalleer is.
RADIUS is 'n backend-keuse met sy eie kombinasies
RADIUS skuif die besluit oor bewysstukke na 'n bediener wat jy bestuur, en dit is gedokumenteer met spesifieke tonneltipes en kliënte. Dit is nie outomaties die regte antwoord omdat die omgewing verskeie bedryfstelsels het nie. Identifiseer wat die werklike kliënt kan voorlê voordat jy die poort se verifikasiebeleid verander, want om die poort na RADIUS oor te skakel, pas nie elke bestaande profiel aan nie. Die kliënt moet steeds daardie bewysstukke kan vra of verskaf.
As 'n gemengde omgewing die dryfveer is, los dit per platform op eerder as om die poortbeleid vir almal te verswak.
Linux ná die uitfasering van die 2026-voorskou
Microsoft se leiding oor die Linux-uitfasering gee 31 Augustus 2026 as die uitfaserdatum vir die Linux Azure VPN Client-voorskou, so vanaf November 2026 is daardie voorskou agter die rug. Bestaande installasies kan aanhou werk, maar hulle ontvang nie meer ondersteuning, opdaterings of sekuriteitsoplossings nie. Moenie 'n ou Linux-installeerder as 'n ondersteunde nuwe ontplooiing uitdeel nie. Dit is 'n uitfasering van 'n kliënt, nie van Azure VPN Gateway of van die Windows- en macOS-kliënte nie.
Die gedokumenteerde Linux-alternatiewe is 'n OpenVPN-kliënt met sertifikaatverifikasie, of strongSwan met IKEv2 en sertifikaat- of RADIUS-verifikasie. Albei is ander konfigurasies wat organisasiegoedkeuring nodig het, nie 'n omskakeling wat jy kry deur die ou Entra-profiel te hernoem nie.
As Entra-aanmelding om beleidsredes verpligtend is, moet die eienaar 'n ondersteunde platform of 'n goedgekeurde alternatiewe ontwerp kies. Dit is 'n besluit, nie 'n omweg nie.
Genereer die profiel en voer vier kontroles uit
Genereer die kliëntkonfigurasie vanaf die beoogde poort sodra die kombinasie vasgestel is, en voer die voorstelling in wat vir daardie kliënt en metode gedokumenteer is. Die generiese OpenVPN-gids en die Azure VPN Client XML-profiel is nie uitruilbaar nie. As die poort doelbewus verskeie verifikasietipes aktiveer, kies die ooreenstemmende profiel en bewysstukpad eerder as om te verwag dat een verbinding almal sal bevredig. Voer dan die kontroles in hierdie volgorde uit:
- Die ondersteunde kliënt voer die gegenereerde profiel in sonder om dit te redigeer.
- Die beoogde identiteit verifieer met die metode wat daardie profiel verwag.
- Die vereiste roete- en oplosserbeleid verskyn op die kliënt.
- Die toegelate toepassing bereik sy private hulpbron.
'n Suksesvolle invoer bewys nóg verifikasieversoenbaarheid nóg magtiging vir private hulpbronne, en daarom bly daardie vier kontroles apart.