SoftEther darrere de NAT: travessa directa o relé de VPN Azure?

El vostre servidor SoftEther és darrere d'un encaminador del proveïdor que no podeu canviar, i els clients encara es connecten, així que suposeu que tot ho porta un relé. Si això és cert depèn de quin mecanisme ha fet la feina: un nom DNS, un camí UDP coordinat o un túnel de sortida cap a un relé. Tots tres poden produir un client connectat, i fallen en condicions diferents. Decidiu quin camí compreu abans de tocar usuaris o concentradors.

Tres mecanismes, tres promeses diferents

El DNS dinàmic és nomenclatura. Manté un nom d'amfitrió apuntant a una adreça que canvia perquè la gent deixi de perseguir el número, i no fa res més. La travessa NAT nativa és coordinació: dos extrems SoftEther intercanvien informació i intenten obrir un camí UDP utilitzable a través dels dispositius de traducció que hi ha entre ells. VPN Azure és un relé: el servidor marca cap al servei, i els clients arriben a través d'un nom d'amfitrió a la infraestructura del relé.

Els tres són complementaris, no versions d'una sola funció. Un desplegament pot fer servir nomenclatura mentre la seva connexió depèn en realitat de la travessa o del relé.

Decidiu a partir del client i de la xarxa

L'elecció comença pel client, perquè la travessa només existeix en el mecanisme de connexió natiu de SoftEther. OpenVPN, L2TP/IPsec i els oients SSTP del mateix servidor no n'hereten res, tot i que comparteixen un amfitrió. Mireu què executarà l'usuari i després què permet la xarxa. Una xarxa corporativa que només permet TCP 443 us empeny cap a un relé en aquest port, mentre que una xarxa que deixa passar els ports UDP que necessita la travessa pot intentar un camí directe; confirmeu-ho tot dues vegades contra la política real de sortida.

Un oient accessible manualment continua sent un disseny legítim quan un administrador pot publicar-ne un, però és un projecte a part amb el seu propi adreçament i feina de tallafocs.

Confirmeu quin transport ha triat la sessió

L'estat de la connexió és l'única font honesta del camí en ús. Llegiu-lo al servidor i resoleu el nom d'amfitrió que va rebre el client.

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

SessionList mostra quines sessions estan connectades, i SessionGet sobre una d'elles informa del tipus de connexió, incloent si la sessió ha arribat pel relé. Un registre que resol a la infraestructura del relé us diu que la sessió passa per un tercer, cosa que podeu confirmar bloquejant aquella ruta en una prova. Amb un client natiu, l'acceleració UDP pot allunyar el camí de dades del camí de control, així que una observació no descriu tota la sessió. Un nom de DNS dinàmic obsolet després d'un canvi d'adreça i un relé que respon mentre falta la ruta de fons són dos modes de fallada que val la pena provar per separat. Anoteu què heu mesurat, no què pretenia el disseny.

Planifiqueu de què depèn el camí triat

Cada camí porta una dependència. Una travessa directa pot canviar després d'una transició de xarxa o d'un dispositiu de traducció nou, mentre que una sessió de relé falla quan falla el servei o el seu port accessible. Torneu a connectar-vos des d'una altra xarxa i confirmeu la identitat del servidor que el client ha verificat, mantenint el camí que abans funcionava en la mateixa prova. Després proveu el recurs privat darrere de la VPN, perquè l'autorització, la pertinença al concentrador, l'assignació d'adreces i les rutes de tornada continuen sent responsabilitat vostra en qualsevol cas.

Anoteu el nom d'amfitrió, el protocol, els paràmetres de la funció i el transport observat. Aquest registre en quatre parts és el que permet a la propera persona reproduir una connexió que funciona.