Il programma di installazione viene eseguito, il profilo viene importato e la connessione fallisce nella fase di accesso. La maggior parte di questi ticket non è un difetto del client: un'applicazione compatibile con OpenVPN può trasportare il tunnel e comunque non sapere come eseguire un accesso Microsoft Entra. L'ordine che evita il ciclo è metodo, poi client, poi profilo. Scegliere il metodo di autenticazione per cui è configurato il gateway, scegliere un client documentato da Microsoft per quel metodo e solo allora generare il profilo che quel client si aspetta. Tutto quanto segue rispetta questo ordine.

Partire dal metodo, non dal programma di installazione

Il gateway è configurato con uno o più tipi di tunnel e metodi di autenticazione. È quella coppia, non l'estensione del file sulla scrivania, a decidere quali client sono supportati.

Annotare la coppia prima di scaricare qualcosa, perché la matrice di supporto è stretta e un inizio sbagliato costa un pomeriggio.

Questa è la mappatura che tengo nelle note di distribuzione:

AuthenticationTunnel typeDocumented client
Microsoft Entra IDOpenVPNAzure VPN Client on Windows and macOS
Client certificateOpenVPN or IKEv2Azure VPN Client, documented OpenVPN client, native IKEv2 client, strongSwan on Linux
RADIUSIKEv2 or OpenVPN, per the current matrixNative IKEv2 client, strongSwan, or the OpenVPN client the matrix names

Leggere quella tabella come un vincolo, non come un menù. Ogni riga è una combinazione documentata, e mescolare un client di una riga con il metodo di un'altra è esattamente l'errore che questo articolo vuole evitare.

Entra ID significa OpenVPN più Azure VPN Client

Per l'autenticazione Entra in punto a sito, la disposizione supportata usa il tipo di tunnel OpenVPN e il client Azure VPN. Una finestra generica di nome utente e password non sostituisce quell'integrazione, e l'IKEv2 nativo di Windows non è un modo intercambiabile per eseguire lo stesso accesso. Se un client di terze parti offre un'opzione Entra o Azure AD, verificarla con la documentazione aggiornata di Microsoft e non con l'etichetta. L'etichetta è marketing, mentre la combinazione documentata è il contratto.

Su macOS il client Azure VPN è anche il percorso documentato per questo metodo.

I certificati richiedono una credenziale client, non solo una radice

L'autenticazione con certificati è un modello supportato a parte, e funziona con i client OpenVPN documentati da Microsoft e con il client Azure VPN sulle piattaforme supportate. Su Windows il client Azure VPN non è solo per Entra: ha anche un flusso di lavoro documentato per i certificati. Ciò che serve è il certificato client previsto con una chiave privata utilizzabile, considerato attendibile dal gateway. La radice attendibile del gateway non è una credenziale client, e la chiave di firma dell'emittente non appartiene mai a un pacchetto client.

Controllare la catena prima di eseguire il debug del profilo. Un certificato emesso da una radice di cui il gateway non si fida produce un errore che sembra un profilo difettoso ed è in realtà un problema di attendibilità.

Mantenere la chiave privata non esportabile dove la piattaforma lo consente, e testare con il certificato realmente installato per l'utente corrente.

RADIUS è una scelta di backend con le proprie combinazioni

RADIUS sposta la decisione sulle credenziali su un server gestito da voi, ed è documentato con tipi di tunnel e client specifici. Non è automaticamente la risposta giusta solo perché l'ambiente ha diversi sistemi operativi. Stabilire cosa può presentare il client reale prima di cambiare i criteri di autenticazione del gateway, perché passare il gateway a RADIUS non adatta ogni profilo esistente. Il client deve comunque poter richiedere o fornire quelle credenziali.

Se il motivo è un ambiente misto, risolverlo per piattaforma invece di indebolire i criteri del gateway per tutti.

Linux dopo il ritiro dell'anteprima nel 2026

Le indicazioni di Microsoft sul ritiro di Linux fissano al 31 agosto 2026 la data di ritiro dell'anteprima del client Azure VPN per Linux, quindi da novembre 2026 quell'anteprima è alle spalle. Le installazioni esistenti possono continuare a funzionare, ma non ricevono più supporto, aggiornamenti o correzioni di sicurezza. Non distribuire un vecchio programma di installazione Linux come nuova distribuzione supportata. È il ritiro di un client, non di Azure VPN Gateway né dei client Windows e macOS.

Le alternative Linux documentate sono un client OpenVPN con autenticazione tramite certificato, oppure strongSwan con IKEv2 e autenticazione tramite certificato o RADIUS. Entrambe sono configurazioni diverse che richiedono un'approvazione organizzativa, non una conversione che si ottiene rinominando il vecchio profilo Entra.

Se l'accesso Entra è obbligatorio per motivi di criterio, il proprietario deve scegliere una piattaforma supportata o una progettazione alternativa approvata. È una decisione, non una scorciatoia.

Generare il profilo ed eseguire quattro controlli

Generare la configurazione client dal gateway previsto una volta stabilita la combinazione, e importare la rappresentazione documentata per quel client e quel metodo. La cartella OpenVPN generica e il profilo XML del client Azure VPN non sono intercambiabili. Se il gateway abilita deliberatamente più tipi di autenticazione, scegliere il profilo e il percorso delle credenziali corrispondenti invece di aspettarsi che una sola connessione li soddisfi tutti. Poi eseguire i controlli in questo ordine:

Un'importazione riuscita non dimostra né la compatibilità dell'autenticazione né l'autorizzazione alla risorsa privata, per questo quei quattro controlli restano separati.

Articoli correlati