SoftEther VPN Azure: um caminho de retransmissão, não uma porta aberta

O seu servidor está atrás de um router que não consegue configurar, pelo que o plano óbvio de encaminhar uma porta não está disponível. VPN Azure existe exatamente para essa situação, e resolve-a invertendo a direção da primeira ligação: o servidor liga para fora a um relay, e os clientes alcançam o relay em vez do servidor. Compreender essa inversão explica tanto o que o serviço corrige como cada limite com que se deparará mais tarde.

O que muda no caminho

Com um listener convencional, um cliente abre uma ligação TCP para um endereço público que o seu router encaminha para o servidor. Com o relay, o servidor mantém uma ligação de saída para a infraestrutura do relay, e o relay aceita as ligações dos clientes e passa a sua carga ao servidor que espera. Nenhuma porta de entrada é aberta, nenhum endereço estático é necessário, e o router fica intacto. Do ponto de vista da firewall, o servidor é um cliente de saída comum, e é por isso que as redes restritivas o permitem.

O relay atribui a esse servidor um nome no seu próprio domínio, e os clientes são configurados para se ligarem lá.

Esse nome pertence ao serviço de relay, que não é um Microsoft Azure VPN Gateway embora ambos se chamem Azure algo. Tratá-los como permutáveis produz uma configuração que não pode funcionar.

Que protocolos sobrevivem ao relay

O relay transporta o protocolo SoftEther, e o projeto documenta SSTP como opção de cliente, o que é útil porque o Windows inclui um cliente SSTP. Não se torna, porém, um transportador genérico para cada listener do anfitrião: um listener de OpenVPN, um respondedor IPsec e um serviço L2TP precisam cada um do seu próprio ponto final acessível, e nenhum deles é transportado pelo relay só porque o servidor SoftEther está ligado.

Os perfis de cliente apontam, portanto, para o nome do relay em vez do endereço do servidor, e um perfil existente criado para uma ligação direta não funcionará sem alterações. Consulte a lista de clientes suportados para a versão que executa antes de desenhar em torno de um protocolo que o relay não transporta.

O que o relay não faz por si

O relay é um transporte. Não cria utilizadores, hubs virtuais, políticas de acesso ou rotas, e não sabe nada sobre as redes privadas atrás do seu servidor. Se os clientes remotos tiverem de alcançar uma sub-rede de LAN, o servidor continua a precisar da configuração de ponte ou de encaminhamento, do caminho de retorno e da política de firewall que o fazem funcionar. Planos de endereçamento sobrepostos nas duas extremidades também são invisíveis para o relay e continuam a ser o seu problema a resolver.

As definições de segurança suportadas também são suas para escolher. A documentação do projeto inclui exemplos de plataformas mais antigas, e copiar definições herdadas de cifra ou certificados de uma captura antiga é uma boa forma de construir um túnel que ninguém pode auditar. Utilize a orientação atual para a versão que executa.

A validação de certificados e a autenticação de utilizadores continuam a ser responsabilidade do servidor, e o relay nunca substitui nenhuma delas.

Opere-o como uma dependência

A disponibilidade passa agora a incluir um terceiro. Quando o relay está inacessível, os clientes não conseguem ligar-se por muito saudável que esteja o seu servidor, e a falha parece, do exterior, um problema de cliente. Monitorize o caminho do relay separadamente da saúde do servidor e mantenha um plano de recurso documentado, como um listener direto noutro endereço, para o dia em que importar.

A latência segue a geografia do relay em vez da proximidade dos seus utilizadores, algo que vale a pena medir antes de prometer desempenho interativo por seu intermédio.

Verifique a identidade do servidor e depois um caminho de aplicação real, não apenas um banner de ligação bem-sucedida, e confirme se o recurso de que precisa é alcançável sobre a família de endereços que o relay transporta. Registe o nome do relay, o protocolo utilizado e o plano de recurso, porque esses três factos respondem à maioria das perguntas futuras sobre esta ligação.