Pagpapatotoo ng kliyente ng Azure P2S: Entra, sertipiko o RADIUS
Ang pag-sign in sa Entra, mga sertipiko ng kliyente at RADIUS ay nangangailangan ng magkaibang mga kliyente at profile ng Azure VPN. Piliin ang paraan, pagkatapos ang kliyente, pagkatapos ang profile.
Tumakbo ang installer, na-import ang profile, at nabigo ang koneksyon sa hakbang ng pag-sign in. Karamihan sa mga ticket na ito ay hindi bug sa kliyente: ang isang aplikasyong compatible sa OpenVPN ay maaaring magdala ng tunnel at hindi pa rin alam kung paano magsagawa ng pag-sign in sa Microsoft Entra. Ang pagkakasunod-sunod na umiiwas sa loop ay paraan, pagkatapos kliyente, pagkatapos profile. Piliin ang paraan ng pagpapatotoo kung saan naka-configure ang gateway, pumili ng kliyenteng dokumentado ng Microsoft para sa paraang iyon, at pagkatapos lamang buuin ang profile na inaasahan ng kliyenteng iyon. Lahat ng nasa ibaba ay sumusunod sa pagkakasunod-sunod na iyon.
Magsimula sa paraan, hindi sa installer
Ang gateway ay naka-configure sa isa o higit pang uri ng tunnel at mga paraan ng pagpapatotoo. Ang pares na iyon, hindi ang extension ng file sa desktop mo, ang nagtatakda kung aling mga kliyente ang sinusuportahan.
Isulat ang pares bago mag-download ng anuman, dahil makitid ang matrix ng suporta at ang maling simula ay nagkakahalaga ng isang hapon.
Narito ang mapping na iniingatan ko sa mga tala ng deployment:
| 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 |
Basahin ang talahanayang iyon bilang hadlang, hindi bilang menu. Bawat hilera ay dokumentadong kombinasyon, at ang paghahalo ng kliyente mula sa isang hilera sa paraan mula sa iba ay eksaktong pagkabigo na nais pigilan ng artikulong ito.
Ang Entra ID ay nangangahulugang OpenVPN at Azure VPN Client
Para sa pagpapatotoo ng Entra sa point-to-site, ginagamit ng sinusuportahang kaayusan ang uri ng tunnel na OpenVPN at ang Azure VPN Client. Ang karaniwang dialog ng username at password ay hindi kapalit ng integrasyong iyon, at ang native na IKEv2 ng Windows ay hindi mapagpapalit na paraan upang gawin ang parehong pag-sign in. Kung ang kliyente ng third party ay nag-aalok ng opsyon na Entra o Azure AD, i-verify ito sa kasalukuyang dokumentasyon ng Microsoft at hindi sa label. Ang label ay marketing, habang ang dokumentadong kombinasyon ay kontrata.
Sa macOS, ang Azure VPN Client din ang dokumentadong landas para sa paraang ito.
Ang mga sertipiko ay nangangailangan ng kredensyal ng kliyente, hindi lamang ugat
Ang pagpapatotoo sa sertipiko ay hiwalay na sinusuportahang modelo, at gumagana ito sa mga kliyenteng OpenVPN na dokumentado ng Microsoft at sa Azure VPN Client sa mga sinusuportahang platform. Sa Windows, ang Azure VPN Client ay hindi para sa Entra lamang: mayroon din itong dokumentadong workflow ng sertipiko. Ang kailangan nito ay ang nilalayong sertipiko ng kliyente na may magagamit na pribadong key, na pinagkakatiwalaan ng gateway. Ang pinagkakatiwalaang ugat ng gateway ay hindi kredensyal ng kliyente, at ang signing key ng issuer ay hindi kailanman kabilang sa pakete ng kliyente.
Suriin ang chain bago i-debug ang profile. Ang sertipikong inisyu ng ugat na hindi pinagkakatiwalaan ng gateway ay gumagawa ng pagkabigong mukhang masamang profile at sa totoo ay problema sa pagtitiwala.
Panatilihing hindi ma-export ang pribadong key kung saan pinapayagan ng platform, at subukan gamit ang sertipikong aktwal na naka-install para sa kasalukuyang user.
Ang RADIUS ay pagpipilian sa backend na may sariling mga kombinasyon
Inililipat ng RADIUS ang desisyon sa kredensyal sa server na ikaw mismo ang nagpapatakbo, at ito ay dokumentado sa mga partikular na uri ng tunnel at kliyente. Hindi ito awtomatikong tamang sagot dahil lamang may ilang operating system ang kapaligiran. Tukuyin kung ano ang maipapakita ng aktwal na kliyente bago baguhin ang patakaran ng pagpapatotoo ng gateway, dahil ang paglipat ng gateway sa RADIUS ay hindi nag-aayos ng bawat umiiral na profile. Kailangan pa ring makahiling o makapagbigay ang kliyente ng mga kredensyal na iyon.
Kung halo-halong kapaligiran ang dahilan, lutasin ito ayon sa platform sa halip na pahinain ang patakaran ng gateway para sa lahat.
Linux pagkatapos ng pag-alis ng preview noong 2026
Ang gabay ng Microsoft tungkol sa pag-alis ng Linux ay nagbibigay ng 31 Agosto 2026 bilang petsa ng pag-alis ng preview ng Azure VPN Client para sa Linux, kaya mula Nobyembre 2026 ang preview na iyon ay nasa likuran mo. Ang mga umiiral na installation ay maaaring magpatuloy, ngunit hindi na tumatanggap ng suporta, update o mga pag-aayos sa seguridad. Huwag ipamahagi ang lumang installer ng Linux bilang sinusuportahang bagong deployment. Ito ay pag-alis ng kliyente, hindi ng Azure VPN Gateway o ng mga kliyente ng Windows at macOS.
Ang mga dokumentadong alternatibo sa Linux ay kliyente ng OpenVPN na may pagpapatotoo sa sertipiko, o strongSwan na may IKEv2 at pagpapatotoo sa sertipiko o RADIUS. Pareho silang magkaibang configuration na nangangailangan ng pag-apruba ng organisasyon, hindi conversion na makukuha sa pamamagitan ng pagpapalit ng pangalan ng lumang profile ng Entra.
Kung ang pag-sign in sa Entra ay sapilitan dahil sa mga dahilan ng patakaran, kailangang pumili ng may-ari ng sinusuportahang platform o aprubadong alternatibong disenyo. Iyon ay desisyon, hindi pag-iwas.
Buuin ang profile at magsagawa ng apat na pagsusuri
Kapag napagpasyahan na ang kombinasyon, buuin ang configuration ng kliyente mula sa nilalayong gateway at i-import ang representasyong dokumentado para sa kliyente at paraang iyon. Ang generic na folder ng OpenVPN at ang XML profile ng Azure VPN Client ay hindi mapagpapalit. Kung sadyang pinagana ng gateway ang ilang uri ng pagpapatotoo, piliin ang tugmang profile at landas ng kredensyal sa halip na asahan na isang koneksyon ang tutugon sa lahat. Pagkatapos ay gawin ang mga pagsusuri sa ganitong pagkakasunod-sunod:
- Ini-import ng sinusuportahang kliyente ang nabuong profile nang hindi ito ine-edit.
- Napatotohanan ang nilalayong pagkakakilanlan gamit ang paraang inaasahan ng profile na iyon.
- Lumilitaw sa kliyente ang kinakailangang patakaran ng ruta at resolver.
- Naabot ng pinapayagang aplikasyon ang sarili nitong pribadong mapagkukunan.
Ang matagumpay na pag-import ay hindi nagpapatunay ng pagiging tugma ng pagpapatotoo o ng awtorisasyon sa pribadong mapagkukunan, kaya nananatiling hiwalay ang apat na pagsusuring iyon.