SoftEther د NAT تر شا: مستقیم تېرېدل که VPN Azure ریلې؟

ستاسو SoftEther سرور د یو داسې عرضه کوونکي روټر تر شا دی چې تاسو یې نه شئ بدلولی، او کلاینټان بیا هم نښلېږي، نو تاسو فکر کوئ چې ریلې هر څه وړي۔ ایا دا سمه ده، دا پورې اړه لري چې کومه طریقه کار وکړ: DNS نوم، همغږی شوی UDP لاره یا ریلې ته وتونکی ټونل۔ درې واړه کولای شي نښلول شوی کلاینټ جوړ کړي، او دوی په بېلو شرایطو کې ناکامېږي۔ د کاروونکو یا هبونو له لاسوهنې مخکې پرېکړه وکړئ چې کومه لاره کوئ۔

درې طریقې، درې بېلې ژمنې

ډینامیک DNS نومونه ورکول دي۔ دا د کوربه نوم د بدلېدونکي پتې په لور ساتي ترڅو خلک د شمېرې تعقیبولو بند کړي، او بل څه نه کوي۔ اصلي NAT تېرېدل همغږي ده: دوه SoftEther پای ټکي معلومات تبادلوي او هڅه کوي د خپل منځ د ژباړې وسیلو له لارې د کارېدونکې UDP لاره پرانیزي۔ VPN Azure یوه ریلې ده: سرور بهر ته د خدمت سره نښلول کېږي، او کلاینټان د ریلې زیربنې کې د کوربه نوم له لارې راځي۔

درې واړه یو بل بشپړوي، نه د یوې ځانګړنې نسخې دي۔ ځای پرځای کول کولای شي نومونه ورکول وکاروي، په داسې حال کې چې د هغه نښلون په ریښتیا تېرېدل یا ریلې پورې تړلی وي۔

د کلاینټ او شبکې له مخې پرېکړه وکړئ

ټاکنه له کلاینټ پیلېږي، ځکه تېرېدل یوازې د SoftEther اصلي نښلون طریقه کې شته۔ په هماغه سرور کې OpenVPN، L2TP/IPsec او SSTP اورېدونکي دوی ته نه رسي، که څه هم یو کوربه شریکوي۔ وګورئ کاروونکی څه چلوي، بیا شبکه څه اجازه ورکوي۔ هغه کارپوریټ شبکه چې یوازې TCP 443 ته اجازه ورکوي تاسو د هماغه پورټ ریلې ته ټېله کوي، په داسې حال کې چې د تېرېدو لپاره اړین UDP پورټونه تېروونکې شبکه کولای شي مستقیمه لاره هڅه وکړي؛ دواړه د ریښتیني وتلو تګلارې سره تایید کړئ۔

په لاس رسېدونکی اورېدونکی هغه وخت هم سم دیزاین دی چې یو مدیر یې خپور کولای شي، مګر دا خپل پتې او د اور وژنې کار سره جلا پروژه ده۔

تایید کړئ چې غونډې کومه لېږدونه غوره کړې

د نښلون حالت د کارېدونکې لارې یوازینی رښتینی سرچینه ده۔ دا پر سرور ولولئ، او هغه کوربه نوم حل کړئ چې کلاینټ ترلاسه کړی۔

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

SessionList ښیي کومې غونډې نښلول شوې دي، او پر یوې یې SessionGet د نښلون ډول راپور ورکوي، په دې کې چې غونډه د ریلې له لارې راغلې که نه۔ هغه ریکارډ چې د ریلې زیربنې ته حلېږي تاسو ته وایي چې غونډه د درېیم اړخ له لارې تېرېږي، کوم چې تاسو په ازموینه کې هغه لاره بندولو سره تاییدولی شئ۔ د اصلي کلاینټ سره، UDP ګړندی کول کولای شي د معلوماتو لاره د کنټرول لارې نه لرې کړي، نو یوه کتنه ټوله غونډه نه تشریح کوي۔ د پتې بدلون وروسته زوړ ډینامیک DNS نوم، او هغه ریلې چې ځواب ورکوي په داسې حال کې چې د backend لاره ورکه ده، دوه د ناکامۍ حالتونه دي چې جلا ازموینې ته ارزښت لري۔ هغه څه ولیکئ چې تاسو اندازه کړل، نه هغه څه چې ډیزاین یې نیت درلود۔

د هغه څه پلان جوړ کړئ چې غوره شوې لاره پرې تکیه ده

هره لاره یوه تکیه لېږدوي۔ مستقیم تېرېدل کولای شي د شبکې تګلارې یا نوي ژباړې وسیلې وروسته بدل شي، په داسې حال کې چې د ریلې غونډه ناکامېږي کله چې خدمت یا د هغه رسېدونکی پورټ ناکام شي۔ له بلې شبکې بیا ونښلئ او هغه سرور هویت تایید کړئ چې کلاینټ تصدیق کړی، پخوانۍ کارکوونکې لاره په هماغه ازموینه کې وساتئ۔ بیا د VPN تر شا شخصي سرچینه وازموئ، ځکه اجازه، د هب غړیتوب، د پتې ځانګړنه او د بېرته راستنېدو لارې په هر حال ستاسو مسؤلیت پاتې کېږي۔

کوربه نوم، پروتوکول، د ځانګړنې ترتیبات او مشاهده شوې لېږدونه ولیکئ۔ هماغه څلور برخې ریکارډ بل کس ته اجازه ورکوي چې کارکوونکی نښلون بیا تولید کړي۔