Come testare un secondo client VPN su un Mac senza perdere il primo

Installi il secondo client per confrontarlo, e il primo smette di funzionare. Non è stato eliminato nulla, ed entrambe le applicazioni sono ancora installate. Ciò che è cambiato sta sotto di loro: un'estensione di sistema, un'impostazione DNS o una rotta predefinita, e i due client ora non concordano su chi ne sia proprietario. L'installazione non è la parte rischiosa; la parte rischiosa è eseguire entrambi senza una linea di base registrata a cui tornare.

Il sintomo: la configurazione che funzionava si ferma dopo la seconda installazione

I client VPN moderni di macOS spesso forniscono un'estensione di rete invece di un'interfaccia in stile vecchio. Installarne una può richiedere un'approvazione, aggiungere un profilo di configurazione o registrare un'estensione di sistema che influenza il traffico prima che venga stabilita qualsiasi connessione. L'estensione si carica prima che appaia la finestra dell'applicazione, ed è per questo che il client originale può fallire mentre il nuovo resta inattivo.

Se poi il client originale non riesce a connettersi, o si connette e non risolve nulla, la nuova estensione è il primo sospetto. Non è la prova di un conflitto, ma è da lì che parte l'indagine. Controlla poi l'elenco delle estensioni e i profili di configurazione installati, non solo la cartella delle applicazioni.

Registra la linea di base prima di installare qualsiasi cosa

Annota ciò che funziona ora: il risultato dell'applicazione, la versione del client, l'endpoint a cui si connette e qualsiasi esclusione per applicazione o per tunnel diviso. Salva il profilo originale tramite il processo protetto supportato dal client, non copiando file da un pacchetto dell'applicazione.

scutil --dns | head -40
netstat -rn | head -30
ifconfig | grep -E "^(utun|ipsec)"

Cattura queste tre uscite mentre il client funzionante è connesso. Ti danno lo stato del resolver, la tabella di routing e l'elenco delle interfacce che produce una configurazione funzionante, ed è esattamente ciò che serve per il confronto successivo. Se il Mac è gestito da un datore di lavoro, conferma prima di iniziare che il confronto è consentito, perché una connessione di lavoro automatica può riattivarsi durante il test e il risultato allora non rappresenta nessuno dei due client da solo. Conserva le tre uscite accanto alla nota del profilo, così che il confronto successivo abbia un riferimento.

Cambia un percorso attivo alla volta

Ferma la connessione originale con il suo controllo abituale, poi avvia l'alternativa. Due client connessi contemporaneamente producono un risultato che descrive la combinazione, non uno dei prodotti. Mantieni l'endpoint e l'attività confrontabili se i servizi lo consentono, perché un download più veloce tramite un altro server confronta due opzioni di connessione e non due applicazioni.

Se il nuovo client fallisce, conserva il suo primo errore prima di cambiare qualsiasi altra cosa. Il primo errore di solito indica la fase, e un secondo tentativo dopo una modifica delle impostazioni spesso segnala qualcosa di meno utile.

Confronta DNS, rotte e applicazione, non solo la velocità

Esegui gli stessi tre comandi con il nuovo client connesso e confrontali riga per riga. Un resolver che punta altrove, o una tabella di routing senza la sottorete privata, spiega la maggior parte delle differenze di comportamento prima ancora di guardare la velocità effettiva. Poi prova l'applicazione reale con la stessa attività, perché un client che si connette rapidamente e non risolve un nome interno non ha vinto il confronto anche se la finestra di stato sembra migliore.

Nota quale interfaccia ha usato il traffico. Su macOS il nome dell'interfaccia del tunnel non è un indicatore affidabile di quale client possieda la rotta, quindi abbina l'elenco delle interfacce alla tabella di routing invece di leggerne solo una. Se esistono due interfacce utun, quella che trasporta il tuo traffico è quella con una rotta corrispondente e una voce nel resolver. Indovinare dal nome è il modo in cui viene incolpata l'interfaccia sbagliata, perché l'interfaccia che esiste non è sempre quella che trasporta il traffico.

Leggi le tre uscite invece di scorrerle. Nel dump del resolver, un server dei nomi associato a un'interfaccia utun mostra quale client l'ha installato; nella tabella di routing, la rotta predefinita indica l'interfaccia che trasporta il traffico; nell'elenco delle interfacce, un secondo dispositivo utun significa che è stato creato un secondo tunnel. Queste tre righe, confrontate con la linea di base, separano una configurazione ripristinata da una in cui entrambi i client competono ancora.

Ripristina, poi rimuovi in modo pulito

Torna attraverso il flusso di lavoro proprio del client originale e conferma che le uscite della linea di base corrispondano a ciò che hai registrato. Se il resolver o la tabella di routing non si ripristinano, fermati e correggi prima di rimuovere qualsiasi altra cosa. Rimuovi la configurazione inutilizzata tramite il componente che la possiede: il disinstallatore del client, il profilo o le impostazioni dell'estensione di sistema.

Termina aggiornando le note con la versione testata, l'endpoint usato e il risultato per ciascuno. Sei mesi dopo, quella registrazione è la differenza tra una decisione e una voce.