SoftEther bak við NAT: bein gegnumferð eða VPN Azure endasending?

SoftEther netþjónninn þinn er bak við beini þjónustuveitunnar sem þú getur ekki breytt, og biðlarar tengjast samt, svo þú gerir ráð fyrir að endasending beri allt. Hvort það er rétt fer eftir því hvaða fyrirkomulag innti verkið af hendi: DNS-nafn, samstillt UDP-slóð eða útstreymisgöng til endasendingar. Öll þrjú geta myndað tengdan biðlara, og þau bregðast við ólíkum skilyrðum. Ákveddu hvaða slóð þú kaupir áður en þú snertir notendur eða hubba.

Þrjú fyrirkomulög, þrjú ólík loforð

Kvik DNS er nafngjöf. Það heldur hýsilnafni beint að breytilegu vistfangi svo fólk hætti að elta númerið, og gerir ekkert annað. Innbyggð NAT-gegnumferð er samstilling: tveir SoftEther endapunktar skiptast á upplýsingum og reyna að opna nothæfa UDP-slóð gegnum þýðingartækin á milli þeirra. VPN Azure er endasending: netþjónninn hringir út til þjónustunnar, og biðlarar koma gegnum hýsilnafn á innviðum endasendingarinnar.

Þrjú þessara styðja hvert annað frekar en að vera afbrigði af einum eiginleika. Uppsetning getur notað nafngjöf á meðan tenging hennar byggist í raun á gegnumferð eða endasendingunni.

Ákveddu út frá biðlaranum og netinu

Valið hefst hjá biðlaranum, því gegnumferð er aðeins til í innbyggðu SoftEther tengingunni. OpenVPN, L2TP/IPsec og SSTP hlustarar á sama netþjóni erfa hana ekki, þótt þeir deili hýsli. Skoðaðu hvað notandinn mun keyra, og síðan hvað netið leyfir. Fyrirtækjanet sem leyfir aðeins TCP 443 ýtir þér að endasendingu á þeim porti, en net sem hleypir í gegn UDP-portunum sem gegnumferð þarf getur reynt beina slóð; staðfestu bæði gegn raunverulegri útstreymisstefnu.

Handvirkt aðgengilegur hlustari er enn lögmæt hönnun þegar stjórnandi getur birt einn, en það er sérstakt verkefni með eigin vistfangi og eldveggsvinnu.

Staðfestu hvaða flutning lotan valdi

Tengistada er eina heiðarlega uppspretta slóðarinnar sem notuð er. Lestu hana á netþjóninum, og leystu hýsilnafnið sem biðlarinn fékk.

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

SessionList sýnir hvaða lotur eru tengdar, og SessionGet á einni þeirra greinir frá tengitegund, þar á meðal hvort lotan kom gegnum endasendinguna. Færsla sem leysist yfir í innviði endasendingarinnar segir þér að lotan fari í gegnum þriðja aðila, sem þú getur staðfest með því að loka þeirri slóð í prófun. Með innbyggðum biðlara getur UDP-hraðun fært gagnaslóðina frá stýrislóðinni, svo ein athugun lýsir ekki allri lotunni. Úrelt kvik DNS-nafn eftir vistfangsbreytingu, og endasending sem svarar meðan bakslóðin vantar, eru tveir bilunarhamir sem vert er að prófa aðskilda. Skráðu það sem þú mældir, ekki það sem hönnunin ætlaði sér.

Skipuleggðu hvað valda slóðin byggist á

Sérhver slóð ber með sér háð. Bein gegnumferð getur breyst eftir netbreytingu eða nýju þýðingartæki, en endasendingarlota bregst þegar þjónustan eða aðgengilegt port hennar bregst. Tengingdu á ný úr öðru neti og staðfestu auðkenni netþjónsins sem biðlarinn staðfesti, og haltu fyrri vinnandi slóð í sama prófi. Prófaðu síðan einkaaðlindina bak við VPN, því heimild, hub-aðild, vistfangsúthlutun og afturvegir eru þín ábyrgð í öllum tilvikum.

Skráðu hýsilnafnið, samskiptaregluna, stillingar eiginleikans og athugaða flutninginn. Þessi fjórskipta skráning er það sem gerir næstu manneskju kleift að endurskapa vinnandi tengingu.