VGW یا TGW؟ AWS Site-to-Site کا IPsec ٹنل کہاں ختم ہوتا ہے

لوگ پوچھتے ہیں کہ AWS Site-to-Site VPN پیکٹ کی حفاظت کہاں چھوڑ دیتا ہے اور ایک ہی جواب کی توقع کرتے ہیں: گیٹ وے پر۔ اس جواب کی کارآمد شکل بتاتی ہے کہ کون سا گیٹ وے، کیونکہ ورچوئل نجی گیٹ وے اور ٹرانزٹ گیٹ وے مختلف اٹیچمنٹ اشیاء کے ساتھ مختلف ترتیبیں ہیں، اور غلط ترتیب فرض کرنے والا جائزہ لینے والا باقی جانچ ایسے خاکے پر کھڑی کرتا ہے جو موجود ہی نہیں۔ نیچے دی گئی تین جانچیں ترتیب سے کریں۔ ہر ایک یا تو حد کی تصدیق کرتی ہے یا بتاتی ہے کہ پچھلا جواب کسی اور وسیلے کے بارے میں تھا۔

کچھ بھی جانچنے سے پہلے تینوں آخری نکات کے نام لیں

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

گاہک گیٹ وے آپ کا ہے اور اس کی تشکیل آپ کو نظر آتی ہے۔ AWS ہدف ایک منظم وسیلہ ہے، اور غلطی اسے فرض کر لینا ہے: VPN کنکشن ورچوئل نجی گیٹ وے یا براہِ راست ٹرانزٹ گیٹ وے سے منسلک ہو سکتا ہے، اور کوئی ایک دوسرے کا تقاضا نہیں کرتا۔ تیسرا آخری نکتہ وہی ہے جسے لوگ چھوڑ دیتے ہیں، اور ایپلیکیشن ڈیٹا کے اصل سوال کا جواب صرف وہی دیتا ہے۔

جانچ 1: ٹنل اصل میں کون سا گیٹ وے ختم کرتا ہے

دونوں ترتیبیں معاون ہیں اور Site-to-Site VPN معماری رہنما انہیں ساتھ ساتھ بیان کرتا ہے، اس لیے اکثر سال بھر پرانے خاکے کی بجائے API سے پوچھیں۔ ایک کنکشن پر صرف پڑھنے والی استفسار VPN ہدف کے فیلڈز واپس کرتی ہے:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

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

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

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

جانچ 2: اندرونی پیکٹ اب بھی کیا لے جاتا ہے

IPsec ختم ہونے کے بعد AWS کھلا ہوا پیکٹ اس راستے سے آگے بھیجتا ہے جو اس سے مماثل تھا۔ اس نکتے سے ٹریفک عام VPC ٹریفک ہے، اور VPN کی حفاظت ختم ہو چکی ہے۔ یہ سروس میں خلا نہیں ہے؛ یہی حد کا مطلب ہے، اور چیک لسٹ کی بات یہ ہے کہ اسے صاف کہا جائے، "VPN خفیہ ہے" کو "ڈیٹا شروع سے آخر تک خفیہ ہے" کی جگہ کھڑا نہ ہونے دیا جائے۔

اب دیکھیں کہ اندر کیا تھا۔ اگر اندرونی پیکٹ سادہ متن کا ایپلیکیشن پروٹوکول ہے، تو جب تک کوئی اور اسے خفیہ نہ کرے، نیچے کی طرف کچھ بھی رازداری نہیں بڑھاتا۔ اگر اندرونی پیکٹ پہلے ہی TLS سیشن لے جاتا ہے، تو بیرونی IPsec ہٹانے سے اس سیشن میں کچھ نہیں بدلتا: یہ اپنے آخری نکتے تک محفوظ رہتا ہے، وہ آخری نکتہ جہاں بھی ہو۔

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

جانچ 3: گیٹ وے کے پیچھے TLS کون ختم کرتا ہے

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

جس آخری نکتے کی آپ کو واقعی پرواہ ہے اسے VPC کے اندر سے جانچیں، ایک بار حل کیے گئے IP کی بجائے ایپلیکیشن کے استعمال کردہ نام کے ساتھ:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

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

نتیجہ فیصلے کے طور پر نہیں، حصوں کے طور پر درج کریں

اس چیک لسٹ کا نتیجہ ایک چھوٹی جدول ہے جس میں ہر حصے کے لیے ایک سطر ہے: گاہک گیٹ وے سے AWS VPN ہدف تک، گیٹ وے سے کام کے بوجھ تک، کام کے بوجھ سے ڈیٹا ذخیرے تک، اور درمیان میں کوئی بھی پراکسی چھلانگ۔ ہر سطر بتاتی ہے کہ اسے کیا بچاتا ہے اور وہ حفاظت کس پر منحصر ہے۔ طریقہ اور آخری نکتے کے بغیر "خفیہ" کوئی سطر نہیں ہے۔

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

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