Client nativo SoftEther o profilo OpenVPN: scegliete la porta giusta

Un server SoftEther può rispondere contemporaneamente sulla porta SSL nativa e su una porta compatibile con OpenVPN, facendo sembrare le due un unico servizio con due porte. Sono due servizi con client diversi, formati di configurazione diversi e capacità diverse. Inserire un profilo nativo in un client OpenVPN fallisce in fase di analisi, e l’errore raramente dice perché.

Scegliete prima il listener, poi il client.

Due listener, due formati di configurazione

Il protocollo nativo usa un client SoftEther e una definizione di connessione che nomina il server, la porta, l’hub virtuale e l’utente. Il listener compatibile con OpenVPN si aspetta un profilo OpenVPN con una direttiva remote, materiale TLS e opzioni tratte da un insieme supportato molto più piccolo di quello offerto da un server OpenVPN autonomo. SoftEther la chiama funzione di clone OpenVPN, e clone è un indizio utile sulla fedeltà.

La compatibilità è una questione di versione. Verificate cosa accetta la build distribuita, non cosa documenta un manuale OpenVPN attuale.

Passo 1: scoprite quale listener ha abilitato l’operatore

Chiedete l’elenco dei listener invece di indovinare da un numero di porta. Un server che risponde in TLS sulla 443 non è necessariamente un endpoint OpenVPN, perché il protocollo nativo può usare la stessa porta. La sezione del manuale sulle funzioni server compatibili descrive quali cloni esistono e come si abilitano.

Se riuscite a raggiungere l’host, provate la porta che vi è stata data e non quella di un tutorial: openssl s_client -connect vpn.example.com:443 -brief almeno vi dice se TLS c’è.

Passo 2: usate il client e il profilo corrispondenti

Per l’accesso nativo, installate il client SoftEther, create una connessione con i dati dell’operatore e collegate l’adattatore virtuale. Per il listener compatibile, importate il profilo OpenVPN che l’operatore ha esportato dal server, perché porta il materiale CA e client che quel listener si aspetta. Non assemblate un profilo a mano da un esempio generico e non incollate una definizione di connessione nativa in una configurazione OpenVPN.

Un errore di analisi all’importazione è un problema di formato, non di rete, e non dovrebbe mandarvi al firewall.

Passo 3: mantenete il confronto onesto

Se l’operatore pubblica entrambi, confrontateli tenendo fermi dispositivo, rete di accesso e attività. I due percorsi possono differire nell’autenticazione, nelle sottoreti a cui si collegano e in ciò che il server fa poi con il vostro traffico. Un host condiviso non è una policy condivisa. Tenete ferma anche l’attività, perché una copia di file e una videochiamata sollecitano parti diverse dello stesso percorso.

Resistete ai correttivi che compaiono ogni volta che un’importazione fallisce. Disattivare i controlli dei certificati o abilitare cifrari vecchi per forzare un profilo è una regressione, non una funzione di compatibilità.

Passo 4: verificate il percorso dopo la connessione

Una volta connessi, controllate l’indirizzo ricevuto, le rotte che lo accompagnano, il DNS e una risorsa interna. Sul lato nativo l’adattatore virtuale è l’interfaccia da ispezionare; sul lato OpenVPN è il dispositivo tun o tap creato dal client. In ogni caso la domanda è se il listener scelto conceda l’accesso che serve, il che è un fatto distinto dal fatto che il tunnel sia salito. Annotate l’indirizzo prima e dopo, e confrontateli.

Annotate quale listener e quale versione del client hanno prodotto il risultato funzionante. Altrimenti la persona successiva ripeterebbe la scoperta dal numero di porta in su.