OpenVPN TAP su macOS: controllate il client prima di fare debug

Un vecchio profilo arriva su un Mac attuale, il client lo importa senza lamentarsi e la connessione cade o non fa mai passare traffico. Prima di dedicare un pomeriggio ai certificati, leggete la riga del dispositivo nel profilo. Se dice dev tap, state chiedendo al client un’interfaccia di tipo Ethernet e, su macOS, è proprio su questa richiesta che finiscono la maggior parte di queste sessioni.

Passo 1: verificate che il profilo chieda davvero TAP

I profili vengono rinominati, impacchettati e riesportati, quindi controllate il file che avete realmente importato. Cercate la direttiva del dispositivo e qualsiasi include che possa sovrascriverla. Due righe di output risolvono la questione nella maggior parte dei casi. Quando compaiono sia dev sia dev-type, vince la direttiva successiva, ed è esattamente il tipo di dettaglio che un profilo copiato nasconde.

grep -nE "^[[:space:]]*(dev|dev-type)[[:space:]]" client.ovpn
ls -l ~/Library/Application\ Support/ 2>/dev/null

Se il file contiene dev tap o dev tap0, il client deve implementare un’interfaccia TAP. Se contiene dev tun, il resto di questo articolo non si applica e il guasto è altrove.

Annotate nome e versione del client, la versione di macOS e la provenienza del profilo. Questi tre fatti decidono quale dei due percorsi seguenti è anche solo possibile.

Passo 2: sappiate cosa cambia davvero la modalità dispositivo

Un’interfaccia TUN trasporta pacchetti IP. Il client legge e scrive pacchetti indirizzati a un peer IP, e il sistema operativo li instrada come qualsiasi altra interfaccia.

Un’interfaccia TAP trasporta frame Ethernet, compresi broadcast e ARP. È ciò che permette a un server in bridge di distribuire indirizzi via DHCP e a un client di scoprire dispositivi urlando, ed è per questo che alcuni progetti vecchi vi dipendono.

Il prezzo è che TAP richiede un driver che presenti al sistema un’interfaccia Ethernet. Apple ha deprecato il modello di estensione del kernel su cui si basavano i vecchi driver TAP per Mac, e la sua API sostitutiva non appare per magia dentro client che non sono mai stati aggiornati per usarla. Una capacità della piattaforma e un prodotto già distribuito sono due cose diverse.

Passo 3: scegliete tra un client compatibile e una migrazione

Ci sono due percorsi onesti. Il primo è un client il cui editore dichiara, per la vostra versione di macOS e il vostro hardware, che supporta la configurazione TAP di cui avete bisogno. Non un post di forum di quattro anni fa e non un installer archiviato: una dichiarazione attuale più una connessione di prova.

Il secondo è spostare il servizio su TUN, che è un cambiamento del server tanto quanto del client. Richiede una topologia instradata, un pool di indirizzi, rotte spinte per le reti remote e un percorso di ritorno da quelle reti al pool.

Ciò che non funziona è modificare tap in tun nella copia locale e sperare. Il server fa ancora da bridge, il client ora parla IP, e nulla concorda.

Passo 4: raccogliete i fatti prima di cambiare un servizio funzionante

Lasciate intatto il profilo originale e fate una copia per gli esperimenti. Un file che potete ripristinare in un minuto vale più di una cartella ordinata. Quando il sostituto funziona, cancellate la copia di proposito invece di lasciare due profili che sembrano identici in un elenco. Quella sola abitudine evita la maggior parte della confusione che segue una migrazione fallita. Registrate il comportamento attuale per poter dimostrare cosa è cambiato: il tunnel sale, riceve un indirizzo, riuscite a raggiungere un host noto e la risoluzione dei nomi funziona.

Fate tre domande al proprietario del gateway. Il server usa una topologia in bridge o instradata? Quali prefissi remoti dovrebbero essere raggiungibili? E c’è una finestra di manutenzione per cambiare la configurazione, o ci si aspetta che funzioni senza toccare il server?

Le risposte determinano se questo pomeriggio risolvete un problema del client o se la prossima settimana pianificate un cambiamento di rete.

Passo 5: verificate la migrazione da entrambi i lati

Quando il server ha una configurazione instradata e voi avete un profilo corrispondente, provate in questo ordine: il tunnel si stabilisce, il client riceve un indirizzo dal nuovo pool, un host sul lato remoto risponde e un nome si risolve tramite l’impostazione DNS spinta.

Poi provate ciò che prima dipendeva dal comportamento Ethernet. Se un’applicazione scopriva i dispositivi via broadcast, non li troverà attraverso un tunnel instradato, e nessuna configurazione del client lo riporta indietro. Quell’applicazione ha bisogno di un indirizzo noto, di un host ausiliario locale o di un altro metodo di scoperta.

Concludete riconnettendovi e riavviando una volta, perché un profilo che funziona solo al primo tentativo di solito significa che le rotte spinte o l’impostazione DNS non vengono applicate alla riconnessione.

Quando fallisce ancora, leggete il primo errore

Un client che non riesce a creare l’interfaccia lo dice nel suo log, di solito nelle prime righe. Un client che la crea e poi non riesce ad autenticarsi ha superato da tempo la questione del dispositivo, e continuare a inseguire TAP spreca la sessione.

Conservate il profilo originale e la configurazione funzionante finché il sostituto non è dimostrato. Annullare una modifica al client è rapido; ricostruire una rete in bridge che qualcuno ha smontato per intuizione non lo è.