SoftEther atrás de NAT: travessia direta ou relay do VPN Azure?

O seu servidor SoftEther está atrás de um router do fornecedor que não pode alterar, e os clientes continuam a ligar-se, por isso assume que um relay transporta tudo. Se isso é verdade depende do mecanismo que fez o trabalho: um nome DNS, um caminho UDP coordenado ou um túnel de saída para um relay. Os três podem produzir um cliente ligado, e falham em condições diferentes. Decida qual caminho compra antes de tocar em utilizadores ou concentradores.

Três mecanismos, três promessas diferentes

O DNS dinâmico é nomenclatura. Mantém um nome de anfitrião apontado para um endereço que muda para que as pessoas deixem de perseguir o número, e não faz mais nada. A travessia NAT nativa é coordenação: dois extremos SoftEther trocam informações e tentam abrir um caminho UDP utilizável através dos dispositivos de tradução entre eles. O VPN Azure é um relay: o servidor liga-se ao serviço, e os clientes chegam através de um nome de anfitrião na infraestrutura do relay.

Os três são complementares, não versões de uma única funcionalidade. Uma implementação pode usar nomenclatura enquanto a sua ligação depende na realidade da travessia ou do relay.

Decida a partir do cliente e da rede

A escolha começa no cliente, porque a travessia só existe no mecanismo de ligação nativo do SoftEther. OpenVPN, L2TP/IPsec e os ouvintes SSTP no mesmo servidor não a herdam, embora partilhem um anfitrião. Veja o que o utilizador vai executar e depois o que a rede permite. Uma rede empresarial que só permite TCP 443 empurra-o para um relay nessa porta, enquanto uma rede que deixa passar as portas UDP de que a travessia precisa pode tentar um caminho direto; confirme ambos contra a política real de saída.

Um ouvinte acessível manualmente continua a ser um desenho legítimo quando um administrador pode publicar um, mas é um projeto separado com o seu próprio endereçamento e trabalho de firewall.

Confirme que transporte a sessão escolheu

O estado da ligação é a única fonte honesta do caminho em uso. Leia-o no servidor e resolva o nome de anfitrião que o cliente recebeu.

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

O SessionList mostra que sessões estão ligadas, e o SessionGet numa delas indica o tipo de ligação, incluindo se a sessão chegou pelo relay. Um registo que resolve para a infraestrutura do relay diz-lhe que a sessão passa por um terceiro, o que pode confirmar bloqueando essa rota num teste. Com um cliente nativo, a aceleração UDP pode afastar o caminho de dados do caminho de controlo, por isso uma observação não descreve a sessão inteira. Um nome de DNS dinâmico obsoleto após uma mudança de endereço, e um relay que responde enquanto falta a rota de backend, são dois modos de falha que vale a pena testar em separado. Registe o que mediu, não o que o desenho pretendia.

Planeie de que depende o caminho escolhido

Cada caminho carrega uma dependência. Uma travessia direta pode mudar após uma transição de rede ou um novo dispositivo de tradução, enquanto uma sessão de relay falha quando o serviço ou a sua porta acessível falha. Volte a ligar-se a partir de outra rede e confirme a identidade do servidor que o cliente verificou, mantendo o caminho que funcionava antes no mesmo teste. Depois teste o recurso privado atrás da VPN, porque autorização, pertença ao concentrador, atribuição de endereços e rotas de retorno continuam a ser sua responsabilidade em qualquer caso.

Registe o nome de anfitrião, o protocolo, as definições da funcionalidade e o transporte observado. É esse registo em quatro partes que permite à pessoa seguinte reproduzir uma ligação funcional.