SoftEther VPN Azure: un percorso in relay, non una porta aperta

Il tuo server si trova dietro un router che non puoi configurare, quindi il piano ovvio di inoltrare una porta non è disponibile. VPN Azure esiste proprio per quella situazione, e la risolve invertendo la direzione della prima connessione: il server si connette verso un relay, e i client raggiungono il relay invece del server. Capire questa inversione spiega sia ciò che il servizio risolve sia ogni limite che incontrerai in seguito.

Cosa cambia nel percorso

Con un listener tradizionale, un client apre una connessione TCP verso un indirizzo pubblico che il router inoltra al server. Con il relay, il server mantiene una connessione in uscita verso l’infrastruttura del relay, e il relay accetta le connessioni dei client e trasmette il loro carico al server in attesa. Nessuna porta in ingresso viene aperta, nessun indirizzo statico è richiesto e il router resta intatto. Dal punto di vista del firewall il server è un normale client in uscita, ed è per questo che le reti restrittive lo permettono.

Il relay assegna a quel server un nome sul proprio dominio, e i client vengono configurati per connettersi lì.

Quel nome appartiene al servizio di relay, che non è un Microsoft Azure VPN Gateway anche se entrambi si chiamano Azure qualcosa. Trattarli come intercambiabili produce una configurazione che non può funzionare.

Quali protocolli sopravvivono al relay

Il relay trasporta il protocollo SoftEther, e il progetto documenta SSTP come opzione client, cosa utile perché Windows include un client SSTP. Non diventa però un trasportatore generico per ogni listener dell’host: un listener OpenVPN, un responder IPsec e un servizio L2TP hanno ciascuno bisogno del proprio endpoint raggiungibile, e nessuno di essi viene trasportato dal relay solo perché il server SoftEther è connesso.

I profili client quindi puntano al nome del relay anziché all’indirizzo del server, e un profilo esistente creato per una connessione diretta non funzionerà senza modifiche. Controlla l’elenco dei client supportati per la versione che esegui prima di progettare intorno a un protocollo che il relay non trasporta.

Cosa il relay non fa per te

Il relay è un trasporto. Non crea utenti, hub virtuali, policy di accesso o rotte, e non sa nulla delle reti private dietro il tuo server. Se i client remoti devono raggiungere una sottorete LAN, il server ha ancora bisogno della configurazione di bridging o routing, del percorso di ritorno e della policy del firewall che la rendono possibile. Anche i piani di indirizzamento sovrapposti alle due estremità sono invisibili al relay e restano un tuo problema da risolvere.

Anche le impostazioni di sicurezza supportate sono da scegliere. La documentazione del progetto include esempi di piattaforme più vecchie, e copiare impostazioni obsolete di cifratura o certificati da uno screenshot vecchio è un buon modo per costruire un tunnel che nessuno può verificare. Usa le indicazioni attuali per la versione che esegui.

La validazione dei certificati e l’autenticazione degli utenti restano responsabilità del server, e il relay non sostituisce mai nessuna delle due.

Gestiscilo come una dipendenza

La disponibilità ora include una terza parte. Quando il relay non è raggiungibile, i client non possono connettersi per quanto il tuo server sia sano, e il guasto appare dall’esterno come un problema del client. Monitora il percorso del relay separatamente dalla salute del server e tieni un piano di riserva documentato, come un listener diretto su un altro indirizzo, per il giorno in cui conterà.

La latenza segue la geografia del relay anziché la vicinanza dei tuoi utenti, cosa che vale la pena misurare prima di promettere prestazioni interattive su di esso.

Verifica l’identità del server e poi un percorso applicativo reale, non solo un banner di connessione riuscita, e controlla se la risorsa che ti serve è raggiungibile sulla famiglia di indirizzi trasportata dal relay. Annota il nome del relay, il protocollo usato e il piano di riserva, perché questi tre fatti rispondono alla maggior parte delle domande future su questo collegamento.