پورٹ فارورڈنگ کے بغیر NAT کے پیچھے ورک اسٹیشن تک رسائی
ان باؤنڈ پورٹ نہ ہونے والا ورک اسٹیشن بھی ہب، ریلے یا ایپ بروکر کے ذریعے قابل رسائی رہتا ہے۔ ایک منتخب کرنے سے پہلے موازنہ کریں کہ ہر ڈیزائن کیا ضمانت دیتا ہے۔
کیریئر NAT اور بند دفتری راؤٹر کے پیچھے دو اینڈ پوائنٹس فارورڈ کرنے کے لیے کوئی ان باؤنڈ پورٹ نہیں چھوڑتے، اور ردِعمل پھر بھی ایک مانگنا ہوتا ہے۔ بہتر سوال یہ ہے کہ کون سا فریق باہر ڈائل کر سکتا ہے اور کس قابلِ رسائی سروس کو ٹریفک لے جانے کی اجازت ہے۔ چار ڈیزائن اس سوال کا مختلف انداز میں جواب دیتے ہیں، اور راستہ بند ہونے پر مختلف طریقوں سے ناکام ہوتے ہیں۔ ان میں انتخاب پروٹوکول ناموں کا نہیں، ضمانتوں کا موازنہ ہے۔
چار ڈیزائن، چار مختلف وعدے
نیچے دیا گیا جدول مختصر ورژن ہے۔ درمیانے کالم کو اس وعدے کے طور پر پڑھیں جس کی آپ جانچ کر سکتے ہیں، اور دائیں کالم کو اس وعدے کے طور پر جو کسی نے نہیں دیا۔
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
کون سی سطر لاگو ہوتی ہے یہ ترجیح پر نہیں، کام پر منحصر ہے۔ ایک ریموٹ ڈیسک ٹاپ سیشن، ایک انتظامی شیل اور پورے نجی سب نیٹ تک رسائی — یہ تین ضروریات ہیں جنہیں ایک ہی داخلہ نقطہ درکار نہیں، اگرچہ وہ اتفاقاً ایک ہی مشین سے متعلق ہوں۔
ہب بدلتا ہے کہ کون باہر ڈائل کرتا ہے، یہ نہیں کہ کیا اجازت ہے
روٹ شدہ ہب ڈیزائن میں دور کا لیپ ٹاپ اور ورک اسٹیشن، یا اس کے سامنے کا سائٹ گیٹ وے، ہر ایک ایسی سروس کی طرف باہر جانے والی سرنگ کھولتا ہے جہاں دونوں پہنچ سکتے ہیں۔ ورک اسٹیشن کے راؤٹر پر کوئی چیز بغیر مانگے کنکشن قبول نہیں کرتی، اور اسی وجہ سے یہ ڈیزائن NAT میں قائم رہتا ہے اور سائٹ کے پاس مستقل پتہ نہ ہونے پر بھی کام کرتا ہے۔ پھر ہب اپنی پالیسی کے مطابق دو اندرونی پتوں کے درمیان ٹریفک روٹ کرتا ہے۔
قیمت یہ ہے کہ ہب کا ہونا ضروری ہے، دونوں طرف سے قابلِ رسائی ہونا چاہیے اور کوئی اسے چلائے۔ آؤٹ باؤنڈ فلٹرنگ کو ٹرانسپورٹ کی اجازت دینی چاہیے، اور جو نیٹ ورک اسے بلاک کرتا ہے وہ پورٹ فارورڈنگ کی ضرورت نہ ہونے پر بھی ڈیزائن کو ناکام کر دے گا۔
باریک بات یہ ہے کہ رسائی اور اجازت الگ الگ جگہوں پر لیے جانے والے الگ فیصلے ہیں۔ کسی پریفکس تک راستہ یہ نہیں بتاتا کہ ورک اسٹیشن پر کون سی سروس شناخت استعمال کر سکتی ہے، اور سرنگ کی اجازت دینے والا فائر وال اصول یہ نہیں بتاتا کہ اکاؤنٹ لاگ ان کر سکتا ہے یا نہیں۔ دونوں کو کنفیگر کریں، دونوں کو جانچیں، اور اجازت کا فیصلہ راؤٹنگ ٹیبل کے بجائے اس نظام کے پاس رکھیں جو وسیلے کا مالک ہے۔
ٹراورسل صرف اسی وقت کام کرتا ہے جب دونوں اسٹیک اسے نافذ کریں
برابر کے سروں کے درمیان ٹراورسل کسی مخصوص نظام کی صلاحیت ہے، VPN بہتر بنانے والی سیٹنگ نہیں۔ Interactive Connectivity Establishment کئی امیدوار پتے جمع کرتا ہے اور جوڑے جانچتا ہے جب تک ایک کام نہ کرے: مقامی انٹرفیس پر ہوسٹ امیدوار، NAT جو ظاہر کرتا ہے اس سے بنائے گئے سرور ریفلیکسیو امیدوار، اور ریلے پر مختص کیے گئے ریلے امیدوار۔ صرف نجی پتہ راستہ نہیں، کیونکہ دوسرا فریق وہاں روٹ نہیں کر سکتا۔
ریلے والے معاملے کو مسترد کرنے سے پہلے سمجھنا مناسب ہے۔ RFC 8656 TURN کو ایسے پروٹوکول کے طور پر بیان کرتا ہے جس میں کلائنٹ سرور سے ریلے شدہ ٹرانسپورٹ پتہ مانگتا ہے اور سرور اس کلائنٹ اور اس کے ساتھیوں کے درمیان ٹریفک بھیجتا ہے۔ لہٰذا ڈیٹا ریلے لے جاتا ہے، جو صرف سروں کو ملنے میں مدد کرنے والی ڈائریکٹری سے بنیادی طور پر مختلف ہے۔ ریلے پتہ دوسرے فریق کے ساتھ تبدیل کرنا ایک ہم آہنگی کا مرحلہ ہے جو ایپلیکیشن کو کرنا ہوتا ہے۔
جس کا آپ وعدہ نہیں کر سکتے وہ سیدھا راستہ ہے۔ متوازی NAT اور کچھ انٹرپرائز فائر وال سوراخ کرنے کو ناکام کرتے ہیں، اور جب ایسا ہوتا ہے تو نظام یا ریلے پر واپس آتا ہے یا ناکام ہوتا ہے۔ آپ یہ بھی نتیجہ نہیں نکال سکتے کہ دو ترجمہ شدہ سرے کبھی بات نہیں کر سکیں گے؛ ریلے بیک اپ والا معاون اسٹیک اسی لیے موجود ہے کہ وہ اکثر کر سکتے ہیں۔ فیصلہ کریں کہ دستیابی زیادہ اہم ہے یا سیدھاپن، پھر مناسب صورت فرض کرنے کے بجائے جانچیں کہ تعیناتی نے اصل میں کون سا راستہ چنا۔
بروکر نیٹ ورک سے تنگ تر ہے
جب ضرورت ایک ایپلیکیشن ہو، ایپ بروکر یا ورک اسٹیشن کی شروع کردہ معکوس کنکشن سب سے چھوٹا جواب ہو سکتا ہے۔ ورک اسٹیشن باہر بروکر کی طرف ڈائل کرتا ہے، بروکر دور کے صارف کی تصدیق کرتا ہے، اور صرف وہی ایپلیکیشن سیشن لے جایا جاتا ہے۔ ورک اسٹیشن کے سب نیٹ تک کوئی راستہ نہیں بنتا، اس لیے دور کے سیشن کی خلاف ورزی ہر اس آلے تک راستہ وراثت میں نہیں پاتی جو اس کے پاس ہے۔
اس تنگی کی قیمت ہے: ہر اضافی ایپلیکیشن کو اپنی انٹیگریشن درکار ہے، اور ایپلیکیشن مقامی نیٹ ورک کے بارے میں جو فرض کرتی ہے، مثلاً وہ فائل شیئرنگ جو قریبی سرور پر کھولتی ہے، وہ قابلِ رسائی نہ ہو سکے۔ بروکر پالیسی اور لاگنگ کو ایک جگہ مرکوز کرتے ہیں، جو اس وقت تک مفید ہے جب تک وہی جگہ رکاوٹ نہ بن جائے۔
اعتماد کی حدود کا موازنہ کریں، پھر راستہ جانچیں
سرنگیں ختم کرنے والا ہب جو ٹریفک روٹ کرتا ہے اسے پڑھ سکتا ہے۔ جب ایپلیکیشن سرے سے سرے تک انکرپٹ کرتی ہے تو ریلے آزادانہ طور پر محفوظ تبادلہ لے جا سکتا ہے، اور بروکر عام طور پر وہی سیشن ختم کرتا ہے جو وہ پیش کرتا ہے۔ دونوں انکرپٹڈ ہیں اس لیے دو ڈیزائن برابر ہیں، یہ فیصلہ کرنے سے پہلے طے کریں کہ تحفظ اصل میں کہاں ختم ہوتا ہے۔
پھر جانچیں کہ ورک اسٹیشن باہر کی طرف اصل میں کہاں پہنچتا ہے، کیونکہ اوپر کا ہر ڈیزائن اسی پر منحصر ہے۔ اسے ورک اسٹیشن پر چلائیں، اور وہ ہوسٹ نام بدلیں جو آپ استعمال کرنے کا ارادہ رکھتے ہیں۔
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comڈیزائن کو صرف اس وقت قبول کریں جب اجازت یافتہ شناخت کے تحت مطلوبہ دور کا عمل کامیاب ہو، غیر منظور شدہ شناخت مسترد ہو، اور سیدھے یا ریلے راستے کے دستیاب نہ ہونے پر رویہ معلوم اور دستاویزی ہو۔ دوبارہ کنیکٹ ہونا اور ورک اسٹیشن کا معمول کا آغاز سیاق شامل کریں، کیونکہ دفتر میں LAN کے ذریعے شروع ہونے والا سیشن دور رسائی کا انحصار رکھنے والی کوئی چیز نہیں جانچتا۔