SoftEther dietro NAT: traversata diretta o relè VPN Azure?

Il vostro server SoftEther si trova dietro un router del provider che non potete cambiare, e i client si connettono comunque, quindi presupponete che un relè porti tutto. Se ciò sia vero dipende da quale meccanismo ha fatto il lavoro: un nome DNS, un percorso UDP coordinato o un tunnel in uscita verso un relè. Tutti e tre possono produrre un client connesso, e falliscono in condizioni diverse. Decidete quale percorso acquistate prima di toccare utenti o hub.

Tre meccanismi, tre promesse diverse

Il DNS dinamico è denominazione. Mantiene un nome host puntato a un indirizzo che cambia perché la gente smetta di inseguire il numero, e non fa altro. La traversata NAT nativa è coordinamento: due estremità SoftEther si scambiano informazioni e tentano di aprire un percorso UDP utilizzabile attraverso i dispositivi di traduzione tra loro. VPN Azure è un relè: il server si collega verso il servizio, e i client arrivano tramite un nome host sull’infrastruttura del relè.

I tre sono complementari, non versioni di un’unica funzione. Un’installazione può usare la denominazione mentre la sua connessione dipende in realtà dalla traversata o dal relè.

Decidete dal client e dalla rete

La scelta parte dal client, perché la traversata esiste solo nel meccanismo di connessione nativo di SoftEther. OpenVPN, L2TP/IPsec e gli ascoltatori SSTP sullo stesso server non la ereditano, anche se condividono un host. Guardate cosa eseguirà l’utente, poi cosa consente la rete. Una rete aziendale che consente solo TCP 443 vi spinge verso un relè su quella porta, mentre una rete che lascia passare le porte UDP necessarie alla traversata può tentare un percorso diretto; confermate entrambe rispetto alla politica reale di uscita.

Un ascoltatore raggiungibile manualmente resta un progetto legittimo quando un amministratore può pubblicarne uno, ma è un progetto separato con il proprio indirizzamento e lavoro sul firewall.

Confermate quale trasporto ha scelto la sessione

Lo stato della connessione è l’unica fonte onesta del percorso in uso. Leggetelo sul server e risolvete il nome host che il client ha ricevuto.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList mostra quali sessioni sono connesse, e SessionGet su una di esse riporta il tipo di connessione, incluso se la sessione è arrivata tramite il relè. Un record che risolve sull’infrastruttura del relè vi dice che la sessione passa attraverso una terza parte, cosa che potete confermare bloccando quella rotta in una prova. Con un client nativo, l’accelerazione UDP può allontanare il percorso dei dati dal percorso di controllo, quindi una sola osservazione non descrive l’intera sessione. Un nome DNS dinamico obsoleto dopo un cambio di indirizzo, e un relè che risponde mentre manca la rotta verso il backend, sono due modalità di guasto che vale la pena provare separatamente. Annotate ciò che avete misurato, non ciò che il progetto intendeva.

Pianificate da cosa dipende il percorso scelto

Ogni percorso porta con sé una dipendenza. Una traversata diretta può cambiare dopo un passaggio di rete o un nuovo dispositivo di traduzione, mentre una sessione di relè fallisce quando fallisce il servizio o la sua porta raggiungibile. Riconnettetevi da un’altra rete e confermate l’identità del server verificata dal client, mantenendo il percorso che funzionava prima nella stessa prova. Poi provate la risorsa privata dietro la VPN, perché autorizzazione, appartenenza all’hub, assegnazione degli indirizzi e rotte di ritorno restano comunque una vostra responsabilità.

Annotate il nome host, il protocollo, le impostazioni della funzione e il trasporto osservato. È quel registro in quattro parti che permette alla persona successiva di riprodurre una connessione funzionante.