SoftEther nyuma ya NAT: kupita moja kwa moja au relay ya VPN Azure?

Seva yako ya SoftEther iko nyuma ya kipanga njia cha mtoa huduma usioweza kubadilisha, na wateja bado wanaunganisha, kwa hiyo unadhani relay inabeba kila kitu. Ikiwa hiyo ni kweli inategemea ni utaratibu upi uliofanya kazi: jina la DNS, njia ya UDP iliyoratibiwa au handaki inayotoka kwenda relay. Zote tatu zinaweza kutoa mteja aliyeunganishwa, na zinashindwa katika hali tofauti. Amua njia unayonunua kabla ya kugusa watumiaji au hub.

Mifumo mitatu, ahadi tatu tofauti

DNS inayobadilika ni uwekaji majina. Inaweka jina la mwenyeji likielekea anwani inayobadilika ili watu waache kufukuza namba, na haifanyi kitu kingine. Upitishaji halisi wa NAT ni uratibu: ncha mbili za SoftEther zinabadilishana taarifa na kujaribu kufungua njia ya UDP inayoweza kutumika kupitia vifaa vya tafsiri kati yao. VPN Azure ni relay: seva hupiga simu huduma kwenda nje, na wateja hufika kupitia jina la mwenyeji kwenye miundombinu ya relay.

Tatu hizo zinakamilishana badala ya kuwa matoleo ya kipengele kimoja. Usambazaji unaweza kutumia uwekaji majina wakati muunganisho wake kwa kweli unategemea upitishaji au relay.

Amua kutokana na mteja na mtandao

Uchaguzi huanza kwa mteja, kwa sababu upitishaji upo tu katika utaratibu halisi wa muunganisho wa SoftEther. OpenVPN, L2TP/IPsec na visikilizaji vya SSTP kwenye seva hiyo hiyo havirithi, ingawa vinashiriki mwenyeji mmoja. Angalia mtumiaji atakachoendesha, kisha mtandao unaruhusu nini. Mtandao wa shirika unaoruhusu TCP 443 pekee unakusukuma kuelekea relay kwenye bandari hiyo, wakati mtandao unaopitisha bandari za UDP zinazohitajika na upitishaji unaweza kujaribu njia ya moja kwa moja; thibitisha zote mbili dhidi ya sera halisi ya kutoka.

Kisikilizaji kinachoweza kufikiwa kwa mkono bado ni muundo halali wakati msimamizi anaweza kuchapisha kimoja, lakini ni mradi tofauti wenye anwani na kazi yake ya ukuta wa moto.

Thibitisha usafirishaji ambao kikao kilichagua

Hali ya muunganisho ni chanzo pekee cha uaminifu kwa njia inayotumika. Isome kwenye seva, na utatue jina la mwenyeji ambalo mteja alipokea.

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

SessionList inaonyesha vikao vipi vimeunganishwa, na SessionGet kwenye kimoja chao huripoti aina ya muunganisho, ikiwa ni pamoja na kama kikao kilifika kupitia relay. Rekodi inayotatuliwa kwenye miundombinu ya relay inakuambia kikao kinapita kwa mtu wa tatu, jambo ambalo unaweza kuthibitisha kwa kuzuia njia hiyo katika jaribio. Kwa mteja halisi, uharakishaji wa UDP unaweza kuhamisha njia ya data mbali na njia ya udhibiti, kwa hiyo uchunguzi mmoja hauelezi kikao kizima. Jina la DNS linalobadilika lililopitwa na wakati baada ya mabadiliko ya anwani, na relay inayojibu wakati njia ya backend haipo, ni mbinu mbili za kushindwa zinazostahili kujaribiwa kwa tofauti. Andika ulichopima, si kile ambacho muundo ulikusudia.

Panga kile ambacho njia iliyochaguliwa inategemea

Kila njia hubeba utegemezi. Upitishaji wa moja kwa moja unaweza kubadilika baada ya mpito wa mtandao au kifaa kipya cha tafsiri, wakati kikao cha relay kinashindwa wakati huduma au bandari yake inayoweza kufikiwa inashindwa. Unganisha tena kutoka mtandao mwingine na uthibitishe utambulisho wa seva ambao mteja alithibitisha, ukihifadhi njia iliyofanya kazi hapo awali katika jaribio hilo hilo. Kisha jaribu rasilimali ya kibinafsi nyuma ya VPN, kwa sababu idhini, uanachama wa hub, ugawaji wa anwani na njia za kurudi zinabaki kuwa jukumu lako kwa vyovyote.

Andika jina la mwenyeji, itifaki, mipangilio ya kipengele na usafirishaji uliozingatiwa. Rekodi hiyo ya sehemu nne ndiyo inayomwezesha mtu anayefuata kuzalisha tena muunganisho unaofanya kazi.