کیوں EC2 آپ کے AWS Client VPN لیپ ٹاپ تک نہیں پہنچ سکتا
Client VPN IPv4 کلائنٹ ماخذوں کو endpoint کے نیٹ ورک انٹرفیس میں ترجمہ کرتا ہے۔ اسی لیے جواب کام کرتا ہے اور EC2 سے نئی کنکشن نہیں۔
AWS Client VPN کے ذریعے جڑا لیپ ٹاپ بغیر کسی دشواری کے EC2 ایپلیکیشن تک پہنچ جاتا ہے۔ پھر آپ اُلٹا آزماتے ہیں، EC2 سے اُس پتے تک جو کلائنٹ کو دیا گیا تھا، اور کنکشن لٹک جاتا ہے یا مسترد ہو جاتا ہے۔ یہ عدم توازن شاذ و نادر ہی کسی غائب سیکیورٹی گروپ اصول کی وجہ سے ہوتا ہے۔ VPC سب نیٹس سے منسلک Client VPN endpoint پر AWS IPv4 کلائنٹ ماخذوں کو endpoint کے نیٹ ورک انٹرفیس میں ترجمہ کرتا ہے، اس لیے کوئی آنے والا VPC پتہ ایسا نہیں جو آپ کے لیپ ٹاپ کی نمائندگی کرے۔
کیپچر جو دکھاتا ہے اُس سے شروع کریں
کلائنٹ کے جڑنے کے دوران EC2 ہوسٹ پر کیپچر لیں اور وہ ماخذ پتہ پڑھیں جو ایپلیکیشن واقعی دیکھتی ہے۔ اگر وہ کلائنٹ پول کا پتہ نہیں بلکہ VPC کی طرف endpoint کا انٹرفیس ہے، تو ایک اصول بدلنے سے پہلے ہی ترجمہ کی تصدیق ہو جاتی ہے۔
کلائنٹ پول ایک تقسیمی حد ہے، واپسی راستے والا سب نیٹ نہیں۔ اسی فرق پر ایسی زیادہ تر تحقیقات غلط ہو جاتی ہیں۔
وہ ترجمہ جو عدم توازن کی وضاحت کرتا ہے
تین بہاؤ آپس میں گڈمڈ کر دیے جاتے ہیں، اور اُن میں سے صرف ایک وہ ہے جسے لوگ آزماتے ہیں۔
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN اجزاء کی وضاحت واضح طور پر بتاتی ہے کہ IPv4 کلائنٹ ماخذ endpoint انٹرفیس میں ترجمہ ہوتے ہیں، اور یہ دیکھنے کے لیے کافی ہے کہ درمیانی قطار کے پاس ملانے کو کچھ کیوں نہیں۔
نئی کنکشن کو راستہ، پتے کے حل کا مرحلہ اور اجازت کا فیصلہ درکار ہوتا ہے۔ کسی اور کے سیشن سے ترجمے کی حالت اِن تینوں میں سے ایک بھی فراہم نہیں کرتی۔
جواب نئی کنکشن کیوں نہیں
TCP جواب موجود اندراج سے ملایا جاتا ہے، اسی لیے کوئی آنے والا اصول نہ ہونے کے باوجود واپسی کا راستہ کام کرتا ہے۔ EC2 ہوسٹ سے نیا SYN ملانے کے لیے اندراج نہیں پاتا، اس لیے وہ ایسی منزل کی طرف عام باہر جانے والی کوشش بن جاتا ہے جہاں پہنچنے کا طریقہ VPC نہیں جانتا۔
اسی لیے اِسے صرف ایک سمت جانے والی ٹریفک کہنا گمراہ کن ہے۔ اِن سیشنز میں واپسی کی ٹریفک مسلسل بہتی رہتی ہے۔ راستے سے محروم حصہ آغاز ہے۔
جس سیشن کو کام کرنا چاہیے اُسے اب بھی کیا توڑتا ہے
سیکیورٹی گروپس، نیٹ ورک ACL اور لیپ ٹاپ کا اپنا فائر وال — جن کنکشنز کو کامیاب ہونا چاہیے اُن سب کے لیے یہ اہم ہیں۔ ناکام ping سب سے کم بتاتا ہے، کیونکہ ICMP پالیسی اکثر اُس TCP پالیسی سے الگ ہوتی ہے جس کی آپ کو فکر ہے۔
یہ اصول ترجمہ شدہ ماخذ کی بنیاد پر لکھیں، کلائنٹ پتے کی بنیاد پر نہیں۔ نیٹ ورک پر کبھی نہ دکھائی دینے والے پتے سے بندھے اصول اِس ڈیزائن میں سب سے عام خود پیدا کردہ خرابی ہیں۔
جب VPC کو واقعی گفتگو شروع کرنی ہو
اگر کسی سروس کو کسی ورک اسٹیشن کو اطلاع دینی ہو، تو سمت اُلٹ دیں اور کلائنٹ کو ایسا مستقل باہر جانے والا چینل رکھنے دیں جس پر سروس جواب دیتی ہے۔ اگر پورا دور دراز نیٹ ورک VPC سے قابل رسائی ہونا چاہیے، تو یہ ماننے کے بجائے کہ Client VPN پہلے ہی ایسا کرتا ہے، ایسی معماری چنیں جو اپنے سابقے اور رسائی پالیسی شائع کرے۔ کلائنٹ سے کلائنٹ تک رسائی تیسرا، زیادہ تنگ معاملہ ہے، جس کی اپنی راستہ اور اجازت کی اشیاء ہیں۔ اِن میں سے کوئی بھی موجودہ endpoint پر محض ایک چیک باکس نہیں۔
IPv4 کی وضاحت کا دائرہ بھی ایمانداری سے رکھیں۔ موجودہ AWS دستاویزات IPv6 کو الگ کرتی ہیں، جہاں وہ ترجمہ لاگو نہیں ہوتا، اور دیگر کنکشن ماڈلز کو بھی جو مختلف انداز میں راستہ دیتے ہیں۔
تین لیبل والے مراحل میں جانچیں: کلائنٹ اجازت یافتہ سیشن کھولتا ہے، VPC کی سروس اُس سیشن کا جواب دیتی ہے، اور VPC کا ہوسٹ کلائنٹ کی طرف نیا سیشن کھولتا ہے۔ پہلے دو کا کامیاب ہونا اور تیسرے کا ناکام ہونا اِس ڈیزائن کی متوقع شکل ہے، فائر وال اصولوں سے پیچھا کرنے والی خرابی نہیں۔