SoftEther sa Likod ng NAT: Direktang Pagtawid o Relay ng VPN Azure?

Nasa likod ng router ng provider na hindi mo mababago ang iyong SoftEther server, at kumokonekta pa rin ang mga kliyente, kaya ipinapalagay mong may relay na nagdadala ng lahat. Kung totoo iyon ay depende sa kung aling mekanismo ang gumawa ng trabaho: isang pangalang DNS, isang koordinadong landas na UDP o isang palabas na tunnel patungo sa relay. Ang tatlo ay makakagawa ng konektadong kliyente, at nabigo sila sa iba't ibang kondisyon. Magpasya kung aling landas ang binibili mo bago hawakan ang mga user o hub.

Tatlong mekanismo, tatlong magkaibang pangako

Ang dynamic na DNS ay pagpapangalan. Pinapanatili nitong nakaturo ang pangalan ng host sa nagbabagong address upang tumigil ang mga tao sa paghabol sa numero, at wala nang iba pang ginagawa. Ang katutubong pagtawid sa NAT ay koordinasyon: nagpapalitan ng impormasyon ang dalawang endpoint ng SoftEther at sinusubukang magbukas ng magagamit na landas na UDP sa pamamagitan ng mga kagamitang pansalin sa pagitan nila. Ang VPN Azure ay isang relay: dumadaan ang server palabas patungo sa serbisyo, at dumarating ang mga kliyente sa pamamagitan ng pangalan ng host sa imprastruktura ng relay.

Ang tatlo ay komplementaryo, hindi mga bersyon ng isang feature. Maaaring gumamit ng pagpapangalan ang isang deployment habang ang koneksyon nito ay aktwal na nakadepende sa pagtawid o sa relay.

Magpasya mula sa kliyente at sa network

Nagsisimula ang pagpili sa kliyente, dahil ang pagtawid ay umiiral lamang sa katutubong mekanismo ng koneksyon ng SoftEther. Ang OpenVPN, L2TP/IPsec at mga tagapakinig ng SSTP sa parehong server ay hindi nagmamana nito, kahit na nagbabahagi sila ng host. Tingnan kung ano ang patatakbuhin ng user, pagkatapos kung ano ang pinapayagan ng network. Ang isang corporate network na pinapayagan lamang ang TCP 443 ay tumutulak sa iyo patungo sa relay sa port na iyon, habang ang isang network na nagpapadaan sa mga port na UDP na kailangan ng pagtawid ay maaaring sumubok ng direktang landas; kumpirmahin ang pareho laban sa aktwal na patakaran sa paglabas.

Ang tagapakinig na naaabot nang manu-mano ay lehitimong disenyo pa rin kapag may administrator na makakapag-publish ng isa, ngunit ito ay hiwalay na proyekto na may sariling addressing at gawain sa firewall.

Kumpirmahin kung aling transport ang pinili ng session

Ang status ng koneksyon ang tanging tapat na pinagmulan ng landas na ginagamit. Basahin ito sa server, at lutasin ang pangalan ng host na natanggap ng kliyente.

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

Ipinapakita ng SessionList kung aling mga session ang konektado, at ang SessionGet sa isa sa kanila ay nag-uulat ng uri ng koneksyon, kabilang kung dumating ang session sa pamamagitan ng relay. Ang rekord na lumulutas sa imprastruktura ng relay ay nagsasabi sa iyo na dumadaan ang session sa ikatlong partido, na maaari mong kumpirmahin sa pamamagitan ng pagharang sa rutang iyon sa isang pagsubok. Sa katutubong kliyente, maaaring ilayo ng UDP acceleration ang landas ng data mula sa landas ng kontrol, kaya hindi inilalarawan ng isang obserbasyon ang buong session. Ang lumang pangalang dynamic na DNS pagkatapos ng pagbabago ng address, at isang relay na tumutugon habang nawawala ang landas patungo sa backend, ay dalawang mode ng pagbabigo na dapat subukan nang hiwalay. Itala ang iyong sinukat, hindi ang sinadya ng disenyo.

Magplano para sa kung ano ang nakasalalay sa piniling landas

Ang bawat landas ay may dalang dependency. Maaaring magbago ang direktang pagtawid pagkatapos ng paglipat ng network o bagong kagamitang pansalin, habang ang session ng relay ay nabigo kapag nabigo ang serbisyo o ang naaabot na port nito. Kumonekta muli mula sa ibang network at kumpirmahin ang pagkakakilanlan ng server na na-verify ng kliyente, habang pinapanatili ang dating gumaganang landas sa parehong pagsubok. Pagkatapos ay subukan ang pribadong resource sa likod ng VPN, dahil ang awtorisasyon, pagiging miyembro ng hub, paglalaan ng address at mga ruta ng pagbabalik ay mananatiling responsibilidad mo sa alinmang paraan.

Itala ang pangalan ng host, protocol, mga setting ng feature at ang naobserbahang transport. Ang rekord na may apat na bahagi ang nagbibigay-daan sa susunod na tao na muling gawin ang gumaganang koneksyon.