NAT کے پیچھے SoftEther: براہ راست عبور یا 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 نام، اور بیک اینڈ راستہ غائب ہونے پر بھی جواب دینے والا ریلے، دو ناکامی کے طریقے ہیں جنہیں الگ الگ جانچنا چاہیے۔ ڈیزائن نے جو ارادہ کیا وہ نہیں، آپ نے جو ناپا وہ لکھیں۔

منتخب راستہ کس پر منحصر ہے اس کا منصوبہ بنائیں

ہر راستہ ایک انحصار اٹھاتا ہے۔ نیٹ ورک کی تبدیلی یا نئے ترجمہ آلے کے بعد براہ راست عبور بدل سکتا ہے، جبکہ سروس یا اس کی قابل رسائی پورٹ ناکام ہونے پر ریلے سیشن ناکام ہوتا ہے۔ دوسرے نیٹ ورک سے دوبارہ جڑیں اور کلائنٹ کی تصدیق شدہ سرور شناخت کی تصدیق کریں، پہلے کام کرنے والا راستہ اسی امتحان میں رکھیں۔ پھر VPN کے پیچھے نجی وسیلہ جانچیں، کیونکہ اجازت، حب رکنیت، پتہ تقسیم اور واپسی کے راستے کسی بھی صورت میں آپ کی ذمہ داری رہتے ہیں۔

میزبان نام، پروٹوکول، خصوصیت کی ترتیبات اور مشاہدہ شدہ ترسیل لکھیں۔ وہی چار حصوں والا ریکارڈ اگلے شخص کو کام کرنے والا کنکشن دوبارہ بنانے دیتا ہے۔