Autentificarea clientului P2S Azure: Entra, certificat sau RADIUS
Autentificarea Entra, certificatele de client și RADIUS necesită clienți și profiluri Azure VPN diferite. Alegeți metoda, apoi clientul, apoi profilul.
Programul de instalare rulează, profilul este importat, iar conexiunea eșuează la pasul de autentificare. Majoritatea acestor tichete nu sunt o eroare a clientului: o aplicație compatibilă OpenVPN poate transporta tunelul și totuși nu știe cum să efectueze o autentificare Microsoft Entra. Ordinea care evită bucla este metodă, apoi client, apoi profil. Alegeți metoda de autentificare pentru care este configurat gateway-ul, alegeți un client pe care Microsoft îl documentează pentru această metodă și abia apoi generați profilul pe care acel client îl așteaptă. Tot ce urmează respectă această ordine.
Începeți cu metoda, nu cu programul de instalare
Gateway-ul este configurat cu unul sau mai multe tipuri de tunel și metode de autentificare. Această pereche, nu extensia fișierului de pe desktop, decide ce clienți sunt acceptați.
Notați perechea înainte de a descărca ceva, pentru că matricea de suport este îngustă, iar un început greșit costă o după-amiază.
Iată maparea pe care o păstrez în notele de implementare:
| 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 |
Citiți acel tabel ca o constrângere, nu ca un meniu. Fiecare rând este o combinație documentată, iar amestecarea unui client dintr-un rând cu metoda din altul este exact eroarea pe care acest articol o previne.
Entra ID înseamnă OpenVPN plus Azure VPN Client
Pentru autentificarea Entra în conexiune punct-la-site, configurația acceptată folosește tipul de tunel OpenVPN și Azure VPN Client. O casetă generică de nume de utilizator și parolă nu înlocuiește această integrare, iar IKEv2 nativ din Windows nu este o modalitate interschimbabilă de a face aceeași autentificare. Dacă un client terț oferă o opțiune Entra sau Azure AD, verificați-o în documentația actuală Microsoft, nu după etichetă. Eticheta este marketing, iar combinația documentată este contractul.
Pe macOS, Azure VPN Client este de asemenea calea documentată pentru această metodă.
Certificatele necesită o acreditare de client, nu doar o rădăcină
Autentificarea cu certificate este un model acceptat separat și funcționează cu clienții OpenVPN pe care Microsoft îi documentează și cu Azure VPN Client pe platformele acceptate. În Windows, Azure VPN Client nu este doar pentru Entra: are și un flux de lucru documentat pentru certificate. Are nevoie de certificatul de client dorit, cu o cheie privată utilizabilă, în care gateway-ul are încredere. Rădăcina de încredere a gateway-ului nu este o acreditare de client, iar cheia de semnare a emitentului nu aparține niciodată unui pachet de client.
Verificați lanțul înainte de a depana profilul. Un certificat emis de o rădăcină în care gateway-ul nu are încredere produce o eroare care arată ca un profil defectuos și este de fapt o problemă de încredere.
Păstrați cheia privată neexportabilă acolo unde platforma permite, și testați cu certificatul instalat efectiv pentru utilizatorul curent.
RADIUS este o alegere de backend cu propriile combinații
RADIUS mută decizia privind acreditările pe un server pe care îl administrați singur și este documentat cu tipuri de tunel și clienți specifici. Nu este automat răspunsul corect doar pentru că mediul are mai multe sisteme de operare. Determinați ce poate prezenta clientul real înainte de a schimba politica de autentificare a gateway-ului, pentru că trecerea gateway-ului la RADIUS nu adaptează fiecare profil existent. Clientul trebuie în continuare să poată solicita sau furniza acele acreditări.
Dacă motivul este un mediu mixt, rezolvați-l pe platforme, nu slăbiți politica gateway-ului pentru toți.
Linux după retragerea previzualizării în 2026
Îndrumările Microsoft privind retragerea Linux indică 31 august 2026 ca dată de retragere a previzualizării Azure VPN Client pentru Linux, așa că din noiembrie 2026 acea previzualizare este în urmă. Instalările existente pot continua să funcționeze, dar nu mai primesc suport, actualizări sau corecții de securitate. Nu distribuiți un instalator Linux vechi ca implementare nouă acceptată. Este retragerea unui client, nu a Azure VPN Gateway sau a clienților Windows și macOS.
Alternativele documentate pentru Linux sunt un client OpenVPN cu autentificare prin certificat sau strongSwan cu IKEv2 și autentificare prin certificat sau RADIUS. Ambele sunt configurații diferite care necesită aprobare organizațională, nu o conversie obținută prin redenumirea profilului Entra vechi.
Dacă autentificarea Entra este obligatorie din motive de politică, proprietarul trebuie să aleagă o platformă acceptată sau un design alternativ aprobat. Aceasta este o decizie, nu o soluție ocolitoare.
Generați profilul și efectuați patru verificări
După stabilirea combinației, generați configurația clientului din gateway-ul dorit și importați reprezentarea documentată pentru acel client și acea metodă. Folderul OpenVPN generic și profilul XML Azure VPN Client nu sunt interschimbabile. Dacă gateway-ul activează intenționat mai multe tipuri de autentificare, alegeți profilul și calea de acreditare potrivite, în loc să vă așteptați ca o singură conexiune să le satisfacă pe toate. Apoi efectuați verificările în această ordine:
- Clientul acceptat importă profilul generat fără a-l edita.
- Identitatea dorită se autentifică cu metoda pe care o așteaptă profilul.
- Politica de rute și de resolver necesară apare pe client.
- Aplicația permisă ajunge la resursa sa privată.
O importare reușită nu dovedește nici compatibilitatea autentificării, nici autorizarea resursei private, de aceea cele patru verificări rămân separate.