SoftEther VPN Azure: daang relay, hindi bukas na port

Nasa likod ng router ang iyong server na hindi mo maaaring i-configure, kaya hindi magagamit ang halatang planong i-forward ang isang port. VPN Azure ay umiiral para sa eksaktong situasyong iyon, at nilulutas ito sa pamamagitan ng pagbabalik ng direksyon ng unang koneksyon: kumokonekta ang server pababa sa isang relay, at nararating ng mga kliyente ang relay sa halip na ang server. Ang pag-unawa sa pagbabalik na iyon ay nagpapaliwanag sa inaayos ng serbisyo at sa bawat limitasyong makatagpo mo mamaya.

Ano ang nagbabago sa daan

Sa karaniwang listener, binubuksan ng kliyente ang koneksyong TCP papunta sa pampublikong address na ipinapasa ng iyong router sa server. Sa relay, pinapanatili ng server ang palabas na koneksyon papunta sa imprastruktura ng relay, at tinatanggap ng relay ang mga koneksyon ng kliyente at ipinapasa ang kanilang karga sa server na naghihintay. Walang papasok na port na binubuksan, walang static na address na kailangan, at nananatiling hindi nagalaw ang router. Sa pananaw ng firewall, karaniwang palabas na kliyente ang server, at iyon ang dahilan kaya pinapayagan ito ng mahigpit na network.

Nagtatalaga ang relay ng pangalan sa sarili nitong domain para sa server na iyon, at ang mga kliyente ay naka-configure na kumonekta doon.

Ang pangalang iyon ay pag-aari ng serbisyo ng relay, na hindi isang Microsoft Azure VPN Gateway kahit pareho silang tinatawag na Azure kung ano. Ang pagtrato sa kanila bilang mapagpapalit ay gumagawa ng configuration na hindi maaaring gumana.

Aling protocol ang nakakalampas sa relay

Dinadala ng relay ang protocol na SoftEther, at idinodokumento ng proyekto ang SSTP bilang opsyon ng kliyente, na kapaki-pakinabang dahil may kasamang kliyenteng SSTP ang Windows. Hindi ito nagiging pangkalahatang tagapagdala para sa bawat listener sa host: ang listener ng OpenVPN, tagatugon ng IPsec at serbisyo ng L2TP ay nangangailangan ng kani-kanilang naaabot na endpoint, at wala sa kanila ang dinadala ng relay dahil lang nakakonekta ang server ng SoftEther.

Kaya ang mga profile ng kliyente ay tumutukoy sa pangalan ng relay sa halip na address ng server, at ang umiiral na profile na ginawa para sa direktang koneksyon ay hindi gagana nang walang pagbabago. Tingnan ang listahan ng mga sinusuportahang kliyente para sa bersyon na pinapatakbo mo bago magdisenyo sa paligid ng protocol na hindi dinadala ng relay.

Ano ang hindi ginagawa ng relay para sa iyo

Ang relay ay isang transportasyon. Hindi ito gumagawa ng mga user, virtual hub, patakaran sa pag-access o ruta, at wala itong alam tungkol sa mga pribadong network sa likod ng iyong server. Kung kailangang maabot ng mga malayong kliyente ang isang subnet ng LAN, kailangan pa rin ng server ang configuration ng tulay o routing, ang daan pabalik at ang patakaran ng firewall na nagpapagana nito. Ang magkakapatong na plano ng address sa dalawang dulo ay hindi rin nakikita ng relay at nananatiling problema mong lutasin.

Ang mga sinusuportahang setting ng seguridad ay pipiliin mo rin. Kasama sa dokumentasyon ng proyekto ang mga halimbawa ng mas lumang platform, at ang pagkopya ng lumang cipher o setting ng sertipiko mula sa lumang screenshot ay isang magandang paraan upang makabuo ng tunnel na walang makakapag-audit. Gamitin ang kasalukuyang gabay para sa bersyon na pinapatakbo mo.

Ang pagpapatunay ng sertipiko at pagpapatunay ng user ay nananatiling responsibilidad ng server, at hindi kailanman pinapalitan ng relay ang alinman sa dalawa.

Patakbuhin ito bilang dependency

Kasama na ngayon sa availability ang ikatlong partido. Kapag hindi maabot ang relay, hindi makakonekta ang mga kliyente gaano man kalusog ang iyong server, at ang pagkasira ay mukhang problema ng kliyente mula sa labas. Subaybayan ang daan ng relay nang hiwalay sa kalusugan ng server, at panatilihin ang dokumentadong fallback tulad ng direktang listener sa ibang address para sa araw na mahalaga ito.

Ang latency ay sumusunod sa heograpiya ng relay sa halip na sa kalapitan ng iyong mga user, na sulit sukatin bago mangako ng interactive na performance dito.

I-verify ang pagkakakilanlan ng server at pagkatapos ay isang tunay na daan ng aplikasyon, hindi lamang matagumpay na banner ng koneksyon, at suriin kung naaabot ang mapagkukunang kailangan mo sa pamilya ng address na dinadala ng relay. Itala ang pangalan ng relay, protocol na ginamit at fallback, dahil ang tatlong katotohanang iyon ay sumasagot sa karamihan ng hinaharap na tanong tungkol sa link na ito.