Qué conecta realmente un hub virtual de SoftEther

El hub virtual de SoftEther es una frontera de pertenencia dentro de un servidor, no una ubicación. Las sesiones que se unen al hub pueden llegar a aquello a lo que está conectado el hub, y las sesiones de otro hub no pueden, incluso cuando ambas se autentican contra el mismo servidor. Por eso un inicio de sesión correcto todavía puede colocar a un cliente en la red equivocada. Leer el hub como un conmutador virtual aclara qué hace y qué deja al puente, el enrutamiento y la configuración en cascada.

Un hub es una frontera de pertenencia

Un servidor puede alojar varios hubs, cada uno con sus propios usuarios, sesiones y política. La autenticación establece quién es la sesión, mientras que el hub decide a qué red virtual se une esa sesión. Dos hubs en un mismo host se comportan, por tanto, como dos conmutadores separados que casualmente comparten hardware. Nada en un inicio de sesión correcto implica que la sesión haya aterrizado donde querías.

Use el nombre de hub documentado por el operador en lugar de un nombre recordado de una captura de pantalla. Un cliente que se une al hub equivocado llega a otra red con una credencial válida, lo que es un hallazgo de configuración y no una brecha de seguridad. Guarde el nombre del hub y su propósito en las notas del perfil de conexión.

La administración está delimitada de la misma manera. Un administrador de hub gestiona ese hub, mientras que el administrador del servidor gestiona el proceso, los oyentes y cada hub del host.

Las conexiones deciden qué hay más allá

Un hub por sí solo conecta las sesiones entre sí. Llegar a cualquier otra cosa depende de cómo esté conectado el hub: un puente local a una interfaz física, un enrutador virtual o una cascada a otro servidor. Cada conexión lleva sus propias reglas de reenvío y sus propias formas de fallar. Suponer que un hub proporciona acceso a internet es el error más común sobre el producto.

SecureNAT es la opción integrada, implementada con un enrutador virtual y un servicio DHCP virtual dentro del servidor. Es cómoda para un laboratorio e incómoda para todo lo que necesite direccionamiento o política predecibles. Un puente local pone el hub en un segmento real, que hereda la conmutación, el DHCP y el comportamiento de difusión de ese segmento.

Una cascada enlaza dos servidores para que las sesiones de un hub puedan aparecer en el otro. Es una relación de hub a hub, así que ambos extremos necesitan una política compatible y un camino que funcione entre ellos.

Lea las sesiones y la política por separado

Las vistas de sesiones, direcciones MAC y direcciones IP describen cómo es la red virtual ahora. Son observaciones, no permisos. Una sesión visible en la lista no queda por ello autorizada a todos los servicios a los que puede llegar el hub, y lo contrario también vale.

Compare la lista de sesiones con la política que debería aplicarse. Un dispositivo con una dirección fuera del rango previsto normalmente significa DHCP de otro lugar o un cliente configurado a mano. Una dirección MAC que se mueve entre sesiones significa un dispositivo migrado o dos dispositivos que comparten una identidad. Ambos merecen un vistazo, y ninguno se demuestra solo con la tabla.

En el servidor, vpncmd informa de la misma imagen desde el punto de vista del host. Compare esa salida con la vista propia del cliente siempre que las dos discrepen.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Trate la administración del hub como un rol propio y no como un permiso de cliente. Delegar un hub no debería entregar los oyentes ni el proceso que aloja todos los demás hubs.

Compruebe el cliente después de unirse

Desde el lado del cliente, una sesión establecida solo demuestra que se aceptaron la autenticación y el nombre del hub. Confirme la dirección, la ruta y la resolución de nombres por separado, porque cada una puede fallar después de que el hub acepte la sesión.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

La lista de direcciones muestra si el adaptador recibió una concesión de la fuente prevista. La consulta de ruta muestra qué interfaz llevaría un destino privado, y la consulta al resolver muestra si el DNS siguió la sesión. Un hub que reenvía paquetes mientras el DNS sigue apuntando a la red local produce la clásica conexión medio funcionando.

Pruebe la aplicación y no el enlace. Una página de intranet que carga es una prueba más fuerte que un adaptador con una dirección plausible.