peered VPC تک پہنچنے کے لیے AWS Client VPN یا bastion

ایک Client VPN endpoint اُس VPC تک پہنچ سکتا ہے جو اُس کے منسلک VPC کے ساتھ peered ہے، اور اِسے جائز بنانے کے لیے آپ کو bastion کی ضرورت نہیں۔ قابلِ توجہ انتخاب یہ ہے کہ ٹریفک کہاں ہاتھ بدلتا ہے: endpoint راستہ جو association subnet میں اُترتا ہے اور peering کنکشن عبور کرتا ہے، یا peered VPC میں host جو سیشن ختم کرتا ہے۔ دونوں راستے کام کرتے ہیں اور مختلف جگہوں پر ناکام ہوتے ہیں، اِس لیے فیصلہ ملکیت اور آڈٹ کے بارے میں ہے، اِس کے بارے میں نہیں کہ AWS کیا اجازت دیتا ہے۔ یہاں ہے کہ میں اِن کے درمیان کیسے انتخاب کرتا ہوں، اور وہ چار اندراجات جو routed راستے کو کام کرنے دیتے ہیں۔

دو راستے، ایک endpoint، مختلف مالک

routed راستے پر کلائنٹ ٹریفک endpoint تک پہنچتا ہے، association subnet میں Client VPN نیٹ ورک انٹرفیس کے پتے میں ترجمہ ہوتا ہے، اور A سے B تک peering کنکشن کے ذریعے اُس subnet سے نکلتا ہے۔ VPC B کوئی VPN سیشن ختم نہیں کرتا؛ وہ VPC A سے عام ٹریفک دیکھتا ہے، اِسی لیے اُس کا واپسی راستہ کلائنٹ پول کی طرف نہیں، VPC A کی طرف اشارہ کرتا ہے۔

bastion راستے پر کلائنٹ پہلے host تک پہنچتا ہے۔ A میں bastion آخری چھلانگ کو اب بھی peering کنکشن سے گزرنے دیتا ہے، اِس لیے peering کا کام باقی رہتا ہے اور ایک سیشن بڑھ جاتا ہے۔ B میں bastion کو بھی کلائنٹ سے راستہ درکار ہوتا ہے، اور جب وہ راستہ وہی endpoint راستہ ہو، تو routed ڈیزائن میں ایک چھلانگ بڑھ جاتی ہے۔ bastion کام صرف اُس وقت کم کرتا ہے جب وہ پہلے سے موجود ہو، پہلے سے منظور شدہ ہو، اور اُس کے پیچھے والی چیز کو نیٹ ورک حد کے بجائے سیشن حد درکار ہو۔

چار اندراجات routed راستے کو کام کرنے دیتے ہیں

AWS اِس منظرنامے کو Client VPN how-it-works صفحے پر دستاویزی کرتا ہے، اور عملاً یہ دو یا تین ٹیموں کی ملکیت والے چار اندراجات تک آتا ہے۔ حدود مثال کے طور پر ہیں؛ peered حد منفرد ہونی چاہیے اور واپسی حد آپ کے منصوبے سے مماثل ہونی چاہیے۔

راستہ اور اجازت الگ کنٹرول ہیں۔ مماثل اجازت نامہ کے بغیر درست endpoint راستہ کلائنٹ کو کچھ نہیں دیتا؛ ایسی منزل کے لیے اجازت نامہ جسے endpoint روٹ نہیں کر سکتا، اُسے سیاہ سوراخ دیتا ہے۔ دونوں کو ایک ہی حد بتانی چاہیے۔

endpoint راستہ endpoint کے اپنے VPC میں موجود subnet کی طرف اشارہ کرتا ہے، کبھی peering کنکشن کی طرف نہیں۔ VPC روٹ جدولیں peering کنکشن کی طرف اشارہ کرتی ہیں، کبھی instance یا انٹرفیس کی طرف نہیں۔ دونوں کے درمیان قدر نقل کرنا بغیر شکایت محفوظ ہوتا ہے اور کچھ روٹ نہیں کرتا۔

چونکہ association subnet کلائنٹ کے ماخذ کا ترجمہ کرتا ہے، B کو کلائنٹ پول کی طرف نہیں، VPC A کی طرف واپس روٹ کرنا چاہیے۔ peering کنکشن پر کلائنٹ حد بھیجنا ہم آہنگ لگتا ہے، جائزہ پاس کرتا ہے اور خاموشی سے ناکام ہوتا ہے کیونکہ B کبھی کلائنٹ ماخذ والا پیکٹ نہیں دیکھتا۔

سیکیورٹی گروپس اور اجازت کا آخری میٹر

روٹنگ پیکٹ B میں لاتی ہے؛ فیصلہ B اب بھی کرتا ہے۔ اسی خطے میں فعال peering کنکشن کے لیے، B میں سیکیورٹی گروپ Client VPN association پر لاگو گروپ کا حوالہ دے سکتا ہے، جو قاعدے کو تنگ رکھتا ہے اور پتوں کی تبدیلیوں پر قائم رہتا ہے۔ جہاں گروپ حوالہ ممکن نہ ہو، وہاں 0.0.0.0/0 تک پھیلانے کے بجائے association subnet کی حد کو واضح طور پر اجازت دیں، کیونکہ یہ روٹنگ کی غلطی کو بے وضاحت ٹائم آؤٹ میں بدل دیتا ہے۔

پھر وہ چیک کریں جسے روٹنگ کبھی نہیں چھوتی: دونوں subnets پر نیٹ ورک ACL، ایپلیکیشن کی allow-list یا ٹوکن سامعین، اور DNS۔ peering نجی ہوسٹڈ زونز کی نقل نہیں کرتا، اِس لیے لیپ ٹاپ اُس پتے تک کام کرنے والا راستہ رکھ سکتا ہے جسے وہ حل نہیں کر سکتا، اور peering کنکشن سرٹیفکیٹ میں اعتماد نہیں بڑھاتا۔ endpoint کو اُس resolver کی طرف اشارہ کریں جو B کے لیے جواب دیتا ہے، پھر تصدیق کریں کہ نجی نام اور سرٹیفکیٹ مماثل ہیں۔

کب bastion دیانتدار جواب ہے

میں جان بوجھ کر bastion منتخب کرنے کے لیے تین محرک رکھتا ہوں۔ peered VPC اُس ٹیم کی ملکیت ہے جو آپ کی حد کے لیے واپسی راستہ نہیں بڑھائے گی یا گروپ حوالہ قبول نہیں کرے گی۔ رسائی ہر سیشن کے لیے منظور یا ریکارڈ ہونی چاہیے اور ایپلیکیشن اِسے خود نہیں اُٹھا سکتی۔ یا آخری چھلانگ B کے اندر ہی رہنی چاہیے کیونکہ سروس صرف وہیں حل ہوتی ہے اور اُس کی TLS شناخت اندرونی نام سے پن ہے۔

اِن میں سے کوئی بھی اِس حقیقت کے گرد گھومنا نہیں کہ peering منتقلی نہیں ہے۔ غیر منتقلیت محدود کرتی ہے کہ B کے وسائل کیا کر سکتے ہیں: وہ A کو تیسرے VPC تک منتقلی کے طور پر استعمال نہیں کر سکتے جس کے ساتھ A peered ہے۔ اِس کا مطلب کبھی یہ نہیں تھا کہ VPN صارف براہِ راست peered VPC تک نہیں پہنچ سکتا، اور اُس غلط قرأت سے بچنے کے لیے بنایا گیا bastion بلا وجہ پیچ کیے جانے والا host ہے۔

اُلٹی غلطی وقت کے ساتھ زیادہ مہنگی پڑتی ہے: ہر ٹیم کو پہلے سے موجود واحد bastion سے گزاریں، پھر معلوم ہو کہ اُس کا سیکیورٹی گروپ، روٹ جدول اور پیچ ونڈو ہی پیداواری انحصار ہیں۔ لکھیں کہ host کس محرک کی خدمت کرتا ہے، اور محرک جانے پر اُسے ریٹائر کریں۔

Transit Gateway اور متعدد association حساب بدلتے ہیں

اگر endpoint subnet کے بجائے براہِ راست Transit Gateway سے منسلک ہو، تو ماڈل بدل جاتا ہے: کلائنٹ اب association subnet میں انٹرفیس پتے میں ترجمہ نہیں ہوتے، اور gateway روٹ جدولوں کو کلائنٹ حد کے ساتھ وہ منسلکہ بھی لے جانا ہوتا ہے جو peered VPC تک لے جاتا ہے۔ یہ پیمانے پر زیادہ صاف ہے، مگر کام چار اندراجات سے gateway روٹ جدولوں میں منتقل ہو جاتا ہے۔

متعدد association جانچ کو ضرب دیتے ہیں۔ endpoint راستہ endpoint کا ہے، پھر بھی ہر association subnet کو حقیقی peering اگلی چھلانگ والا روٹ جدول درکار ہے۔ ایک association سے سیشن کامیاب ہو سکتا ہے جبکہ دوسرے کے پاس واپسی راستہ نہ ہو، اِس لیے ہر ایک کو آزمائیں۔

وہ تصدیقی ترتیب جو ٹوٹ پھوٹ جلد ڈھونڈتی ہے

اِنہیں ترتیب سے چلائیں؛ ہر مرحلہ پاس ہو سکتا ہے جبکہ اگلا ناکام ہو، اور کلائنٹ ٹائم آؤٹ تقریباً کبھی نہیں بتاتا کہ کون سا ٹوٹا۔

1. کلائنٹ سے ایپلیکیشن کا نام حل کریں اور جانچیں کہ پتہ peered حد کے اندر ہے۔
2. کنیکٹ کریں، پھر جس association نے سیشن ختم کیا اُس کے لیے endpoint کنکشن لاگ پڑھیں۔
3. اُس association subnet پر تصدیق کریں کہ روٹ جدول peered حد کو فعال peering کنکشن کی طرف اشارہ کرتا ہے۔
4. B کے وسائل والے subnet پر انٹرفیس حد کے لیے واپسی اندراج اور مماثل گروپ قواعد کی تصدیق کریں۔
5. ایک اجازت یافتہ کارروائی اور ایک ایسا وسیلہ آزمائیں جو ناقابلِ رسائی رہنا چاہیے؛ دوسرا ڈیبگنگ کی باقیات پکڑتا ہے۔
6. کسی بھی split-tunnel راستے کی تبدیلی کے بعد دوبارہ کنیکٹ کریں، کیونکہ چلتی ٹنل نیا راستہ سیٹ نہیں لے گی۔

دو علامات یاد رکھنے کے قابل ہیں۔ بغیر جواب B تک پہنچنے والا SYN تقریباً ہمیشہ گمشدہ واپسی راستہ ہوتا ہے۔ مکمل ہو کر پھر ری سیٹ ہونے والا کنکشن عام طور پر گروپ، ACL یا ایپلیکیشن ہوتا ہے۔ کوئی بھی endpoint لاگ میں بطور سبب نظر نہیں آتا، اِس لیے چار اندراجات ہر ایک کے ساتھ مالک رکھ کر محفوظ رکھیں۔

اگر تینوں محرکات میں سے کوئی لاگو نہ ہو، تو routed راستہ مکمل کریں اور وہ چار اندراجات درج کریں۔ اگر ایک لاگو ہو، تو bastion صرف اُسی حد کے لیے رکھیں اور اُن خدمات کے لیے endpoint راستہ چھوڑ دیں جن کے سامنے سیشن درکار نہیں۔