Il profilo OpenVPN di Windows fallisce su Ubuntu: tre livelli

Avviate lo stesso profilo dal terminale e il messaggio che quasi tutti copiano è un avviso, non il motivo per cui il client si è fermato. Qui falliscono tre livelli indipendenti: una direttiva inviata che la build Linux non implementa, i permessi necessari per creare un dispositivo tun e l’helper del resolver che trasforma una connessione in un DNS funzionante. Affrontateli in ordine, perché ciascuno può nascondere il successivo.

Conservate il download così com’è arrivato e modificate una copia, così un nuovo download non annulla le vostre modifiche in silenzio.

Leggete l’avviso prima di dargli la colpa

block-outside-dns blocca il DNS su Windows tramite la piattaforma di filtro di Windows, e il client Linux non ha nulla a cui associarlo. Quando il server lo invia, il client stampa una riga di opzione sconosciuta per quella voce inviata e prosegue, perché un’opzione inviata non è considerata fatale. La riga identica nel vostro file è un’altra cosa: lì il parser si ferma. Stabilite quale delle due avete prima di toccare qualcosa, perché solo una delle due termina l’esecuzione.

Per togliere il rumore, filtratelo prima dell’analisi: una voce pull-filter ignore per quel nome, oppure --ignore-unknown-option quando la riga sta nel file locale. Entrambe zittiscono una riga che avete già letto; nessuna ripara un guasto che non avete diagnosticato.

I privilegi falliscono prima di ogni altra cosa

Un dispositivo tun e le rotte che lo accompagnano sono oggetti privilegiati, e un account normale non può crearli. L’opzione --user spiega questa separazione: il demone rinuncia ai propri privilegi solo dopo che il lavoro privilegiato è stato fatto. Avviatelo come root, o tramite una unit che lo avvia così, poi cercate un errore di permessi prima di guardare i certificati. Allentare i permessi del file del profilo non dà al processo i diritti che gli mancano.

Un errore TLS significa che il client ha superato questo livello. Una lamentela su dispositivo o rotta significa che non ha mai raggiunto il livello superiore.

Cosa fa la GUI e il terminale no

Connettersi con successo mentre ogni risoluzione continua a fallire è il terzo livello. NetworkManager fa il proprio lavoro di resolver, ed è per questo che un’importazione dal desktop può distribuire DNS anche quando lo script up del profilo non è mai riuscito. Il comando openvpn --config esegue ciò che --up indica, e se quell’helper manca l’interfaccia compare mentre le richieste continuano verso i server precedenti. Confrontate gli script dei due percorsi prima di installare qualsiasi cosa.

Usate l’helper pacchettizzato della vostra distribuzione; uno script copiato da un post di blog di solito punta a un altro resolver. L’integrazione fornita per systemd-resolved non è lo script generico in stile vpnc, e ciascuna aspetta i propri argomenti e variabili dal client. Anche gli script up definiti dall’utente richiedono script-security 2 prima che il client li esegua.

Separate i livelli alla prossima esecuzione

Eseguite una volta con --verb 4 e leggete il registro nell’ordine in cui è accaduto: creazione del dispositivo, rotte, stretta di mano TLS, poi l’output dello script up. Il primo guasto di quella sequenza è quello che vale la pena correggere; tutto ciò che segue di solito è una conseguenza. Un tunnel che si stabilisce mentre il resolver non lo fa vi mette sul terzo livello, dove il certificato è irrilevante. Lasciate intatto il profilo scaricato mentre confrontate.

Quando ogni ritocco dell’operatore produce un’altra riga rifiutata, il file è rivolto a un’altra piattaforma. Chiedete un export per Linux invece di costruire una lista di filtri permanente.

Annotate quale livello ha fallito e cosa l’ha cambiato, perché la prossima persona che riceverà lo stesso file si fermerà anche lei all’avviso.