SoftEther VPN Azure: ریلے کا راستہ، کھلا پورٹ نہیں

آپ کا سرور ایسے راؤٹر کے پیچھے ہے جسے آپ ترتیب نہیں دے سکتے، اس لیے پورٹ فارورڈ کرنے کا واضح منصوبہ دستیاب نہیں۔ VPN Azure بالکل اسی صورت حال کے لیے ہے، اور پہلے کنکشن کی سمت الٹ کر اسے حل کرتا ہے: سرور باہر ایک ریلے سے جڑتا ہے، اور کلائنٹ سرور کے بجائے ریلے تک پہنچتے ہیں۔ اس الٹاؤ کو سمجھنا بتاتا ہے کہ سروس کیا درست کرتی ہے اور آگے آپ کو کون سی حدیں ملیں گی۔

راستے میں کیا بدلتا ہے

روایتی سننے والے کے ساتھ کلائنٹ ایک عوامی پتے پر TCP کنکشن کھولتا ہے جسے آپ کا راؤٹر سرور تک بھیجتا ہے۔ ریلے کے ساتھ سرور ریلے کے بنیادی ڈھانچے کی طرف باہر جانے والا کنکشن برقرار رکھتا ہے، اور ریلے کلائنٹ کنکشن قبول کر کے ان کا بوجھ منتظر سرور تک بھیجتا ہے۔ کوئی اندر آنے والا پورٹ نہیں کھلتا، مستقل پتہ درکار نہیں، اور راؤٹر اچھوتا رہتا ہے۔ فائر وال کی نظر میں سرور ایک عام باہر جانے والا کلائنٹ ہے، اسی لیے پابندی والے نیٹ ورک اسے اجازت دیتے ہیں۔

ریلے اس سرور کو اپنے ڈومین پر ایک نام دیتا ہے، اور کلائنٹ وہاں جڑنے کے لیے ترتیب دیے جاتے ہیں۔

وہ نام ریلے سروس کا ہے، جو Microsoft Azure VPN Gateway نہیں ہے، اگرچہ دونوں کو Azure کچھ کہا جاتا ہے۔ انہیں قابل تبادلہ سمجھنے سے ایسی ترتیب بنتی ہے جو کام نہیں کر سکتی۔

کون سے پروٹوکول ریلے سے گزرتے ہیں

ریلے SoftEther پروٹوکول لے جاتا ہے، اور منصوبہ SSTP کو کلائنٹ آپشن کے طور پر درج کرتا ہے، جو مفید ہے کیونکہ Windows کے ساتھ SSTP کلائنٹ آتا ہے۔ تاہم یہ میزبان پر ہر سننے والے کے لیے عمومی حامل نہیں بنتا: OpenVPN سننے والے، IPsec جواب دینے والے اور L2TP سروس کو اپنا اپنا قابل رسائی آخری نقطہ چاہیے، اور صرف SoftEther سرور جڑے ہونے کی وجہ سے ان میں سے کوئی ریلے سے نہیں گزرتا۔

اسی لیے کلائنٹ پروفائل سرور پتے کے بجائے ریلے نام کی طرف اشارہ کرتے ہیں، اور براہ راست کنکشن کے لیے بنایا گیا موجودہ پروفائل بغیر تبدیلی کام نہیں کرے گا۔ ریلے جس پروٹوکول کو نہیں لے جاتا اس کے گرد ڈیزائن کرنے سے پہلے آپ جو ورژن چلاتے ہیں اس کے لیے معاون کلائنٹ فہرست دیکھیں۔

ریلے آپ کے لیے کیا نہیں کرتا

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

معاون سیکیورٹی ترتیبات بھی آپ کے چننے کی ہیں۔ منصوبے کی دستاویزات میں پرانے پلیٹ فارم کی مثالیں ہیں، اور پرانے اسکرین شاٹ سے پرانی سائفر یا سرٹیفکیٹ ترتیبات کاپی کرنا ایسی سرنگ بنانے کا اچھا طریقہ ہے جس کا کوئی آڈٹ نہیں کر سکتا۔ آپ جو ورژن چلاتے ہیں اس کے لیے موجودہ رہنمائی استعمال کریں۔

سرٹیفکیٹ کی تصدیق اور صارف کی تصدیق سرور کی ہی ذمہ داری رہتی ہے، اور ریلے کبھی ان میں سے کسی کا متبادل نہیں بنتا۔

اسے انحصار کے طور پر چلائیں

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

تاخیر آپ کے صارفین کی قربت کے بجائے ریلے کے جغرافیے کی پیروی کرتی ہے، جسے اس پر انٹرایکٹو کارکردگی کا وعدہ کرنے سے پہلے ناپنا مناسب ہے۔

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