Azure P2S-klienta aŭtentigo: Entra, atestilo aŭ RADIUS
Entra-ensaluto, klientaj atestiloj kaj RADIUS postulas malsamajn Azure VPN-klientojn kaj profilojn. Unue elektu la metodon, poste la klienton, poste la profilon.
La instalilo ruliĝas, la profilo importiĝas, kaj la konekto malsukcesas ĉe la ensaluta paŝo. Plej multaj el tiuj ĉi biletoj ne estas cimo en la kliento: OpenVPN-kongrua aplikaĵo povas porti la tunelon kaj tamen ne scii kiel fari Microsoft Entra-ensaluton. La ordo, kiu evitas la buklon, estas metodo, poste kliento, poste profilo. Elektu la aŭtentigan metodon por kiu la enirejo estas agordita, elektu klienton kiun Microsoft dokumentas por tiu metodo, kaj nur poste kreu la profilon kiun tiu kliento atendas. Ĉio sube sekvas tiun ordon.
Komencu per la metodo, ne per la instalilo
La enirejo estas agordita kun unu aŭ pluraj tunelaj tipoj kaj aŭtentigaj metodoj. Tiu paro, ne la dosiera finaĵo sur via labortablo, decidas kiujn klientojn oni subtenas.
Skribu la paron antaŭ ol elŝuti ion ajn, ĉar la subtena matrico estas mallarĝa kaj malĝusta komenco kostas posttagmezon.
Jen la mapado kiun mi tenas en la deplojaj notoj:
| 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 |
Legu tiun tabelon kiel limigon, ne kiel menuon. Ĉiu vico estas dokumentita kombino, kaj miksi klienton el unu vico kun la metodo el alia estas ĝuste tiu eraro, kiun ĉi tiu artikolo celas malhelpi.
Entra ID signifas OpenVPN plus Azure VPN Client
Por Entra-aŭtentigo ĉe punkto-al-ejo, la subtenata aranĝo uzas la tunelan tipon OpenVPN kaj la Azure VPN Client. Ĝenerala dialogujo por uzantnomo kaj pasvorto ne anstataŭas tiun integriĝon, kaj la denaska IKEv2 de Windows ne estas interŝanĝebla maniero fari la saman ensaluton. Se triaparta kliento proponas opcion Entra aŭ Azure AD, kontrolu ĝin laŭ la aktuala dokumentaro de Microsoft, ne laŭ la etikedo. La etikedo estas merkatado, dum la dokumentita kombino estas la kontrakto.
En macOS la Azure VPN Client ankaŭ estas la dokumentita vojo por ĉi tiu metodo.
Atestiloj bezonas klientan legitimilon, ne nur radikon
Atestila aŭtentigo estas aparta subtenata modelo, kaj ĝi funkcias kun OpenVPN-klientoj kiujn Microsoft dokumentas kaj kun la Azure VPN Client sur subtenataj platformoj. En Windows la Azure VPN Client ne estas nur por Entra: ĝi ankaŭ havas dokumentitan atestilan laborfluon. Ĝi bezonas la celatan klientan atestilon kun uzebla privata ŝlosilo, kiun la enirejo fidas. La fidata radiko de la enirejo ne estas klienta legitimilo, kaj la subskriba ŝlosilo de la eldonanto neniam apartenas al klienta pako.
Kontrolu la ĉenon antaŭ ol sencimigi la profilon. Atestilo eldonita de radiko kiun la enirejo ne fidas produktas malsukceson kiu aspektas kiel malbona profilo kaj fakte estas fido-problemo.
Tenu la privatan ŝlosilon ne-eksportebla kie la platformo permesas, kaj testu per la atestilo efektive instalita por la nuna uzanto.
RADIUS estas malantaŭa elekto kun propraj kombinoj
RADIUS movas la decidon pri legitimiloj al servilo kiun vi mem funkciigas, kaj ĝi estas dokumentita kun specifaj tunelaj tipoj kaj klientoj. Ĝi ne estas aŭtomate la ĝusta respondo nur ĉar la mastrumaĵo havas plurajn operaciumojn. Difinu kion la reala kliento povas prezenti antaŭ ol ŝanĝi la aŭtentigan politikon de la enirejo, ĉar ŝalti la enirejon al RADIUS ne adaptas ĉiun ekzistantan profilon. La kliento ankoraŭ devas povi peti aŭ liveri tiujn legitimilojn.
Se miksita mastrumaĵo estas la kaŭzo, solvu ĝin laŭ platformo anstataŭ malfortigi la enirejan politikon por ĉiuj.
Linux post la fino de la antaŭrigardo en 2026
La gvidlinioj de Microsoft pri la fino de Linux donas la 31-an de aŭgusto 2026 kiel la daton de la fino de la antaŭrigardo de Azure VPN Client por Linux, do ekde novembro 2026 tiu antaŭrigardo estas malantaŭ vi. Ekzistantaj instalaĵoj povas daŭre funkcii, sed ili ne plu ricevas subtenon, ĝisdatigojn aŭ sekurecajn ripariojn. Ne disdonu malnovan Linux-instalilon kiel subtenatan novan deplojon. Ĉi tio estas fino de kliento, ne fino de Azure VPN Gateway aŭ de la klientoj por Windows kaj macOS.
La dokumentitaj Linux-alternativoj estas OpenVPN-kliento kun atestila aŭtentigo, aŭ strongSwan kun IKEv2 kaj atestila aŭ RADIUS-aŭtentigo. Ambaŭ estas malsamaj agordoj kiuj bezonas organizan aprobon, ne konvertiĝo kiun vi ricevas per renomado de la malnova Entra-profilo.
Se Entra-ensaluto estas deviga pro politikaj kialoj, la posedanto devas elekti subtenatan platformon aŭ aprobitan alternativan dezajnon. Tio estas decido, ne ĉirkaŭvojo.
Kreu la profilon kaj faru kvar kontrolojn
Kreu la klientan agordon el la celata enirejo post kiam la kombino estas fiksita, kaj importu la prezenton dokumentitan por tiu kliento kaj metodo. La ĝenerala OpenVPN-dosierujo kaj la XML-profilo de Azure VPN Client ne estas interŝanĝeblaj. Se la enirejo intence ebligas plurajn aŭtentigajn tipojn, elektu la kongruan profilon kaj legitimilan vojon anstataŭ atendi ke unu konekto kontentigos ĉiujn. Poste faru la kontrolojn en ĉi tiu ordo:
- La subtenata kliento importas la kreitan profilon sen redakti ĝin.
- La celata identeco aŭtentiĝas per la metodo kiun tiu profilo atendas.
- La postulata voja kaj solvila politiko aperas en la kliento.
- La permesita aplikaĵo atingas sian privatan rimedon.
Sukcesa importo pruvas nek aŭtentigan kongruecon nek rajtigon al privata rimedo, tial tiuj kvar kontroloj restas apartaj.