Puente local de SoftEther o SecureNAT: cuál activar

Abra SoftEther Manager y la primera decisión real sobre un hub no es una casilla, es una cuestión de topología. Un puente local conecta ese hub a un adaptador físico y deja que el segmento existente proporcione el direccionamiento, mientras que SecureNAT le da al hub su propio router virtual, NAT y DHCP. Elegir entre ambos cambia de dónde vienen las direcciones y qué dispositivo responde por ellas. Activar los dos y esperar que uno gane es la forma en que un laboratorio que funciona se convierte en un hilo de soporte.

Empiece por el hub que realmente está editando

Manager muestra un árbol de servidores y hubs, y es fácil configurar el hub predeterminado mientras los clientes se conectan a otro con un nombre distinto. Haga clic en el hub, lea su nombre y confirme que las sesiones que aparecen debajo son los clientes que intenta atender. Esa única comprobación evita la mayor parte de la confusión que luego se atribuye al protocolo.

Después decida qué necesita el cliente del extremo remoto. El comportamiento Ethernet compartido con difusión y servicios de LAN apunta a un puente, el acceso privado enrutado a un rango pequeño de direcciones apunta a SecureNAT, y una salida a internet es una decisión de enrutamiento que cualquiera de las dos disposiciones puede llevar mal.

Escriba la respuesta antes de hacer clic en nada, porque los dos ajustes no son intercambiables y deshacerlo lleva más tiempo que decidir. Dos minutos de escritura ahorran una hora de reconexiones.

Qué hace un puente local con el direccionamiento

Un puente local conecta el hub a un adaptador físico, así que el hub pasa a formar parte de ese segmento Ethernet. Los clientes reciben direcciones de lo que ya sirve al segmento, y su puerta de enlace es el router del segmento. Desde el punto de vista del cliente, se ha unido a la LAN de la oficina, con toda la accesibilidad y toda la exposición que eso implica.

Eso también significa que el puente necesita un adaptador real con el soporte de controlador adecuado y que el administrador debe estar autorizado a extender ese segmento. Un inicio de sesión VPN demuestra autenticación, no el derecho a colocar un host en una VLAN de producción. Compruebe que el nombre del controlador coincide con el adaptador que pretende, porque puentear el puerto equivocado tumba un segmento con rapidez. Si la lista de adaptadores está vacía o el puente informa de un fallo, la respuesta normalmente tiene que ver con el controlador o los privilegios, no con la criptografía.

Lea la tabla de puentes desde la línea de comandos cuando el árbol gráfico sea ambiguo. La salida nombra el adaptador, cosa que el árbol no siempre hace.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

Una lista de puentes vacía con sesiones conectadas es una imagen útil: los clientes están dentro del hub virtual y nada lo extiende todavía a un segmento.

Qué añade SecureNAT y qué oculta

SecureNAT le da al hub un router virtual, una función NAT y un servicio DHCP, todo dentro del proceso de SoftEther. Los clientes obtienen direcciones del rango DHCP virtual, el router virtual responde por la puerta de enlace predeterminada y el tráfico que necesita salir se traduce. No interviene ningún adaptador físico, y por eso funciona en un host con una sola tarjeta de red y sin configuración de conmutador.

El coste es que las direcciones virtuales pertenecen al hub y a nada más. Una máquina de la LAN de la oficina no puede enrutar hacia la dirección SecureNAT de un cliente sin ayuda, y todo lo que registra direcciones de origen ve la dirección traducida del host de SoftEther. Si sus reglas de acceso o su rastro de auditoría dependen de la dirección real del cliente, eso es un cambio de diseño y no un detalle. También decide si una regla de dirección de origen llegará a ver al cliente.

También es un servidor DHCP. Ejecutarlo en un segmento que ya tiene uno, o puentear ese segmento al mismo tiempo, produce dos respondedores y concesiones impredecibles. El manual trata las dos funciones como opciones separadas exactamente por eso.

Inspeccione qué está sirviendo el hub ahora mismo antes de activar cualquier otra cosa. Cada comando imprime el estado actual, no el previsto.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Activar uno sin romper el otro

Elija la disposición, actívela y deje la otra apagada. Un hub con puente y con SecureNAT ambos activos es un hub con dos respuestas posibles a la misma pregunta, y el cliente creerá la que llegue primero. Cuando migre de una a la otra, desactive la función antigua y vuelva a conectar el cliente en lugar de suponer que el nuevo ajuste surte efecto en una sesión existente.

Ordene el cambio de modo que el grupo de clientes no se solape con el rango de la LAN. Las subredes solapadas son la segunda causa más común de un túnel que se conecta y luego no alcanza nada, y son invisibles hasta que compara los dos planes de direccionamiento lado a lado.

Después vuelva a conectar desde el cliente y lea qué recibió, porque la visión del hub sobre la sesión no es la visión del cliente sobre su propia red. Reconectar es la única forma fiable de forzar una concesión nueva.

Compruebe la puerta de enlace y el resolutor en el cliente

Una autenticación correcta le dice que las credenciales funcionan y que el hub aceptó la sesión. No dice nada sobre si el cliente alcanza algo, porque eso depende de la dirección, la máscara, la puerta de enlace y el servidor DNS que recibió. Lea esos cuatro valores en el cliente antes de tocar de nuevo un ajuste del servidor.

En Windows el detalle del adaptador muestra la concesión y el resolutor, y la tabla de rutas muestra si el túnel es realmente la ruta predeterminada.

ipconfig /all
route print -4
nslookup intranet.corp.internal

En un cliente Linux la misma información proviene de los archivos de direcciones, rutas y resolutor. La ruta predeterminada es el valor que decide si el tráfico sale o no por el túnel. Si la puerta de enlace apunta al router de la oficina mientras el túnel espera transportar el tráfico, la topología está puenteada de nombre y rota en la práctica. Corrija primero el origen de las direcciones, vuelva a probar la aplicación y solo entonces considere cambiar el otro modo.