Quale client può completare un accesso SAML su AWS Client VPN

Due persone pongono la stessa domanda su AWS Client VPN e SAML e ottengono risposte opposte. Una accede da un portatile Ubuntu ogni mattina; l’altra ha un telefono, un profilo scaricato e un client che rifiuta una riga al suo interno. La differenza non è fortuna e non è un interruttore nascosto nella dashboard. Tutto si riduce a tre condizioni: se la piattaforma è una di quelle che AWS supporta per il proprio client, se lo strumento che avete in mano può eseguire lo scambio federato nel browser e se l’endpoint è configurato per SAML. Se ne manca una delle tre, l’accesso si blocca in un punto diverso.

Tre condizioni decidono se l’accesso può concludersi

La piattaforma viene per prima. AWS distribuisce il proprio client Client VPN per Windows, macOS e Ubuntu su AMD64, e a fine ottobre 2026 la pagina dei requisiti Linux cita Ubuntu 22.04, 24.04 e 26.04. Una build reimpacchettata, un pacchetto convertito o un’altra distribuzione possono funzionare, ma non è una piattaforma supportata, e quando si rompe la linea di supporto siete voi.

Il client viene per secondo. L’accesso federato non è un’opzione del profilo che ogni applicazione compatibile con OpenVPN interpreta. Il client fornito apre il vostro provider di identità in un browser, riceve la risposta di autenticazione firmata e la inoltra all’endpoint. Un’applicazione che si limita a leggere il profilo e ad alzare un tunnel non esegue questo passo, per quanto pulito appaia il suo registro di connessione.

L’endpoint viene per terzo. Un endpoint che usa credenziali di Active Directory o certificati reciproci ha un’impostazione del tutto diversa, e cambiare client non la modificherà. Confermate la modalità di autenticazione con chi ha emesso il profilo prima di fare debug su qualsiasi altra cosa.

Prese insieme, le tre condizioni danno una breve tabella decisionale:

Perché un import OpenVPN si ferma su auth-federate

Un profilo AWS Client VPN esportato porta una direttiva che dice al client che l’autenticazione avviene fuori dal tunnel, tramite federazione. Un client OpenVPN generico o rifiuta la riga di netto o la ignora e allora non ha credenziali da offrire. È qui che finiscono la maggior parte dei tentativi su Android: il profilo viene importato, l’applicazione protesta, o la connessione muore con un errore di configurazione prima che un solo pacchetto lasci il dispositivo.

Eliminare auth-federate è la mossa successiva tentante, e trasforma un guasto chiaro in uno confuso. Togliere una direttiva non converte un endpoint SAML in autenticazione con nome utente e password. L’endpoint si aspetta ancora una risposta SAML firmata e rifiuta ciò che il client invia al suo posto. La password del vostro account, il profilo scaricato e un’asserzione copiata non sono credenziali intercambiabili.

Accedere al provider di identità in Chrome sul telefono prova solo che il provider di identità ha accettato l’utente. Non dice nulla sull’arrivo della risposta a un client che possa rimandarla all’endpoint. I requisiti di autenticazione federata rendono il client fornito parte del flusso proprio per questo: il passaggio nel browser è necessario e non sufficiente.

Com’è il percorso desktop Linux supportato

Installate il pacchetto che AWS pubblica per Ubuntu AMD64 con il gestore di pacchetti del sistema, poi aprite la connessione da quel client invece di importare il profilo in un’applicazione VPN generica. Usate il profilo che il vostro amministratore ha esportato per questo endpoint; non sostituite un URL di callback né un identificatore client presi da una guida più vecchia, anche se il client lo accetta.

Avviate la connessione, completate l’accesso e qualsiasi richiesta MFA nel browser che si apre, e lasciate che il flusso di ritorno dal browser al client si concluda. Poi richiedete di nuovo l’indirizzo privato che vi serve davvero. Una pagina che annuncia un accesso riuscito non è prova che il tunnel sia salito.

Il client Linux riserva le porte TCP locali da 8096 a 8115 per le risposte SAML. Quando il passaggio si blocca dopo che il provider di identità vi ha accettato, guardate cosa è già in ascolto in quell’intervallo:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

Una porta occupata, o un software di sicurezza dell’endpoint che blocca l’ascoltatore di loopback, producono un accesso che sembra completarsi e poi non si connette mai. Tenete quell’intervallo locale. È un percorso di ritorno lato client, non qualcosa da aprire in un gruppo di sicurezza EC2 o in una regola del firewall del gateway, e aprirlo a internet aggiunge esposizione senza risolvere nulla.

Leggete la fase che fallisce prima di cambiare qualcosa

Dare la colpa al client è il riflesso abituale, ma ogni punto di guasto appartiene a un proprietario diverso. Stabilite prima dove siete davvero.

• Non si apre alcuna finestra del browser. Controllate la modalità di autenticazione del profilo, la connessione scelta e l’integrazione con il browser predefinito del desktop.
• Il provider di identità rifiuta l’account. Assegnazione dell’account, iscrizione MFA o configurazione dell’applicazione SAML, tutto territorio dell’amministratore.
• Il browser termina ma il client non si connette mai. Una risposta di autenticazione scaduta o inutilizzabile, una porta di ritorno bloccata o un passaggio fallito.
• Il tunnel è attivo ma l’applicazione è irraggiungibile. Rotte dell’endpoint, regole di autorizzazione, gruppi di sicurezza, DNS. Ripetere l’accesso nel browser non può aggiungere un permesso di rete mancante.

Conservate il testo dell’errore del client e l’ora del tentativo quando escalate. L’affermazione che SAML è rotto e quella che il client non ha mai ricevuto una risposta di autenticazione valida mandano le persone in posti completamente diversi.

Quando il requisito è Android comunque

Android non è una piattaforma per cui AWS pubblichi il proprio client, quindi la risposta onesta è che non c’è alcun client mobile supportato da installare. È un vincolo di progettazione, non un rompicapo da risolvere sul telefono modificando il profilo finché qualcosa si connette.

Ciò che può cambiare è il progetto di accesso che sta dietro, e quella decisione spetta all’amministratore: un percorso di accesso applicativo approvato verso l’unico servizio interno che il telefono richiede, un prodotto VPN con supporto mobile che l’organizzazione già gestisce, o un desktop supportato per l’endpoint che usa solo SAML. Ogni opzione porta la propria configurazione dell’endpoint, la propria iscrizione dell’identità e le proprie regole di autorizzazione, e l’utente non può crearne nessuna a partire da un profilo scaricato.

Gli strumenti di terze parti che dichiarano di colmare il divario richiedono una revisione esplicita di supporto e sicurezza che copra MFA, gestione delle risposte, criteri del dispositivo e cadenza degli aggiornamenti. La loro esistenza non li rende un client Android fornito da AWS, e non dovreste spostare materiale di autenticazione riutilizzabile su un telefono per farne funzionare uno.

Date all’amministratore tre fatti invece di un lungo thread sulle direttive: la modalità di autenticazione dell’endpoint, la risorsa privata che il telefono deve raggiungere e la scadenza. Basta per scegliere tra un desktop, un percorso di accesso applicativo e un nuovo prodotto VPN.

Controllate le condizioni in ordine prima di aprire un altro ticket: piattaforma nell’elenco dei client forniti, uno strumento che possa completare lo scambio nel browser, un endpoint davvero configurato per la federazione e, su Linux, l’intervallo di porte di loopback. Il primo elemento che fallisce è quello da correggere. Tutto il resto è congettura.