Cascata SoftEther: collegare due hub virtuali di proposito
Una cascata collega un hub locale a uno remoto sotto un’identità configurata. Non è un nodo di uscita e trasporta tutto ciò che quegli hub già pontano.
Due hub SoftEther uniti da una cascata condividono un solo dominio di broadcast, quindi un loop o un secondo server DHCP smettono di essere un errore locale e diventano un errore condiviso. Questo è l’intero modello di rischio. La cascata in sé è una relazione client configurata: l’hub virtuale locale si connette verso l’hub di un server remoto sotto un’identità che quel server autorizza. È un elemento costitutivo per una rete virtuale più grande, mai un’uscita verso internet.
1. Decidete cosa deve trasportare il collegamento
Partite dal requisito, non dalla funzione. Una cascata sposta frame di livello due tra hub, ed è ciò che serve quando due siti devono sembrare un unico segmento Ethernet. Se l’esigenza è solo l’accesso instradato a poche sottoreti, un percorso instradato è più semplice e fallisce in modi più facili da vedere. Scegliere una cascata vi vincola a broadcast condiviso, scoperta condivisa e una sola topologia a loop.
Scrivete il requisito in una riga prima di toccare un server: quali sistemi devono apparire sullo stesso cavo e quali necessitano solo di una rotta. Tutto ciò che risponde «una rotta» resta fuori dalla cascata. Questa sola frase evita la maggior parte dei progetti che finiscono con servizi di indirizzi duplicati.
2. Delimitate l’identità che lo autorizza
Le credenziali che amministrano un server e l’identità che una cascata usa per connettersi sono segreti diversi, e mescolarli è una scorciatoia comune con una lunga coda. L’hub remoto necessita di una voce utente o di criterio che consenta a questa cascata di connettersi. Quella voce è l’autorizzazione; un accesso riuscito non dice nulla su ciò che sta dietro l’hub remoto.
Annotate quale hub inizia, a quale hub remoto si unisce e cosa può raggiungere l’identità remota. Confrontate le due architetture prima di impegnarvi:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
Mantenete aggiornate le credenziali e le istruzioni di ripristino di entrambe le estremità. Un cambio di password o una modifica di criterio sull’hub remoto rompe la cascata senza toccare i vostri utenti locali, e il guasto di solito appare come un collegamento attivo ma vuoto.
3. Ispezionate cosa trasporta già l’hub
Un hub è raramente isolato. Forse già fa ponte verso un adattatore fisico, instrada attraverso un router virtuale o fa cascata altrove, e ciascuno di questi collegamenti viene trasportato nella nuova relazione. Per questo «abbiamo solo unito due hub» si trasforma così spesso in «perché questi due siti sono ora un unico segmento?».
Due hub pontati nello stesso segmento fisico e poi messi in cascata l’uno verso l’altro formano un loop. Aggiungete spanning tree o non costruitelo. Lo stesso test vale per un hub che raggiunge già l’obiettivo attraverso un’altra cascata: un secondo collegamento non aggiunge capacità, aggiunge un percorso.
Non aggiungete un collegamento perché manca una rotta; correggete la rotta. Disegnate prima la topologia su carta, compresi ogni ponte e cascata, perché il diagramma richiede due minuti e intercetta la maggior parte dei loop prima che esistano.
4. Sistemate l’indirizzamento prima di unire
I segmenti uniti portano sottoreti duplicate, e i server DHCP duplicati sono il sintomo classico: i client prendono un lease dal server che risponde per primo, quindi il comportamento sembra casuale e si sposta tra i riavvii. Decidete in anticipo quale lato possiede l’assegnazione degli indirizzi e date al segmento lontano un intervallo che non si sovrapponga a nulla di locale. Disattivate l’altro servizio DHCP prima che la cascata sia online, non dopo la prima lamentela.
DNS è una questione separata. Una cascata trasporta frame; non configura resolver, e un nome che si risolve sul lato locale potrebbe non risolversi attraverso il collegamento. Testate la risoluzione separatamente dal percorso IP, perché un ping funzionante dimostra solo una delle due cose.
5. Dimostratelo con una risorsa reale
Scegliete un servizio consentito sul segmento remoto previsto e confermate che la risposta torna attraverso la cascata. Poi ripetete per la risoluzione dei nomi. Se l’obiettivo dipende dalla scoperta tramite broadcast, aspettatevi un comportamento diverso su un collegamento pontato rispetto a un solo cavo, e pianificatelo invece di registrarlo come difetto.
Infine, scrivete la topologia: quale hub fa cascata verso dove, quale identità la autorizza, quali segmenti sono pontati e chi possiede l’assegnazione degli indirizzi su ciascuno. Quella nota è ciò che permette alla persona successiva di cambiare un criterio senza abbattere un segmento che non sapeva esistesse.