Cosa collega davvero un hub virtuale di SoftEther

L’hub virtuale di SoftEther è un confine di appartenenza dentro un singolo server, non un luogo. Le sessioni che si uniscono all’hub possono raggiungere ciò a cui l’hub è collegato, e le sessioni su un altro hub non possono, anche quando entrambe si autenticano sullo stesso server. Per questo un accesso riuscito può comunque collocare un client sulla rete sbagliata. Leggere l’hub come uno switch virtuale chiarisce cosa fa e cosa lascia al bridging, all’instradamento e alla configurazione a cascata.

Un hub è un confine di appartenenza

Un server può ospitare diversi hub, ciascuno con i propri utenti, sessioni e criteri. L’autenticazione stabilisce chi è la sessione, mentre l’hub decide a quale rete virtuale quella sessione si unisce. Due hub sullo stesso host si comportano quindi come due switch separati che per caso condividono l’hardware. Niente in un accesso riuscito implica che la sessione sia atterrata dove volevate.

Usate il nome dell’hub documentato dall’operatore invece di un nome ricordato da uno screenshot. Un client che si unisce all’hub sbagliato raggiunge un’altra rete con una credenziale valida, il che è un riscontro di configurazione e non una violazione di sicurezza. Conservate il nome dell’hub e il suo scopo nelle note del profilo di connessione.

L’amministrazione è delimitata allo stesso modo. Un amministratore dell’hub gestisce quell’hub, mentre l’amministratore del server gestisce il processo, i listener e ogni hub sull’host.

I collegamenti decidono cosa c’è oltre

Un hub da solo collega le sessioni tra loro. Raggiungere qualsiasi altra cosa dipende da come è collegato l’hub: un bridge locale verso un’interfaccia fisica, un router virtuale o una cascata verso un altro server. Ogni collegamento porta le proprie regole di inoltro e i propri modi di guastarsi. Presumere che un hub fornisca accesso a internet è l’errore più comune sul prodotto.

SecureNAT è l’opzione integrata, realizzata con un router virtuale e un servizio DHCP virtuale dentro il server. È comoda per un laboratorio e scomoda per tutto ciò che richiede indirizzamento o criteri prevedibili. Un bridge locale mette l’hub su un segmento reale, che eredita la commutazione, il DHCP e il comportamento di diffusione di quel segmento.

Una cascata collega due server così che le sessioni di un hub possano apparire sull’altro. È una relazione hub-a-hub, quindi entrambe le estremità hanno bisogno di criteri compatibili e di un percorso funzionante tra loro.

Leggete sessioni e criteri separatamente

Le viste di sessioni, indirizzi MAC e indirizzi IP descrivono com’è ora la rete virtuale. Sono osservazioni, non autorizzazioni. Una sessione visibile nell’elenco non è per questo autorizzata a ogni servizio che l’hub può raggiungere, e vale anche il contrario.

Confrontate l’elenco delle sessioni con i criteri che dovrebbero applicarsi. Un dispositivo con un indirizzo fuori dall’intervallo previsto di solito significa DHCP da altrove o un client configurato a mano. Un indirizzo MAC che si sposta tra le sessioni significa un dispositivo migrato o due dispositivi che condividono un’identità. Entrambi meritano uno sguardo, e nessuno è dimostrato dalla sola tabella.

Sul server, vpncmd riporta la stessa immagine dal punto di vista dell’host. Confrontate quell’output con la vista propria del client ogni volta che i due discordano.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Trattate l’amministrazione dell’hub come un ruolo a sé invece che come un permesso del client. Delegare un hub non dovrebbe consegnare i listener o il processo che ospita ogni altro hub.

Verificate il client dopo l’unione

Dal lato client, una sessione stabilita dimostra soltanto che l’autenticazione e il nome dell’hub sono stati accettati. Confermate l’indirizzo, la rotta e la risoluzione dei nomi separatamente, perché ciascuna può fallire dopo che l’hub ha accettato la sessione.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

L’elenco degli indirizzi mostra se l’adattatore ha ricevuto un lease dalla fonte prevista. La query di rotta mostra quale interfaccia porterebbe una destinazione privata, e la query al resolver mostra se il DNS ha seguito la sessione. Un hub che inoltra pacchetti mentre il DNS punta ancora alla rete locale produce la classica connessione funzionante a metà.

Provate l’applicazione e non il collegamento. Una pagina intranet che si carica è una prova più forte di un adattatore con un indirizzo plausibile.