Cascada de SoftEther: une dos hubs virtuales a propósito
Una cascada une un hub local con uno remoto bajo una identidad configurada. No es un nodo de salida y transporta todo lo que esos hubs ya puentean.
Dos hubs de SoftEther unidos por una cascada comparten un solo dominio de difusión, así que un bucle o un segundo servidor DHCP deja de ser un error local y pasa a ser uno compartido. Ese es todo el modelo de riesgo. La cascada en sí es una relación de cliente configurada: el hub virtual local se conecta hacia el hub de un servidor remoto bajo una identidad que ese servidor autoriza. Es una pieza para una red virtual mayor, nunca una salida a internet.
1. Decida qué debe transportar el enlace
Empiece por el requisito, no por la función. Una cascada mueve tramas de capa dos entre hubs, que es lo que se quiere cuando dos sitios deben parecer un solo segmento Ethernet. Si la necesidad es solo acceso enrutado a unas pocas subredes, una ruta enrutada es más simple y falla de maneras más fáciles de ver. Elegir una cascada le compromete con difusión compartida, descubrimiento compartido y una sola topología de bucle.
Escriba el requisito en una línea antes de tocar un servidor: qué sistemas deben aparecer en el mismo cable y cuáles solo necesitan una ruta. Todo lo que responde «una ruta» queda fuera de la cascada. Esta sola frase evita la mayoría de los diseños que acaban con servicios de direcciones duplicados.
2. Delimite la identidad que lo autoriza
Las credenciales que administran un servidor y la identidad que una cascada usa para conectarse son secretos distintos, y mezclarlos es un atajo habitual con cola larga. El hub remoto necesita una entrada de usuario o de política que permita conectarse a esta cascada. Esa entrada es la autorización; un inicio de sesión correcto no dice nada sobre lo que hay detrás del hub remoto.
Anote qué hub inicia, a qué hub remoto se une y qué puede alcanzar la identidad remota. Compare las dos arquitecturas antes de comprometerse:
| 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 |
Mantenga al día las credenciales y las instrucciones de recuperación de ambos extremos. Un cambio de contraseña o una edición de política en el hub remoto rompe la cascada sin tocar a sus usuarios locales, y el fallo suele aparecer como un enlace que está activo pero vacío.
3. Inspeccione qué transporta ya el hub
Un hub rara vez está aislado. Puede que ya puentee un adaptador físico, enrute a través de un enrutador virtual o haga cascada en otro sitio, y cada una de esas conexiones se traslada a la nueva relación. Por eso «solo unimos dos hubs» tantas veces se convierte en «¿por qué estos dos sitios son ahora un solo segmento?».
Dos hubs puenteados al mismo segmento físico y luego en cascada entre sí forman un bucle. Añada spanning tree o no lo construya. La misma prueba se aplica a un hub que ya alcanza el objetivo por otra cascada: un segundo enlace no añade capacidad, añade un camino.
No añada un enlace porque falte una ruta; arregle la ruta. Dibuje primero la topología en papel, incluidos cada puente y cascada, porque el diagrama tarda dos minutos y atrapa la mayoría de los bucles antes de que existan.
4. Resuelva el direccionamiento antes de unir
Los segmentos unidos traen subredes duplicadas, y los servidores DHCP duplicados son el síntoma clásico: los clientes toman una concesión del servidor que responda primero, así que el comportamiento parece aleatorio y se mueve entre reinicios. Decida de antemano qué lado posee la asignación de direcciones y dé al segmento lejano un rango que no se solape con nada local. Desactive el otro servicio DHCP antes de que la cascada esté en línea, no después de la primera queja.
DNS es una cuestión aparte. Una cascada transporta tramas; no configura resolutores, y un nombre que se resuelve en el lado local puede no resolverse a través del enlace. Pruebe la consulta por separado de la ruta IP, porque un ping que funciona solo demuestra una de las dos cosas.
5. Demuéstrelo con un recurso real
Elija un servicio permitido en el segmento remoto previsto y confirme que la respuesta vuelve por la cascada. Luego repita para la resolución de nombres. Si el objetivo depende del descubrimiento por difusión, espere un comportamiento distinto en un enlace puenteado que en un solo cable, y planifíquelo en lugar de registrarlo como defecto.
Por último, escriba la topología: qué hub hace cascada hacia dónde, qué identidad lo autoriza, qué segmentos están puenteados y quién posee la asignación de direcciones en cada uno. Esa nota es lo que permite a la siguiente persona cambiar una política sin derribar un segmento que no sabía que existía.