AWS Client VPN اسپلٹ ٹنل کے ساتھ: کون سے راستے شائع کریں

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

اسپلٹ ٹنل کا جھنڈا منزل کی فہرست نہیں ہے

AWS اسپلٹ ٹنل کو یوں بیان کرتا ہے کہ کنکشن قائم ہونے پر اینڈ پوائنٹ کے راستے کلائنٹ کی روٹ ٹیبل میں شامل کیے جاتے ہیں۔ نجی VPC کے لیے راستہ ٹنل کو اسی منزل تک محدود کرتا ہے؛ باقی سب کلائنٹ کے عام راستے پر چلتا ہے۔ ڈیفالٹ راستہ مختلف اثر والی مختلف ہدایت ہے، اسی لیے اسپلٹ ٹنل کی دستاویزات اس موڈ کے لیے ترتیب دیے گئے اینڈ پوائنٹ پر 0.0.0.0/0 شائع کرنے کے خلاف خبردار کرتی ہیں: یہ عام طور پر کنیکٹیویٹی کو بڑھانے کے بجائے توڑ دیتا ہے۔ اینڈ پوائنٹ کی روٹ ٹیبل پالیسی ہے، اور کلائنٹ کی روٹ ٹیبل وہ نتیجہ ہے جس کا آپ معائنہ کر سکتے ہیں۔

اینڈ پوائنٹ کی روٹ ٹیبل اور کلائنٹ کے نصب شدہ راستے ایک ساتھ پڑھیں۔ لیبل نیت بیان کرتا ہے؛ راستے بتاتے ہیں کہ کیا ہوتا ہے۔

پہلا فیصلہ: کیا عام انٹرنیٹ ٹریفک مقامی رہنا چاہیے؟

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

اگر انٹرنیٹ ٹریفک AWS کے ذریعے باہر جانا ہے، تو دستاویزی انٹرنیٹ رسائی کا ڈھانچہ بنائیں: اینڈ پوائنٹ راستہ، اجازت کے قواعد، متعلقہ سب نیٹ کا راستہ، سیکیورٹی پالیسی اور کام کرنے والا بالائی اخراج۔ صرف ڈیفالٹ راستہ ان میں سے کچھ بھی فراہم نہیں کرتا۔

دوسرا فیصلہ: کون سے نجی سابقے، اور کس کی اجازت سے؟

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

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

جب کسی منزل تک نام سے رسائی ضروری ہو، تو دھیان دیں کہ اگلا سوال راستے کا نہیں بلکہ نام کے حل کا ہے۔

تیسرا فیصلہ: کون سا ریزالور ٹنل کی پیروی کرتا ہے؟

کلائنٹ کو ایسا DNS سرور مل سکتا ہے جو صرف VPN کے ذریعے قابل رسائی ہو، اور وہ ریزالور صرف اسی وقت کام کرتا ہے جب اس کا پتہ خود کسی مجاز راستے کے اندر ہو۔ دونوں حصے جانچیں: ریزالور کا پتہ شائع شدہ راستے کی پیروی کرتا ہے، اور سرور ان ناموں کا جواب دیتا ہے جو ایپلیکیشن پوچھتی ہے۔ پتے سے کامیاب مگر ہوسٹ نام سے ناکام درخواست نام رکھنے کی طرف اشارہ کرتی ہے، روٹنگ کی طرف نہیں، اور اس حالت میں ٹنل کو ڈی بگ کرنا دوپہر ضائع کرتا ہے۔

عوامی نام کنکشن سے پہلے کی طرح حل ہونے چاہئیں، جو اس بات پر درست رہنے کی ایک اور وجہ ہے کہ آپ کیا شائع کرتے ہیں۔

راستوں کا مجموعہ بدلیں، پھر دونوں جہانیں جانچیں

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

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

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