SoftEther agter NAT: direkte deurgang of VPN Azure-relais?

Jou SoftEther-bediener sit agter 'n verskaffersroeteerder wat jy nie kan verander nie, en kliënte maak steeds verbinding, so jy aanvaar dat 'n relais alles dra. Of dit waar is, hang af van watter meganisme die werk gedoen het: 'n DNS-naam, 'n gekoördineerde UDP-pad of 'n uitgaande tonnel na 'n relais. Al drie kan 'n gekoppelde kliënt lewer, en hulle misluk onder verskillende omstandighede. Besluit watter pad jy koop voordat jy aan gebruikers of hubs raak.

Drie meganismes, drie verskillende beloftes

Dinamiese DNS is naamgewing. Dit hou 'n gasheernaam na 'n veranderende adres gerig sodat mense ophou om die nommer te jaag, en dit doen niks anders nie. Inheemse NAT-deurgang is koördinering: twee SoftEther-eindpunte ruil inligting uit en probeer 'n bruikbare UDP-pad deur die vertaaltoestelle tussen hulle oopmaak. VPN Azure is 'n relais: die bediener skakel uit na die diens, en kliënte kom deur 'n gasheernaam op die relais se infrastruktuur.

Die drie is aanvullend eerder as weergawes van een funksie. 'n Ontplooiing kan naamgewing gebruik terwyl sy verbinding eintlik van deurgang of van die relais afhang.

Besluit op grond van die kliënt en die netwerk

Die keuse begin by die kliënt, want deurgang bestaan net in die inheemse SoftEther-verbindingsmeganisme. OpenVPN, L2TP/IPsec en SSTP-luisteraars op dieselfde bediener erf dit nie, selfs al deel hulle 'n gasheer. Kyk na wat die gebruiker gaan hardloop, en dan na wat die netwerk toelaat. 'n Korporatiewe netwerk wat net TCP 443 toelaat, stoot jou na 'n relais op daardie poort, terwyl 'n netwerk wat die UDP-poorte deurlaat wat deurgang nodig het, 'n direkte pad kan probeer; bevestig albei teen die werklike uitgangsbeleid.

'n Luisteraar wat met die hand bereikbaar is, bly 'n geldige ontwerp wanneer 'n administrateur een kan publiseer, maar dit is 'n aparte projek met sy eie adressering en brandmuurwerk.

Bevestig watter vervoer die sessie gekies het

Verbindingstatus is die enigste eerlike bron vir die pad wat gebruik word. Lees dit op die bediener, en los die gasheernaam op wat die kliënt gekry het.

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

SessionList wys watter sessies gekoppel is, en SessionGet op een van hulle rapporteer die verbindingstipe, insluitend of die sessie deur die relais gekom het. 'n Rekord wat na relaisinfrastruktuur oplos, sê vir jou die sessie gaan deur 'n derde party, wat jy kan bevestig deur daardie roete in 'n toets te blokkeer. Met 'n inheemse kliënt kan UDP-versnelling die datapad weg van die beheerpad skuif, so een waarneming beskryf nie die hele sessie nie. 'n Verouderde dinamiese DNS-naam ná 'n adresverandering, en 'n relais wat antwoord terwyl die agterkantroete ontbreek, is twee mislukkingsmodusse wat afsonderlik getoets moet word. Teken op wat jy gemeet het eerder as wat die ontwerp bedoel het.

Beplan vir waarvan die gekose pad afhang

Elke pad dra 'n afhanklikheid. 'n Direkte deurgang kan verander ná 'n netwerkoorgang of 'n nuwe vertaaltoestel, terwyl 'n relaisessie misluk wanneer die diens of sy bereikbare poort misluk. Herverbind vanaf 'n ander netwerk en bevestig die bedieneridentiteit wat die kliënt geverifieer het, terwyl jy die voorheen werkende pad in dieselfde toets hou. Toets dan die private hulpbron agter die VPN, want magtiging, hub-lidmaatskap, adrestoewysing en terugroetes bly jou verantwoordelikheid in elk geval.

Skryf die gasheernaam, protokol, funksie-instellings en waargenome vervoer neer. Daardie vierdelige rekord is wat die volgende persoon in staat stel om 'n werkende verbinding te herhaal.