Configurare una VPN su Mac: scegliete il client adatto al vostro profilo

Configurate il client che il vostro operatore VPN indica, poi dimostrate il tunnel con la risorsa privata di cui avete davvero bisogno. Un Mac può conservare una configurazione VPN nativa in Impostazioni di Sistema, ma un file OpenVPN o WireGuard richiede software che comprenda il formato, e sono percorsi di configurazione diversi. Il tipo di credenziale decide come fallirà l’accesso, quindi leggetelo prima di digitare qualsiasi cosa. Giudicate il risultato da ciò che restituisce la risorsa privata, non dall’icona nella barra dei menu.

Abbinate il client al profilo che avete ricevuto

Partite dal file o dalle istruzioni inviate dal vostro operatore, non da un elenco di protocolli su un sito di download. Il modulo VPN nativo di Impostazioni di Sistema gestisce tipi specifici; un profilo OpenVPN o una configurazione WireGuard richiede un’applicazione che la analizzi. Un Mac gestito può già ricevere la connessione dalla gestione dei dispositivi, e aggiungere un secondo profilo sopra produce un conflitto anziché una configurazione. Guardate cosa esiste già prima di installare qualsiasi cosa.

Il metodo di accesso viene dal profilo ed è di solito uno di tre: una password dell’account, un certificato client o una passphrase che sblocca una chiave privata. Una password errata e un certificato rifiutato fermano entrambi la connessione, ma non si leggono allo stesso modo, e solo uno dei due si risolve reimpostando la password dell’account. Leggete il rifiuto prima di cambiare qualcosa: un certificato scaduto o non attendibile fallisce ancora dopo la reimpostazione della password, mentre una password sbagliata fallisce subito, al primo tentativo.

Tenete il materiale privato fuori dai registri condivisi. La passphrase di una chiave, un certificato client e la sua chiave non appartengono a una conversazione con un collega, e uno screenshot dell’editor dei profili rivela di solito più di quanto si aspetti il mittente. Se l’operatore fornisce un file importabile, importatelo invece di ridigitare i valori a mano.

Dimostrate che funziona sulla risorsa, non sull’icona

Un profilo di lavoro spesso instrada solo le destinazioni dell’ufficio, quindi l’indirizzo pubblico che vedete navigando può restare lo stesso mentre l’applicazione privata funziona. Su un profilo di uscita personale l’indirizzo che vedete dall’esterno deve cambiare, e su un profilo di lavoro di solito no. Misurate quella differenza prima di concludere che il tunnel è rotto.

Poi aprite la risorsa che vi serve davvero: la condivisione file, la pagina di amministrazione, l’host del database. Il caricamento di una pagina iniziale attraverso il tunnel prova che il tunnel trasporta del traffico, non che trasporti il traffico che intendevate. Se il browser mostra ancora l’indirizzo originale quando il profilo dovrebbe cambiarlo, confrontate tre cose: l’applicazione in uso, la famiglia di indirizzi e la politica del proxy. Un proxy del browser o un percorso IPv6 possono portare il traffico attorno alla VPN mentre il tunnel stesso è sano.

Dove il client espone una tabella di routing, leggete la route predefinita e la route del tunnel. Quella coppia registra quale progetto avete davvero distribuito.

Quando smette di funzionare, trovate lo strato che si è rotto

Una configurazione che funzionava prima di solito si è rotta perché qualcosa si è aggiunto al percorso: un secondo client VPN, un agente di sicurezza, un filtro dei contenuti, una nuova estensione di rete. Usate la diagnostica del prodotto invece di cancellare preferenze o reimpostare lo stack di rete, che è una speranza e non una diagnosi. Collegate il guasto a un evento — sospensione, cambio di Wi-Fi, accesso al portale o aggiornamento del client — e annotate se si ripete. Un fattore scatenante ripetibile va nel ticket con l’ora in cui si è verificato.

I nomi falliscono diversamente dalle route. A un host privato si arriva con il suo nome completo documentato, e i nomi brevi di ufficio dipendono da un resolver interno più un dominio di ricerca che esiste solo sul percorso aziendale. Sostituite quel resolver con un servizio DNS pubblico e i nomi brevi smettono del tutto di risolversi, il che sembra un tunnel rotto ma non lo è.

scutil --dns
dscacheutil -q host -a name intranet.example.com

Nell’output di scutil --dns, trovate il resolver il cui dominio di ricerca corrisponde al vostro dominio aziendale e leggete il server dei nomi a cui punta; le voci elencate sotto la configurazione DNS mostrano quale resolver fornisce ogni interfaccia. Quando il resolver aziendale compare solo per un’altra interfaccia, o il browser esegue un proprio DNS cifrato, un’applicazione risolve il nome mentre tutto il resto fallisce.

Rimuovete un profilo che non vi serve più tramite il meccanismo che lo ha installato, perché cancellare una voce locale lascia vivo l’account lato server e un client obsoleto può ancora rivendicare le stesse route. Su un Mac gestito conta la procedura di rimozione dell’amministratore. Annotate il nome del profilo, l’indirizzo del server e la risorsa che funziona prima di rimuovere qualsiasi cosa, così il ripristino non parte da zero.