Perché un profilo OpenVPN non si importa in SoftEther

Due file che sembrano entrambi una configurazione VPN finiscono nella stessa cartella, e solo uno dei due funziona. Il profilo OpenVPN descrive un tunnel TLS con direttive che quel client comprende, mentre una connessione SoftEther descrive una sessione contro un hub virtuale con un contratto di autenticazione diverso. Convertire l’uno nell’altro non è un esercizio di formattazione, perché i due client non implementano lo stesso protocollo. Identificare quale servizio abbia realmente pubblicato l’operatore decide tutto ciò che segue.

Due file, due contratti

Un profilo OpenVPN è una configurazione client: un endpoint remoto, un trasporto, materiale TLS e direttive per l’instradamento e la rinegoziazione. Una connessione SoftEther è una sessione client nativa contro un hub virtuale, con un adattatore virtuale collegato.

Possono descrivere l’accesso alla stessa rete senza essere intercambiabili. Il listener OpenVPN è una funzione di compatibilità che il server può pubblicare su una porta separata, e parla OpenVPN invece del protocollo nativo. Il client nativo parla il protocollo nativo e si aspetta il proprio profilo. Un server, due porte, e ogni porta ha la sua chiave.

L’estensione del file non vi dice quasi nulla, per questo la risposta dell’operatore conta più del nome del file.

Leggete il server prima di toccare un blocco di certificato

Chiedete all’operatore tre cose: quale porta e trasporto, quale metodo di autenticazione e quale client si aspettano che usiate. Quelle risposte eliminano gran parte delle congetture.

Poi verificate ciò che è realmente in ascolto, non ciò che afferma una guida. Un listener di compatibilità disattivato non mostra nulla sulla sua porta, e uno attivo mostra un socket anche quando nessuno si è mai connesso. La differenza tra una porta chiusa e un accesso rifiutato è la prima diagnosi utile. Tutto ciò che segue dipende da quale porta è stata bussata.

ss -lunp | grep -E ':1194|:443'
sudo ss -ltnp | grep -E ':992|:5555'
grep -nE '^(remote|proto|auth-user-pass|ca |cert |key )' profile.ovpn

Una porta UDP assente dall’elenco dei listener è una funzione disattivata e non un problema di firewall.

Ciò che serve al client nativo e un profilo non può dargli

Il client nativo installa un adattatore di rete virtuale e vi collega una connessione. Senza quell’adattatore non c’è interfaccia su cui instradare, ed è per questo che una connessione nativa può autenticarsi e comunque non trasportare traffico.

L’autenticazione nativa avviene contro un hub virtuale, con un oggetto utente creato dall’amministratore dell’hub. I blocchi di certificato copiati da un profilo OpenVPN non diventano utenti dell’hub, e un utente dell’hub non diventa un certificato client. I due sistemi memorizzano cose diverse, e un profilo non ha dove mettere il record utente dell’hub. È una differenza strutturale e non un problema di sintassi.

Tenete la chiave privata fuori da qualsiasi servizio di conversione, perché una chiave che lascia la macchina va trattata come divulgata.

Ciò che accetta il listener compatibile con OpenVPN

Il listener di compatibilità è un vero server OpenVPN dal punto di vista del client: si aspetta un client OpenVPN e le direttive che quel client supporta. I blocchi di certificato inline sono una funzione di OpenVPN, e appartengono a quel lato dello steccato.

Ciò che non farà è accettare un profilo SoftEther nativo, perché quel profilo non è una configurazione OpenVPN. Il listener non trasforma nemmeno il client nativo in un client OpenVPN. Se l’operatore offre solo il servizio nativo, la risposta è il client nativo; se offre il listener di compatibilità, la risposta è OpenVPN e il suo materiale.

Chiedete l’esportazione supportata dall’operatore invece di assemblarne una da frammenti, poiché l’esportazione porta dettagli che un file costruito a mano di solito trascura.

Dimostrate il percorso prima di modificare le direttive

Una volta scelto il client, provate il tunnel prima di toccare le rotte. Un accesso riuscito e un’interfaccia che trasporta traffico sono due risultati diversi.

sudo openvpn --config profile.ovpn --verb 3
ip -br addr
ip route get 10.70.4.20
resolvectl status | grep -A2 'DNS Servers'

Confrontate l’indirizzo assegnato con il pool descritto dall’operatore, poi esaminate separatamente rotte e resolver. Una connessione nativa all’hub può autenticarsi correttamente e non installare alcuna rotta, il che dal lato client sembra un tunnel rotto. Solo quando questi tre concordano vale la pena modificare una direttiva. Modificare prima nasconde quale livello fosse sbagliato.