Come scegliere un client VPN per Mac per il gateway che hai già

Sei app VPN per Mac compaiono in una pagina di download e nessuna dice quale accetterà il gateway del tuo datore di lavoro. Non è una lacuna dello store; è una lacuna nel passaggio di consegne. Un SSL VPN è una famiglia di prodotti, non un protocollo, quindi due gateway con la stessa schermata di accesso possono richiedere client diversi. Questo è l'ordine che seguo quando qualcuno mi mette in mano un Mac e un indirizzo server: chiarisci cosa parla il gateway, scegli il client che corrisponde, poi verifica rotte e DNS prima di affidare lavoro al tunnel.

Parti dal gateway, non dall'app store

L'app gira sul tuo Mac, ma qualcos'altro deve accettare la connessione e concedere l'accesso: un gateway con un operatore, un indirizzo, impostazioni compatibili e un modo per autorizzarti. Un client gratuito può essere un buon software e comunque non fornire nulla di tutto ciò. Accesso al lavoro, gateway domestico e uscita internet commerciale sono tre punti di partenza diversi che per caso condividono una pagina di download.

Prima di installare o sostituire qualsiasi cosa, ottieni quattro risposte da chi gestisce il servizio:

• Modalità di accesso: portale nel browser, accesso a un'applicazione selezionata o tunnel di rete completo. Questo decide se ti serve affatto un client.

• Famiglia del gateway e versione supportata: il prodotto, il servizio abilitato e una versione del client che supporti ancora la tua build di macOS e l'hardware del Mac.

• Autenticazione: password con MFA, accesso dal browser, certificato del dispositivo o controllo della postura. Un client privo del flusso approvato si connette e poi viene rifiutato.

• Proprietà: la fonte di download o gestione affidabile, il profilo previsto e chi lo supporta quando si rompe.

La proprietà è la voce che le persone saltano. Su un Mac gestito il profilo arriva spesso dal sistema di gestione dell'organizzazione, e una configurazione costruita a mano può essere sostituita al controllo successivo. Chiedi se ci si aspetta che installi qualcosa da solo prima di cercare un'app di terze parti.

SSL VPN è un'etichetta di famiglia, non un protocollo

TLS può proteggere una connessione mentre uno scambio specifico del prodotto al suo interno gestisce accesso, assegnazione di sessione e traffico del tunnel. È quello scambio interno che un client deve implementare. Un browser che raggiunge la pagina di accesso HTTPS del gateway dimostra la catena di certificati e il server web; non dimostra che un'app VPN non correlata possa costruire un tunnel verso la stessa macchina.

OpenConnect è l'esempio più chiaro che conosco. La sua documentazione upstream elenca modalità di protocollo separate per famiglie di gateway diverse e tiene distinta l'interoperabilità dal supporto ufficiale del fornitore. Se ogni SSL VPN parlasse un solo protocollo, quelle modalità sarebbero inutili.

Un profilo OpenVPN ha lo stesso limite nel senso opposto: è un formato di importazione per un'installazione compatibile con OpenVPN. Condividere TLS come mattone non lo trasforma nel file di configurazione di un gateway aziendale qualsiasi. Per questo un accesso dal browser funzionante è un falso positivo: l'accesso al portale può riuscire mentre non esiste alcun tunnel, e un tunnel che sale può comunque essere rifiutato più tardi da un controllo della postura.

Abbina il client a ciò che parla il gateway

Una volta nota la famiglia, la scelta si restringe in fretta. Questa è la mappatura che controllo per prima, e l'ultima colonna conta più di qualsiasi valutazione dell'app.

Due righe meritano un avvertimento. Il client integrato di macOS è una vera implementazione IKEv2, non un client SSL VPN generico: un servizio progettato per lui richiede il profilo corretto, l'identità server attesa e le credenziali, e su una macchina gestita quel profilo può essere bloccato. OpenConnect copre diversi protocolli dei fornitori da un solo binario, ma il suo progetto non rivendica il supporto dei fornitori; la scansione dell'host, le regole di tunnel diviso inviate dal gateway o un particolare flusso SSO possono esistere solo nel client del fornitore.

WireGuard ha la stessa forma. Il servizio fornisce i peer, il client fornisce il tunnel, e un profilo OpenVPN non è un sostituto. Una piega di macOS: il client dell'App Store tiene i suoi tunnel dentro un'estensione di rete, quindi wg show dagli strumenti Homebrew può non riportare nulla mentre l'interfaccia è attiva. Verifica invece con rotte e traffico.

Configura, poi verifica in un ordine fisso

Installa un client e un profilo, e annota cosa hai cambiato. Prima di connetterti, registra una base di riferimento per poter dire cosa cambia il tunnel:

scutil --nc list
networksetup -listallnetworkservices
netstat -rn | grep -E "^default|utun"
scutil --dns

Connettiti con il profilo fornito e ripeti gli stessi comandi. Per un tunnel completo la rotta predefinita dovrebbe puntare a un'interfaccia utun; con il tunnel diviso solo i prefissi interni dovrebbero essere instradati e la tua uscita pubblica dovrebbe sembrare invariata. Il DNS è la metà che di solito resta rotta: scutil --dns elenca i resolver nell'ordine in cui il sistema li userà, e un resolver interno che sta sotto uno pubblico manderà i nomi interni al server sbagliato.

Per un servizio OpenVPN, Tunnelblick è un client ragionevole senza costi, e la sua guida è diretta sulla metà mancante: non fornisce un servizio VPN. Fai doppio clic sul .ovpn che ti è stato dato, lascia che Tunnelblick lo installi, e controlla la versione rispetto alla tua versione di macOS prima di farci affidamento.

Per un gateway del fornitore spesso provo con OpenConnect dalla riga di comando:

brew install openconnect
sudo openconnect --protocol=anyconnect --user=you vpn.example.com

Lo strumento stampa il certificato ricevuto e attende prima di fidarsi di una catena sconosciuta; quel prompt è una funzione, e il pinning con --servercert pin-sha256:... è meglio che accettare un avvertimento che non hai letto. Ctrl-C abbatte il tunnel, perché un openconnect in primo piano non ha kill switch né logica di riconnessione. Va bene per una sessione diagnostica ed è un pessimo valore predefinito per il lavoro quotidiano.

Quando non c'è un gateway a cui corrispondere

Alcune persone arrivano con il problema opposto: nessun operatore, nessun indirizzo, nessun servizio. Un'app Mac gratuita non può creare raggiungibilità in ingresso su un router di casa. Se vuoi la tua rete da un hotel, qualcuno deve gestire un gateway a casa, tenerlo aggiornato, pubblicare o risolvere il suo indirizzo e decidere quali dispositivi sono raggiungibili.

Se vuoi un'uscita internet diversa invece dell'accesso a una rete privata, scegli il servizio prima del client. Un elenco di profili vuoto in un client autonomo spesso non è un abbonamento gratuito rotto; può darsi che non ci sia alcun abbonamento e nessun server collegato. Tieni separati anche i costi: una licenza del client, un piano di servizio e un gateway gestito da te sono tre acquisti diversi.

Un Mac di lavoro aggiunge uno strato di criteri. Un'app senza costi può essere sbagliata anche quando si connette, perché il client approvato può imporre controlli del dispositivo o un flusso di autenticazione che l'alternativa non ha. Chiedi un'alternativa approvata invece di copiare credenziali tra app non correlate, e non trattare la disattivazione delle protezioni della piattaforma come una correzione di compatibilità.

Un visualizzatore di desktop remoto è anch'esso un prodotto diverso. Ti mostra una sessione su un altro computer; non dà alle applicazioni locali del tuo Mac il percorso di rete che un tunnel fornisce.

Una breve lista di controllo prima della prima sessione reale

Nomina per iscritto la famiglia del gateway e la modalità di accesso, installa solo il client che vi corrisponde e registra il profilo usato. Poi conferma tre cose con traffico reale: le rotte installate dal tunnel, l'ordine dei resolver e un'applicazione interna raggiunta per nome e non per IP.

Se qualcosa fallisce, cambia una variabile alla volta: client, profilo, flusso di autenticazione. Un portale che si carica mentre il tunnel rifiuta di partire separa un problema del server web da uno di compatibilità del client. Quando il servizio di lavoro risponde e il percorso pubblico si comporta come previsto, hai una sistemazione con un nome e supportata invece di un mucchio di ipotesi.