Cascata SoftEther: ligar dois hubs virtuais de propósito
Uma cascata liga um hub local a um remoto sob uma identidade configurada. Não é um nó de saída, e transporta tudo o que esses hubs já fazem pontes.
Dois hubs SoftEther ligados por uma cascata partilham um único domínio de difusão, por isso um ciclo ou um segundo servidor DHCP deixa de ser um erro local e passa a ser um erro partilhado. É todo o modelo de risco. A cascata em si é uma relação de cliente configurada: o hub virtual local liga-se para fora ao hub de um servidor remoto sob uma identidade que esse servidor autoriza. É uma peça para uma rede virtual maior, nunca uma saída para a internet.
1. Decida o que a ligação tem de transportar
Comece pelo requisito, não pela funcionalidade. Uma cascata move tramas de camada dois entre hubs, e é isso que quer quando dois locais têm de parecer um único segmento Ethernet. Se a necessidade for apenas acesso encaminhado a algumas sub-redes, um caminho encaminhado é mais simples e falha de formas mais fáceis de ver. Escolher uma cascata compromete-o com difusão partilhada, descoberta partilhada e uma única topologia de ciclo.
Escreva o requisito numa linha antes de tocar num servidor: que sistemas têm de parecer estar no mesmo cabo, e quais só precisam de uma rota. Tudo o que responde «uma rota» fica fora da cascata. Esta única frase evita a maioria dos desenhos que acabam com serviços de endereços duplicados.
2. Delimite a identidade que o autoriza
As credenciais que administram um servidor e a identidade que uma cascata usa para ligar são segredos diferentes, e misturá-los é um atalho comum com cauda longa. O hub remoto precisa de uma entrada de utilizador ou de política que permita a esta cascata ligar-se. Essa entrada é a autorização; um início de sessão bem-sucedido não diz nada sobre o que está por trás do hub remoto.
Registe que hub inicia, a que hub remoto se junta e o que a identidade remota pode alcançar. Compare as duas arquiteturas antes de se comprometer:
| 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 |
Mantenha atualizadas as credenciais e as instruções de recuperação das duas pontas. Uma mudança de palavra-passe ou uma edição de política no hub remoto quebra a cascata sem tocar nos seus utilizadores locais, e a falha aparece normalmente como uma ligação ativa mas vazia.
3. Inspecione o que o hub já transporta
Um hub raramente está isolado. Pode já fazer ponte para um adaptador físico, encaminhar através de um router virtual ou fazer cascata noutro lugar, e cada uma dessas ligações é transportada para a nova relação. É por isso que «só ligámos dois hubs» tantas vezes se transforma em «porque é que estes dois locais são agora um só segmento?».
Dois hubs ligados em ponte ao mesmo segmento físico e depois em cascata um para o outro formam um ciclo. Adicione spanning tree ou não o construa. O mesmo teste aplica-se a um hub que já alcança o objetivo por outra cascata: uma segunda ligação não acrescenta capacidade, acrescenta um caminho.
Não acrescente uma ligação porque falta uma rota; corrija a rota. Desenhe primeiro a topologia em papel, incluindo cada ponte e cascata, porque o diagrama leva dois minutos e apanha a maioria dos ciclos antes de existirem.
4. Resolva o endereçamento antes de juntar
Os segmentos unidos trazem sub-redes duplicadas, e os servidores DHCP duplicados são o sintoma clássico: os clientes obtêm uma concessão do servidor que responder primeiro, por isso o comportamento parece aleatório e muda entre reinícios. Decida antecipadamente que lado detém a atribuição de endereços, e dê ao segmento distante um intervalo que não se sobreponha a nada local. Desative o outro serviço DHCP antes de a cascata ficar online, não depois da primeira queixa.
DNS é uma questão separada. Uma cascata transporta tramas; não configura resolvedores, e um nome que resolve do lado local pode não resolver através da ligação. Teste a consulta separadamente do caminho IP, porque um ping a funcionar só prova uma das duas coisas.
5. Demostre-o com um recurso real
Escolha um serviço permitido no segmento remoto pretendido e confirme que a resposta volta através da cascata. Depois repita para a resolução de nomes. Se o alvo depende da descoberta por difusão, espere um comportamento diferente numa ligação com ponte do que num único cabo, e planeie isso em vez de o registar como defeito.
Por fim, escreva a topologia: que hub faz cascata para onde, que identidade o autoriza, que segmentos têm ponte e quem detém a atribuição de endereços em cada um. Essa nota é o que permite à pessoa seguinte mudar uma política sem derrubar um segmento que não sabia existir.