SoftEther VPN Azure: una ruta de retransmisión, no un puerto abierto

Su servidor está detrás de un router que no puede configurar, así que el plan obvio de reenviar un puerto no está disponible. VPN Azure existe justamente para esa situación, y la resuelve invirtiendo la dirección de la primera conexión: el servidor marca hacia un relay y los clientes alcanzan el relay en lugar del servidor. Entender esa inversión explica tanto lo que el servicio resuelve como cada límite con el que se topará después.

Qué cambia en la ruta

Con un listener convencional, un cliente abre una conexión TCP a una dirección pública que su router reenvía al servidor. Con el relay, el servidor mantiene una conexión saliente hacia la infraestructura del relay, y el relay acepta las conexiones de los clientes y pasa su carga al servidor que espera. No se abre ningún puerto entrante, no se requiere una dirección estática y el router permanece intacto. Desde el punto de vista del cortafuegos, el servidor es un cliente saliente ordinario, y por eso las redes restrictivas lo permiten.

El relay asigna a ese servidor un nombre en su propio dominio, y los clientes se configuran para conectarse allí.

Ese nombre pertenece al servicio de relay, que no es una Microsoft Azure VPN Gateway aunque ambos se llamen Azure algo. Tratarlos como intercambiables produce una configuración que no puede funcionar.

Qué protocolos sobreviven al relay

El relay transporta el protocolo SoftEther, y el proyecto documenta SSTP como opción de cliente, lo que resulta útil porque Windows incluye un cliente SSTP. No se convierte en un transportista genérico para cada listener del host: un listener de OpenVPN, un respondedor IPsec y un servicio L2TP necesitan cada uno su propio punto de acceso alcanzable, y ninguno se transporta por el relay solo porque el servidor SoftEther esté conectado.

Por tanto, los perfiles de cliente apuntan al nombre del relay en lugar de a la dirección del servidor, y un perfil existente creado para una conexión directa no funcionará sin cambios. Consulte la lista de clientes compatibles para la versión que ejecuta antes de diseñar en torno a un protocolo que el relay no transporta.

Lo que el relay no hace por usted

El relay es un transporte. No crea usuarios, hubs virtuales, políticas de acceso ni rutas, y no sabe nada de las redes privadas detrás de su servidor. Si los clientes remotos deben alcanzar una subred de LAN, el servidor sigue necesitando la configuración de puente o enrutamiento, la ruta de retorno y la política de cortafuegos que lo hacen funcionar. Los planes de direccionamiento superpuestos en ambos extremos también son invisibles para el relay y siguen siendo su problema a resolver.

Los ajustes de seguridad compatibles también son suyos para elegir. La documentación del proyecto incluye ejemplos de plataformas más antiguas, y copiar ajustes heredados de cifrado o certificados de una captura antigua es una buena forma de construir un túnel que nadie pueda auditar. Use la guía actual para la versión que ejecuta.

La validación de certificados y la autenticación de usuarios siguen siendo responsabilidad del servidor, y el relay nunca sustituye a ninguna de las dos.

Opérelo como una dependencia

La disponibilidad ahora incluye a un tercero. Cuando el relay no es accesible, los clientes no pueden conectarse por muy sano que esté su servidor, y el fallo parece un problema de cliente desde fuera. Vigile la ruta del relay por separado de la salud del servidor y mantenga un plan de reserva documentado, como un listener directo en otra dirección, para el día en que importe.

La latencia sigue la geografía del relay en lugar de la proximidad de sus usuarios, algo que merece medirse antes de prometer rendimiento interactivo sobre él.

Verifique la identidad del servidor y luego una ruta de aplicación real, no solo un banner de conexión correcta, y compruebe si el recurso que necesita es alcanzable sobre la familia de direcciones que transporta el relay. Anote el nombre del relay, el protocolo usado y el plan de reserva, porque esos tres datos responden a la mayoría de las preguntas futuras sobre este enlace.