SoftEther VPN Azure: unha ruta de retransmisión, non un porto aberto

O seu servidor está detrás dun router que non pode configurar, así que o plan obvio de reenviar un porto non está dispoñible. VPN Azure existe xustamente para esa situación, e resólvea invertendo a dirección da primeira conexión: o servidor marca cara a un relay e os clientes alcanzan o relay en lugar do servidor. Entender esa inversión explica tanto o que o servizo resolve como cada límite co que se atopará despois.

Que cambia na ruta

Cun listener convencional, un cliente abre unha conexión TCP a un enderezo público que o seu router reenvía ao servidor. Co relay, o servidor mantén unha conexión saínte cara á infraestrutura do relay, e o relay acepta as conexións dos clientes e pasa a súa carga ao servidor que espera. Non se abre ningún porto entrante, non se require un enderezo estático e o router permanece intacto. Desde o punto de vista da devasa, o servidor é un cliente saínte ordinario, e por iso as redes restritivas permíteno.

O relay asigna a ese servidor un nome no seu propio dominio, e os clientes configúranse para conectarse alí.

Ese nome pertence ao servizo de relay, que non é unha Microsoft Azure VPN Gateway aínda que ambos se chamen Azure algo. Tratalos como intercambiables produce unha configuración que non pode funcionar.

Que protocolos sobreviven ao relay

O relay transporta o protocolo SoftEther, e o proxecto documenta SSTP como opción de cliente, o que resulta útil porque Windows inclúe un cliente SSTP. Non se converte nun transportista xenérico para cada listener do host: un listener de OpenVPN, un respondedor IPsec e un servizo L2TP necesitan cada un o seu propio punto de acceso alcanzable, e ningún se transporta polo relay só porque o servidor SoftEther estea conectado.

Por tanto, os perfís de cliente apuntan ao nome do relay en lugar de ao enderezo do servidor, e un perfil existente creado para unha conexión directa non funcionará sen cambios. Consulte a lista de clientes compatibles para a versión que executa antes de deseñar arredor dun protocolo que o relay non transporta.

O que o relay non fai por vostede

O relay é un transporte. Non crea usuarios, hubs virtuais, políticas de acceso nin rutas, e non sabe nada das redes privadas detrás do seu servidor. Se os clientes remotos deben alcanzar unha subrede de LAN, o servidor segue necesitando a configuración de ponte ou encamiñamento, a ruta de retorno e a política de devasa que o fan funcionar. Os plans de direccionamento solapados nos dous extremos tamén son invisibles para o relay e seguen sendo o seu problema a resolver.

Os axustes de seguridade compatibles tamén son seus para escoller. A documentación do proxecto inclúe exemplos de plataformas máis antigas, e copiar axustes herdados de cifrado ou certificados dunha captura antiga é unha boa forma de construír un túnel que ninguén poida auditar. Use a guía actual para a versión que executa.

A validación de certificados e a autenticación de usuarios seguen sendo responsabilidade do servidor, e o relay nunca substitúe ningunha das dúas.

Opéreo como unha dependencia

A dispoñibilidade agora inclúe un terceiro. Cando o relay non é accesible, os clientes non poden conectarse por moi san que estea o seu servidor, e o fallo parece un problema de cliente desde fóra. Vixíe a ruta do relay por separado da saúde do servidor e manteña un plan de reserva documentado, como un listener directo noutro enderezo, para o día en que importe.

A latencia segue a xeografía do relay en lugar da proximidade dos seus usuarios, algo que paga a pena medir antes de prometer rendemento interactivo sobre el.

Verifique a identidade do servidor e logo unha ruta de aplicación real, non só un banner de conexión correcta, e comprobe se o recurso que necesita é alcanzable sobre a familia de enderezos que transporta o relay. Anote o nome do relay, o protocolo usado e o plan de reserva, porque eses tres datos responden á maioría das preguntas futuras sobre esta ligazón.