Cascada de SoftEther: une dous hubs virtuais a propósito
Unha cascada une un hub local cun remoto baixo unha identidade configurada. Non é un nodo de saída e transporta todo o que eses hubs xa pontan.
Dous hubs de SoftEther unidos por unha cascada comparten un só dominio de difusión, así que un bucle ou un segundo servidor DHCP deixa de ser un erro local e pasa a ser compartido. Ese é todo o modelo de risco. A cascada en si é unha relación de cliente configurada: o hub virtual local conéctase cara ao hub dun servidor remoto baixo unha identidade que ese servidor autoriza. É unha peza para unha rede virtual maior, nunca unha saída a internet.
1. Decide que debe transportar a ligazón
Empeza polo requisito, non pola función. Unha cascada move tramas de capa dous entre hubs, que é o que queres cando dous sitios deben parecer un só segmento Ethernet. Se a necesidade é só acceso encamiñado a unhas poucas subredes, unha ruta encamiñada é máis simple e falla de maneiras máis doadas de ver. Escoller unha cascada comprométete con difusión compartida, descuberta compartida e unha soa topoloxía de bucle.
Escribe o requisito nunha liña antes de tocar un servidor: que sistemas deben aparecer no mesmo cable e cales só necesitan unha ruta. Todo o que responde «unha ruta» queda fóra da cascada. Esta soa frase evita a maioría dos deseños que acaban con servizos de enderezos duplicados.
2. Delimita a identidade que o autoriza
As credenciais que administran un servidor e a identidade que unha cascada usa para conectarse son segredos distintos, e mesturalos é un atallo habitual con cola longa. O hub remoto necesita unha entrada de usuario ou de política que permita conectarse a esta cascada. Esa entrada é a autorización; un inicio de sesión correcto non di nada sobre o que hai detrás do hub remoto.
Anota que hub inicia, a que hub remoto se une e que pode acadar a identidade remota. Compara as dúas arquitecturas antes de comprometerte:
| 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 |
Mantén ao día as credenciais e as instrucións de recuperación dos dous extremos. Un cambio de contrasinal ou unha edición de política no hub remoto rompe a cascada sen tocar os teus usuarios locais, e o fallo adoita aparecer como unha ligazón que está activa pero baleira.
3. Inspecciona que xa transporta o hub
Un hub raramente está illado. Pode que xa ponte un adaptador físico, encamiña a través dun encamiñador virtual ou fai cascada noutro sitio, e cada unha desas conexións trasládase á nova relación. Por iso «só unimos dous hubs» tantas veces se converte en «por que estes dous sitios son agora un só segmento?».
Dous hubs pontados no mesmo segmento físico e despois en cascada entre si forman un bucle. Engade spanning tree ou non o constrúas. A mesma proba se aplica a un hub que xa acada o obxectivo por outra cascada: unha segunda ligazón non engade capacidade, engade un camiño.
Non engadas unha ligazón porque falte unha ruta; arranxa a ruta. Debuxa primeiro a topoloxía en papel, incluíndo cada ponte e cascada, porque o diagrama leva dous minutos e atrapa a maioría dos bucles antes de que existan.
4. Resolve o enderezamento antes de unir
Os segmentos unidos traen subredes duplicadas, e os servidores DHCP duplicados son o síntoma clásico: os clientes toman unha concesión do servidor que responda primeiro, así que o comportamento parece aleatorio e móvese entre reinicios. Decide de antemán que lado posúe a asignación de enderezos e dálle ao segmento afastado un rango que non se solape con nada local. Desactiva o outro servizo DHCP antes de que a cascada estea en liña, non despois da primeira queixa.
DNS é unha cuestión aparte. Unha cascada transporta tramas; non configura resolucións, e un nome que se resolve no lado local pode non resolverse a través da ligazón. Proba a consulta por separado da ruta IP, porque un ping que funciona só demostra unha das dúas cousas.
5. Demostrao cun recurso real
Escolle un servizo permitido no segmento remoto previsto e confirma que a resposta volve pola cascada. Despois repite para a resolución de nomes. Se o obxectivo depende da descuberta por difusión, espera un comportamento distinto nunha ligazón pontada que nun só cable, e planifícao en lugar de rexistralo como defecto.
Por último, escribe a topoloxía: que hub fai cascada cara a onde, que identidade o autoriza, que segmentos están pontados e quen posúe a asignación de enderezos en cada un. Esa nota é o que permite á persoa seguinte cambiar unha política sen derrubar un segmento que non sabía que existía.