Azure P2S-klientautentisering: Entra, certifikat eller RADIUS
Entra-inloggning, klientcertifikat och RADIUS kräver olika Azure VPN-klienter och -profiler. Välj metoden, sedan klienten, sedan profilen.
Installationsprogrammet körs, profilen importeras och anslutningen misslyckas i inloggningssteget. De flesta av dessa ärenden är inte ett fel i klienten: ett OpenVPN-kompatibelt program kan bära tunneln och ändå inte veta hur en Microsoft Entra-inloggning utförs. Ordningen som undviker loopen är metod, sedan klient, sedan profil. Välj autentiseringsmetoden som gatewayen är konfigurerad för, välj en klient som Microsoft dokumenterar för den metoden och generera först därefter profilen som klienten förväntar sig. Allt nedan följer den ordningen.
Börja med metoden, inte med installationsprogrammet
Gatewayen är konfigurerad med en eller flera tunneltyper och autentiseringsmetoder. Det paret, inte filändelsen på skrivbordet, avgör vilka klienter som stöds.
Skriv ned paret innan du laddar ner något, för supportmatrisen är smal och en felaktig start kostar en eftermiddag.
Här är mappningen jag har i distributionsanteckningarna:
| 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 |
Läs tabellen som en begränsning, inte som en meny. Varje rad är en dokumenterad kombination, och att blanda en klient från en rad med metoden från en annan är precis det fel artikeln finns för att förhindra.
Entra ID betyder OpenVPN plus Azure VPN Client
För Entra-autentisering på punkt-till-plats använder den stödda ordningen OpenVPN-tunneltypen och Azure VPN Client. En allmän dialog för användarnamn och lösenord ersätter inte den integrationen, och Windows inbyggda IKEv2 är inte ett utbytbart sätt att utföra samma inloggning. Om en tredjepartsklient erbjuder ett Entra- eller Azure AD-alternativ ska du kontrollera det mot Microsofts aktuella dokumentation och inte mot etiketten. Etiketten är marknadsföring, medan den dokumenterade kombinationen är kontraktet.
På macOS är Azure VPN Client också den dokumenterade vägen för den här metoden.
Certifikat kräver en klientlig identitetshandling, inte bara en rot
Certifikatautentisering är en separat stödd modell och fungerar med OpenVPN-klienter som Microsoft dokumenterar och med Azure VPN Client på stödda plattformar. På Windows är Azure VPN Client inte bara för Entra: det har också ett dokumenterat certifikatarbetsflöde. Det som behövs är det avsedda klientcertifikatet med en användbar privat nyckel, som gatewayen litar på. Gatewayens betrodda rot är inte en klientlig identitetshandling, och utgivarens signeringsnyckel hör aldrig hemma i ett klientpaket.
Kontrollera kedjan innan du felsöker profilen. Ett certifikat utfärdat av en rot som gatewayen inte litar på ger ett fel som ser ut som en dålig profil och egentligen är ett tillitsproblem.
Håll den privata nyckeln icke-exporterbar där plattformen tillåter det, och testa med certifikatet som faktiskt är installerat för den aktuella användaren.
RADIUS är ett backendval med egna kombinationer
RADIUS flyttar beslutet om autentiseringsuppgifter till en server du själv driver, och det är dokumenterat med specifika tunneltyper och klienter. Det är inte automatiskt rätt svar bara för att miljön har flera operativsystem. Fastställ vad den faktiska klienten kan presentera innan du ändrar gatewayens autentiseringspolicy, eftersom att byta gatewayen till RADIUS inte anpassar varje befintlig profil. Klienten måste fortfarande kunna begära eller tillhandahålla dessa uppgifter.
Om en blandad miljö är orsaken, lös det per plattform i stället för att försvaga gatewaypolicyn för alla.
Linux efter utfasningen av förhandsversionen 2026
Microsofts vägledning om utfasning av Linux anger 31 augusti 2026 som utfasningsdatum för förhandsversionen av Azure VPN Client för Linux, så från november 2026 ligger den förhandsversionen bakom dig. Befintliga installationer kan fortsätta att fungera, men de får inte längre support, uppdateringar eller säkerhetskorrigeringar. Dela inte ut ett gammalt Linux-installationsprogram som en stödd ny distribution. Detta är utfasning av en klient, inte av Azure VPN Gateway eller Windows- och macOS-klienterna.
De dokumenterade Linux-alternativen är en OpenVPN-klient med certifikatautentisering, eller strongSwan med IKEv2 och certifikat- eller RADIUS-autentisering. Båda är andra konfigurationer som kräver organisatoriskt godkännande, inte en konvertering du får genom att byta namn på den gamla Entra-profilen.
Om Entra-inloggning är obligatorisk av policyskäl måste ägaren välja en stödd plattform eller en godkänd alternativ design. Det är ett beslut, inte en omväg.
Generera profilen och kör fyra kontroller
Generera klientkonfigurationen från den avsedda gatewayen när kombinationen är fastställd, och importera representationen som är dokumenterad för den klienten och metoden. Den generiska OpenVPN-mappen och Azure VPN Client XML-profilen är inte utbytbara. Om gatewayen medvetet aktiverar flera autentiseringstyper ska du välja den matchande profilen och autentiseringsvägen i stället för att förvänta dig att en anslutning uppfyller alla. Kör sedan kontrollerna i denna ordning:
- Den stödda klienten importerar den genererade profilen utan att redigera den.
- Den avsedda identiteten autentiseras med den metod som profilen förväntar sig.
- Den nödvändiga route- och resolverpolicyn visas på klienten.
- Programmet som tillåts når sin privata resurs.
En lyckad import bevisar varken autentiseringskompatibilitet eller behörighet till den privata resursen, därför hålls de fyra kontrollerna åtskilda.