Ponte locale SoftEther o SecureNAT: quale attivare

Aprite SoftEther Manager, e la prima vera decisione su un hub non è una casella di controllo, è una questione di topologia. Un ponte locale collega quell'hub a un adattatore fisico e lascia che il segmento esistente fornisca l'indirizzamento, mentre SecureNAT dà all'hub il proprio router virtuale, NAT e DHCP. Scegliere tra i due cambia da dove arrivano gli indirizzi e quale dispositivo risponde per essi. Attivare entrambi sperando che uno vinca è il modo in cui un laboratorio funzionante diventa un thread di supporto.

Partite dall'hub che state davvero modificando

Manager mostra un albero di server e hub, ed è facile configurare l'hub predefinito mentre i client si collegano a un altro con un nome diverso. Fate clic sull'hub, leggete il nome e confermate che le sessioni elencate sotto sono i client che state cercando di servire. Quell'unica verifica evita la maggior parte della confusione che poi viene attribuita al protocollo.

Poi decidete di cosa ha bisogno il client dall'estremità remota. Un comportamento Ethernet condiviso con broadcast e servizi LAN punta a un ponte, l'accesso privato instradato verso un piccolo intervallo di indirizzi punta a SecureNAT, e un'uscita internet è una decisione di instradamento che entrambe le disposizioni possono gestire male.

Scrivete la risposta prima di fare clic su qualsiasi cosa, perché le due impostazioni non sono intercambiabili e annullare richiede più tempo che decidere. Due minuti di scrittura risparmiano un'ora di riconnessioni.

Cosa fa un ponte locale all'indirizzamento

Un ponte locale collega l'hub a un adattatore fisico, così l'hub diventa parte di quel segmento Ethernet. I client ricevono indirizzi da ciò che già serve il segmento, e il loro gateway è il router del segmento. Dal punto di vista del client, è entrato nella LAN dell'ufficio, con tutta la raggiungibilità e tutta l'esposizione che questo comporta.

Ciò significa anche che il ponte richiede un adattatore reale con il giusto supporto del driver e che l'amministratore deve essere autorizzato a estendere quel segmento. Un accesso VPN dimostra l'autenticazione, non il diritto di collocare un host su una VLAN di produzione. Verificate che il nome del driver corrisponda all'adattatore previsto, perché pontare la porta sbagliata abbatte rapidamente un segmento. Se l'elenco degli adattatori è vuoto o il ponte segnala un errore, la risposta di solito riguarda il driver o i privilegi, non la crittografia.

Leggete la tabella dei ponti dalla riga di comando quando l'albero grafico è ambiguo. L'output nomina l'adattatore, cosa che l'albero non sempre fa.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Un elenco di ponti vuoto con sessioni connesse è un quadro utile: i client sono dentro l'hub virtuale e nulla lo sta estendendo a un segmento.

Cosa aggiunge SecureNAT e cosa nasconde

SecureNAT dà all'hub un router virtuale, una funzione NAT e un servizio DHCP, tutto all'interno del processo SoftEther. I client ottengono indirizzi dall'intervallo DHCP virtuale, il router virtuale risponde per il gateway predefinito e il traffico che deve uscire viene tradotto. Nessun adattatore fisico è coinvolto, ed è per questo che funziona su un host con una sola scheda di rete e senza configurazione dello switch.

Il costo è che gli indirizzi virtuali appartengono all'hub e a nient'altro. Una macchina della LAN dell'ufficio non può instradare verso l'indirizzo SecureNAT di un client senza aiuto, e tutto ciò che registra gli indirizzi di origine vede l'indirizzo tradotto dell'host SoftEther. Se le vostre regole di accesso o la traccia di controllo dipendono dall'indirizzo reale del client, è un cambio di progettazione e non un dettaglio. Decide anche se una regola sull'indirizzo di origine vedrà mai il client.

È anche un server DHCP. Eseguirlo su un segmento che ne ha già uno, o pontare quel segmento nello stesso momento, produce due risponditori e lease imprevedibili. Il manuale tratta le due funzioni come scelte separate proprio per questo motivo.

Ispezionate ciò che l'hub sta servendo adesso prima di attivare qualsiasi altra cosa. Ogni comando stampa lo stato attuale, non quello previsto.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Attivare uno senza rompere l'altro

Scegliete la disposizione, attivatela e lasciate l'altra spenta. Un hub con ponte e con SecureNAT entrambi attivi è un hub con due possibili risposte alla stessa domanda, e il client crederà a quella che arriva prima. Quando migrate da una all'altra, disattivate la vecchia funzione e riconnettete il client invece di presumere che la nuova impostazione abbia effetto su una sessione esistente.

Ordinate il cambiamento in modo che il pool di client non si sovrapponga all'intervallo della LAN. Le sottoreti sovrapposte sono la seconda causa più comune di un tunnel che si connette e poi non raggiunge nulla, e sono invisibili finché non confrontate i due piani di indirizzamento fianco a fianco.

Poi riconnettetevi dal client e leggete cosa ha ricevuto, perché la visione dell'hub sulla sessione non è quella del client sulla propria rete. La riconnessione è l'unico modo affidabile per forzare un nuovo lease.

Verificate il gateway e il resolver sul client

Un'autenticazione riuscita vi dice che le credenziali funzionano e che l'hub ha accettato la sessione. Non dice nulla sulla capacità del client di raggiungere qualcosa, perché dipende dall'indirizzo, dalla maschera, dal gateway e dal server DNS che ha ricevuto. Leggete questi quattro valori sul client prima di toccare di nuovo un'impostazione del server.

Su Windows il dettaglio dell'adattatore mostra il lease e il resolver, e la tabella di routing mostra se il tunnel è davvero il percorso predefinito.

ipconfig /all
route print -4
nslookup intranet.corp.internal

Su un client Linux le stesse informazioni provengono dai file di indirizzi, route e resolver. La route predefinita è il valore che decide se il traffico esce o meno dal tunnel. Se il gateway punta al router dell'ufficio mentre il tunnel si aspetta di portare il traffico, la topologia è pontata di nome e rotta nella pratica. Correggete prima l'origine degli indirizzi, ritestate l'applicazione e solo allora considerate di cambiare l'altra modalità.