Motore OpenVPN o Tunnelblick: chi possiede la sessione VPN del Mac?

Homebrew installa un programma OpenVPN; Tunnelblick installa un gestore che esegue uno o più motori. Sono livelli diversi, e la domanda utile non è se vi piace usare un terminale. È chi possiede la configurazione, le modifiche al DNS, la richiesta delle credenziali e la pulizia alla fine della sessione. Un unico proprietario per questi livelli è ciò che rende prevedibile la configurazione.

Procedete con i cinque controlli qui sotto in ordine. Il primo che ha due proprietari è quello che produce gli strani stati a metà connessione che la gente attribuisce a OpenVPN stesso. Ogni controllo nomina la prova che lo risolve.

Controllo uno: quale binario di OpenVPN viene davvero eseguito

Eseguite pgrep -fl openvpn mentre siete connessi e leggete l’intera riga di comando. Il primo percorso è il motore che viene davvero eseguito. Su Apple Silicon un’installazione Homebrew di solito si trova sotto /opt/homebrew, mentre i Mac Intel usano /usr/local, e Tunnelblick esegue un motore dall’interno del proprio pacchetto applicativo.

Tunnelblick include motori e consente a una configurazione di sceglierne uno. Aggiornare la formula Homebrew cambia il binario autonomo, non il motore che avvia un profilo Tunnelblick. Se confrontate le versioni per spiegare una differenza di comportamento, confrontate il motore nell’elenco dei processi anziché quello nel gestore di pacchetti. La sola stringa di versione non vi dirà quale profilo ha caricato quel motore.

Un profilo copiato può anche far sembrare identici due motori mentre leggono file diversi. Il percorso del profilo nella riga di comando vi dice quale configurazione ha caricato il processo in esecuzione; un profilo aperto in un editor non è una prova. Confrontate quel percorso prima di confrontare i comportamenti.

Controllo due: chi cambia il DNS e le rotte

Il motore può eseguire le direttive up e down proprie di OpenVPN, ma il gestore può possedere lo stesso ciclo di vita. Le impostazioni del server dei nomi di Tunnelblick controllano i suoi script standard di connessione e disconnessione, e quando quell’integrazione è attiva, le direttive concorrenti nel profilo possono essere ignorate.

Questo conta perché il DNS è il punto in cui un tunnel funzionante sembra rotto più spesso. Controllate scutil --dns mentre siete connessi, notate quale resolver è il primo e confermate che torna dopo la disconnessione. Se il profilo conta di impostare il DNS da sé mentre il gestore lo gestisce anche, uno dei due perderà.

Decidete quale livello possiede il DNS prima della prima connessione, poi rimuovete la direttiva perdente invece di lasciarle entrambe. Le modifiche alle rotte seguono la stessa regola: un proprietario, visibile nella configurazione, con un percorso di ripristino documentato.

Controllo tre: da dove arrivano le credenziali

Una richiesta interattiva e un processo senza sorveglianza hanno requisiti diversi. Una credenziale salvata da un’applicazione non è automaticamente disponibile per un altro processo, e un elemento del portachiavi limitato al gestore può essere invisibile a un motore autonomo avviato da una shell.

Elencate la fonte delle credenziali per il profilo: un certificato e una chiave client, una richiesta di nome utente e password, o un token fornito da un assistente esterno. Poi confermate che il proprietario scelto possa raggiungere quella fonte senza una persona se la connessione deve sopravvivere a un riavvio.

Controllo quattro: chi avvia, sorveglia e arresta il processo

Un’installazione autonoma ha bisogno di un supervisore se deve restare attiva. Launchd può avviare il motore all’accesso o su richiesta, riavviarlo dopo un arresto anomalo e fermarlo in modo pulito, ma qualcuno deve scrivere e possedere quel compito. Eseguire il comando in un terminale funziona per una prova e non per un utente che chiude la finestra.

Se Tunnelblick resta il proprietario, usate i suoi controlli supportati invece di avviare un secondo motore. Il binario Homebrew, con un profilo copiato, apre una connessione indipendente con la propria configurazione e il proprio contesto di integrazione invece di comandare la sessione Tunnelblick esistente.

Qualunque proprietario scegliate, definite cosa accade in sospensione, al cambio di rete e al logout. Un gestore di solito gestisce quegli eventi; un processo nudo di solito no, e la rotta o il resolver obsoleto che ne deriva è facile da interpretare male come guasto del server.

Controllo cinque: come viene verificato il passaggio

Provate il nuovo proprietario con il vecchio disattivato, poi provate di nuovo il vecchio se pensate di tenerlo. Una risorsa privata che risponde in un flusso di lavoro e non nell’altro è una prova sull’integrazione mancante, non sul server.

Per un passaggio a un motore autonomo, annotate il percorso del profilo, il percorso del binario, il supervisore, il proprietario del DNS e la fonte delle credenziali. Poi verificate la risorsa privata, il percorso verso internet pubblico e una disconnessione pulita in quest’ordine. Se il DNS o le rotte restano dopo la disconnessione, il nuovo proprietario non ha finito.

Per un passaggio a Tunnelblick, selezionate il motore per la configurazione, attivate l’integrazione DNS che intendete e rimuovete le direttive del profilo che la contrastano. Poi ripetete gli stessi tre controlli. Una connessione che funziona ma lascia il resolver cambiato è un passaggio fallito, anche se il tunnel si è alzato.

Il confezionamento non risolve la compatibilità con il server. Controllate i requisiti client del servizio stesso e scegliete il solo motore solo quando intendete fornirne la gestione.