Azure P2S-klientautentisering: Entra, sertifikat eller RADIUS
Entra-innlogging, klientcertifikater og RADIUS krever ulike Azure VPN-klienter og -profiler. Velg metoden, deretter klienten, så profilen.
Installasjonsprogrammet kjører, profilen importeres, og tilkoblingen feiler i innloggingstrinnet. De fleste av disse sakene er ikke en feil i klienten: en OpenVPN-kompatibel applikasjon kan bære tunnelen og likevel ikke vite hvordan en Microsoft Entra-innlogging utføres. Rekkefølgen som unngår løkken, er metode, deretter klient, deretter profil. Velg autentiseringsmetoden gatewayen er konfigurert for, velg en klient Microsoft dokumenterer for den metoden, og generer først da profilen klienten forventer. Alt nedenfor følger den rekkefølgen.
Start med metoden, ikke med installasjonsprogrammet
Gatewayen er konfigurert med én eller flere tunneltyper og autentiseringsmetoder. Det paret, og ikke filtypen på skrivebordet, avgjør hvilke klienter som støttes.
Skriv ned paret før du laster ned noe, for støttematrisen er smal, og en feil start koster en ettermiddag.
Her er tilordningen jeg har i distribusjonsnotatene:
| 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 |
Les tabellen som en begrensning, ikke som en meny. Hver rad er en dokumentert kombinasjon, og å blande en klient fra én rad med metoden fra en annen er nøyaktig feilen artikkelen finnes for å hindre.
Entra ID betyr OpenVPN pluss Azure VPN Client
For Entra-autentisering på punkt-til-site bruker den støttede ordningen OpenVPN-tunneltypen og Azure VPN Client. En generisk dialog for brukernavn og passord erstatter ikke den integrasjonen, og Windows' innebygde IKEv2 er ikke en utskiftbar måte å utføre samme innlogging på. Hvis en tredjepartsklient tilbyr et Entra- eller Azure AD-alternativ, må du kontrollere det mot Microsofts gjeldende dokumentasjon og ikke mot etiketten. Etiketten er markedsføring, mens den dokumenterte kombinasjonen er kontrakten.
På macOS er Azure VPN Client også den dokumenterte veien for denne metoden.
Sertifikater krever en klientlegitimasjon, ikke bare en rot
Sertifikatautentisering er en egen støttet modell, og den fungerer med OpenVPN-klienter Microsoft dokumenterer og med Azure VPN Client på støttede plattformer. På Windows er Azure VPN Client ikke bare for Entra: den har også en dokumentert sertifikatarbeidsflyt. Det den trenger, er det tiltenkte klientcertifikatet med en brukbar privat nøkkel, som gatewayen har tillit til. Gatewayens klarerte rot er ikke en klientlegitimasjon, og utstederens signeringsnøkkel hører aldri hjemme i en klientpakke.
Kontroller kjeden før du feilsøker profilen. Et sertifikat utstedt av en rot gatewayen ikke har tillit til, gir en feil som ser ut som en dårlig profil og egentlig er et tillitsproblem.
Hold den private nøkkelen ikke-eksporterbar der plattformen tillater det, og test med sertifikatet som faktisk er installert for gjeldende bruker.
RADIUS er et backend-valg med sine egne kombinasjoner
RADIUS flytter beslutningen om legitimasjon til en server du selv driver, og det er dokumentert med bestemte tunneltyper og klienter. Det er ikke automatisk det riktige svaret fordi miljøet har flere operativsystemer. Fastslå hva den faktiske klienten kan presentere før du endrer gatewayens autentiseringspolicy, fordi å bytte gatewayen til RADIUS ikke tilpasser alle eksisterende profiler. Klienten må fortsatt kunne be om eller levere den legitomasjonen.
Hvis et blandet miljø er årsaken, løs det per plattform i stedet for å svekke gatewaypolicyen for alle.
Linux etter utfasingen av forhåndsvisningen i 2026
Microsofts veiledning om utfasing av Linux oppgir 31. august 2026 som utfasingsdato for forhåndsvisningen av Azure VPN Client for Linux, så fra november 2026 er den forhåndsvisningen bak deg. Eksisterende installasjoner kan fortsette å virke, men de får ikke lenger støtte, oppdateringer eller sikkerhetsrettelser. Ikke del ut et gammelt Linux-installasjonsprogram som en støttet ny distribusjon. Dette er utfasing av en klient, ikke av Azure VPN Gateway eller Windows- og macOS-klientene.
De dokumenterte Linux-alternativene er en OpenVPN-klient med sertifikatautentisering, eller strongSwan med IKEv2 og sertifikat- eller RADIUS-autentisering. Begge er andre konfigurasjoner som krever organisatorisk godkjenning, ikke en konvertering du får ved å gi den gamle Entra-profilen nytt navn.
Hvis Entra-innlogging er obligatorisk av policygrunner, må eieren velge en støttet plattform eller et godkjent alternativt design. Det er en beslutning, ikke en omvei.
Generer profilen og kjør fire kontroller
Generer klientkonfigurasjonen fra den tiltenkte gatewayen når kombinasjonen er avklart, og importer representasjonen som er dokumentert for den klienten og metoden. Den generiske OpenVPN-mappen og Azure VPN Client XML-profilen kan ikke byttes om. Hvis gatewayen bevisst aktiverer flere autentiseringstyper, velg den samsvarende profilen og legitimasjonsveien i stedet for å forvente at én tilkobling tilfredsstiller alle. Kjør deretter kontrollene i denne rekkefølgen:
- Den støttede klienten importerer den genererte profilen uten å redigere den.
- Den tiltenkte identiteten autentiseres med metoden profilen forventer.
- Den påkrevde rute- og oppløserpolicyen vises på klienten.
- Applikasjonen som er tillatt, når sin private ressurs.
En vellykket import beviser verken autentiseringskompatibilitet eller autorisasjon for den private ressursen, derfor holdes de fire kontrollene atskilt.