SoftEther tras NAT: ¿atravesar directamente o usar un relé de VPN Azure?

Su servidor SoftEther está detrás de un router del proveedor que no puede cambiar, y los clientes siguen conectándose, así que supone que un relé lo transporta todo. Si eso es cierto depende de qué mecanismo hizo el trabajo: un nombre DNS, una ruta UDP coordinada o un túnel saliente hacia un relé. Los tres pueden producir un cliente conectado, y fallan en condiciones distintas. Decida qué ruta compra antes de tocar usuarios o concentradores.

Tres mecanismos, tres promesas distintas

El DNS dinámico es nomenclatura. Mantiene un nombre de host apuntando a una dirección cambiante para que la gente deje de perseguir el número, y no hace nada más. La atravesadura NAT nativa es coordinación: dos extremos de SoftEther intercambian información e intentan abrir una ruta UDP utilizable a través de los dispositivos de traducción entre ellos. VPN Azure es un relé: el servidor marca hacia el servicio, y los clientes llegan mediante un nombre de host en la infraestructura del relé.

Los tres son complementarios, no versiones de una sola función. Un despliegue puede usar nomenclatura mientras su conexión depende en realidad de la atravesadura o del relé.

Decida a partir del cliente y de la red

La elección empieza por el cliente, porque la atravesadura solo existe en el mecanismo de conexión nativo de SoftEther. OpenVPN, L2TP/IPsec y los oyentes SSTP del mismo servidor no la heredan, aunque comparten un host. Mire lo que ejecutará el usuario y luego lo que permite la red. Una red corporativa que solo permite TCP 443 le empuja hacia un relé en ese puerto, mientras que una red que deja pasar los puertos UDP que necesita la atravesadura puede intentar una ruta directa; confirme ambas contra la política real de salida.

Un oyente accesible manualmente sigue siendo un diseño legítimo cuando un administrador puede publicar uno, pero es un proyecto aparte con su propio direccionamiento y trabajo de cortafuegos.

Confirme qué transporte eligió la sesión

El estado de la conexión es la única fuente honesta de la ruta en uso. Léalo en el servidor y resuelva el nombre de host que recibió el cliente.

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList muestra qué sesiones están conectadas, y SessionGet sobre una de ellas informa del tipo de conexión, incluido si la sesión llegó por el relé. Un registro que resuelve a la infraestructura del relé le dice que la sesión pasa por un tercero, lo que puede confirmar bloqueando esa ruta en una prueba. Con un cliente nativo, la aceleración UDP puede alejar la ruta de datos de la ruta de control, así que una observación no describe toda la sesión. Un nombre de DNS dinámico obsoleto tras un cambio de dirección, y un relé que responde mientras falta la ruta de backend, son dos modos de fallo que conviene probar por separado. Anote lo que midió, no lo que el diseño pretendía.

Planifique de qué depende la ruta elegida

Cada ruta conlleva una dependencia. Una atravesadura directa puede cambiar tras una transición de red o un dispositivo de traducción nuevo, mientras que una sesión de relé falla cuando falla el servicio o su puerto accesible. Reconéctese desde otra red y confirme la identidad del servidor que el cliente verificó, manteniendo la ruta que antes funcionaba en la misma prueba. Después pruebe el recurso privado detrás de la VPN, porque la autorización, la pertenencia al concentrador, la asignación de direcciones y las rutas de retorno siguen siendo su responsabilidad en cualquier caso.

Anote el nombre de host, el protocolo, los ajustes de la función y el transporte observado. Ese registro en cuatro partes es lo que permite a la siguiente persona reproducir una conexión que funciona.