SoftEther detrás de NAT: atravesamento directo ou relé de VPN Azure?

O seu servidor SoftEther está detrás dun router do provedor que non pode cambiar, e os clientes seguen conectándose, así que supón que un relé transporta todo. Se iso é certo depende de que mecanismo fixo o traballo: un nome DNS, un camiño UDP coordinado ou un túnel de saída cara a un relé. Os tres poden producir un cliente conectado, e fallan en condicións distintas. Decida que camiño compra antes de tocar usuarios ou concentradores.

Tres mecanismos, tres promesas distintas

O DNS dinámico é nomenclatura. Mantén un nome de host apuntando a un enderezo cambiante para que a xente deixe de perseguir o número, e non fai nada máis. O atravesamento NAT nativo é coordinación: dous extremos SoftEther intercambian información e intentan abrir un camiño UDP utilizable a través dos dispositivos de tradución entre eles. VPN Azure é un relé: o servidor marca cara ao servizo, e os clientes chegan mediante un nome de host na infraestrutura do relé.

Os tres son complementarios, non versións dunha soa función. Unha implantación pode usar nomenclatura mentres a súa conexión depende en realidade do atravesamento ou do relé.

Decida a partir do cliente e da rede

A elección comeza polo cliente, porque o atravesamento só existe no mecanismo de conexión nativo de SoftEther. OpenVPN, L2TP/IPsec e os oíntes SSTP do mesmo servidor non o herdan, aínda que comparten un host. Mire o que executará o usuario e logo o que permite a rede. Unha rede corporativa que só permite TCP 443 empúxao cara a un relé nese porto, mentres que unha rede que deixa pasar os portos UDP que necesita o atravesamento pode tentar un camiño directo; confirme ambas contra a política real de saída.

Un oínte accesible manualmente segue sendo un deseño lexítimo cando un administrador pode publicar un, pero é un proxecto aparte co seu propio direccionamento e traballo de cortalumes.

Confirme que transporte escolleu a sesión

O estado da conexión é a única fonte honesta do camiño en uso. Léao no servidor e resolva o nome de host que recibiu o cliente.

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

SessionList mostra que sesións están conectadas, e SessionGet sobre unha delas informa do tipo de conexión, incluído se a sesión chegou polo relé. Un rexistro que resolve na infraestrutura do relé dille que a sesión pasa por un terceiro, o que pode confirmar bloqueando esa ruta nunha proba. Cun cliente nativo, a aceleración UDP pode afastar o camiño de datos do camiño de control, así que unha observación non describe toda a sesión. Un nome de DNS dinámico obsoleto tras un cambio de enderezo, e un relé que responde mentres falta a ruta de backend, son dous modos de fallo que convén probar por separado. Anote o que mediu, non o que o deseño pretendía.

Planifique de que depende o camiño elixido

Cada camiño leva unha dependencia. Un atravesamento directo pode cambiar tras unha transición de rede ou un dispositivo de tradución novo, mentres que unha sesión de relé falla cando falla o servizo ou o seu porto accesible. Reconéctese desde outra rede e confirme a identidade do servidor que o cliente verificou, mantendo o camiño que antes funcionaba na mesma proba. Despois probe o recurso privado detrás da VPN, porque a autorización, a pertenza ao concentrador, a asignación de enderezos e as rutas de retorno seguen sendo a súa responsabilidade en calquera caso.

Anote o nome de host, o protocolo, os axustes da función e o transporte observado. Ese rexistro en catro partes é o que permite á seguinte persoa reproducir unha conexión que funciona.