AWS Client VPN منسلک ہے، مگر EC2 پھر بھی جواب نہیں دیتا

میرے لیپ ٹاپ نے منسلک دکھایا۔ AWS Client VPN کلائنٹ نے اپنی سبز حالت دکھائی، endpoint نے سیشن درج کیا، اور پھر بھی میں نجی ذیلی نیٹ ورک میں EC2 انسٹانس پر MongoDB پورٹ نہیں کھول سکا۔ ظاہری طور پر کچھ ٹوٹا نہیں تھا: سرٹیفکیٹ درست تھا، پروفائل کنسول سے آیا تھا، اور ٹنل ٹریفک لے جا رہی تھی۔ غلطی میری تھی، کیونکہ میں منسلک کو مجاز کے معنی میں پڑھ رہا تھا۔

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

نیچے دی گئی جانچیں وہی ترتیب ہیں جو اب میں استعمال کرتا ہوں۔

منسلک سیشن واقعی کیا ثابت کرتا ہے

ہینڈ شیک کے دوران endpoint کلائنٹ سرٹیفکیٹ کو اپنے trust store کے سامنے جانچتا ہے، یا جب SAML ترتیب دیا گیا ہو تو براؤزر کو آپ کے شناختی فراہم کنندہ کی طرف بھیج دیتا ہے۔ اگر وہ گزر جائے تو کلائنٹ کو endpoint کے کلائنٹ CIDR سے پتہ ملتا ہے اور کنسول فعال کنکشن دکھاتا ہے۔ اس تبادلے کے کسی بھی لمحے یہ نہیں پوچھا جاتا کہ آپ 10.0.4.17 تک پورٹ 27017 پر پہنچ سکتے ہیں یا نہیں۔

کسی منزل کی اجازت endpoint پر الگ شے ہے۔ ہر بہاؤ کو اجازت کے قواعد سے ملایا جاتا ہے، اور ہر قاعدہ منزل کے CIDR کو اس گروپ سے جوڑتا ہے جسے قاعدہ دیا گیا ہے۔ جب کوئی قاعدہ منزل کو نہیں ڈھکتا، endpoint سیشن قبول کر لیتا ہے اور ٹریفک گرا دیتا ہے۔ کوئی بینر نہیں، دوبارہ جڑنے کا لوپ نہیں، اور کلائنٹ کے انٹرفیس میں کچھ بھی نہیں جو مسترد کہے۔

اجازت کے قاعدے کا موازنہ VPC سے نہیں، وسیلے سے کریں

قواعد کی فہرست بنائیں اور انہیں اس پتے کے پاس رکھیں جو انسٹانس کے پاس واقعی ہے:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

آؤٹ پٹ ہر قاعدے کے لیے منزل کا CIDR اور گروپ ID دکھاتا ہے۔ اس میں دو ناکامیاں چھپی ہیں۔ قاعدہ 10.0.0.0/16 کی اجازت دے سکتا ہے جبکہ انسٹانس 10.1.0.0/16 پر peer شدہ VPC میں بیٹھا ہے؛ peering راستہ موجود ہے، مگر کسی نے دوسری رینج کے لیے اجازت کا قاعدہ نہیں لکھا۔ یا قاعدہ ایسے ڈائریکٹری گروپ کی طرف اشارہ کرتا ہے جس میں صارف ڈائریکٹری میں رکن ہے مگر اس گروپ میں نہیں جس کا endpoint جائزہ لیتا ہے۔

منزل کو ڈھکنے والا سب سے تنگ قاعدہ لکھیں، اور دوسرا قاعدہ صرف اسی وقت شامل کریں جب دوسرا CIDR واقعی درکار ہو۔ تیز آغاز سے آیا وسیع 0.0.0.0/0 قاعدہ کام کرتا ہے، اور اسی لیے وہ پروڈکشن تک زندہ رہتا ہے اور ماڈل چھپا دیتا ہے۔

پیکٹ کے چلنے کا فیصلہ دو روٹ ٹیبل کرتے ہیں

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

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8

ایسا راستہ تلاش کریں جس کی منزل وسیلے کے CIDR سے میل کھاتی ہو اور جس کا ہدف منسلک ذیلی نیٹ ورک ہو۔ اگر راستہ نہ ہو تو شامل کریں۔ اگر ہو اور ہوسٹ پھر بھی خاموش ہو تو خلا VPC کی طرف ہے، اس لیے منسلکہ ذیلی نیٹ ورک کے روٹ ٹیبل سے موازنہ کریں۔

کلائنٹ کی طرف کی ایک ترتیب ٹنل توڑے بغیر روٹنگ توڑ دیتی ہے: route-nopull والا پروفائل۔ یہ ہدایت OpenVPN پر مبنی کلائنٹ سے کہتی ہے کہ سرور کے دھکیلے ہوئے راستوں کو نظر انداز کرے، اس لیے انٹرفیس صرف endpoint کے اپنے پتے کے ساتھ اٹھتا ہے اور منزل کا کوئی راستہ ہی نہیں ہوتا۔ Linux پر ip route show یا macOS پر netstat -rn سے جانچیں کہ tun انٹرفیس سے راستہ موجود ہے یا نہیں۔ اگر نہ ہو تو برآمد شدہ پروفائل سے route-nopull ہٹائیں اور دوبارہ جڑیں تاکہ دھکیلے گئے راستے لاگو ہوں۔

سیکیورٹی گروپس آپ کے کلائنٹ کا پتہ نہیں دیکھتے

یہ وہ حصہ ہے جسے میں نے آدھا دن غلط رکھا۔ ذیلی نیٹ ورک سے منسلک IPv4 endpoint کے لیے، سروس کلائنٹ کے ماخذ پتے کو اسی ذیلی نیٹ ورک میں endpoint کے نیٹ ورک انٹرفیس کے پتے میں تبدیل کرتی ہے۔ انسٹانس تک پہنچنے والا پیکٹ وہ پتہ نہیں اٹھاتا جو آپ کے کلائنٹ نے دکھایا تھا، اس لیے کلائنٹ پول، فرض کریں 172.16.0.0/22، کی اجازت دینے والا سیکیورٹی گروپ قاعدہ کسی چیز سے میل نہیں کھاتا۔

پورٹ کو کلائنٹ CIDR سے نہیں، endpoint کے سیکیورٹی گروپ سے اجازت دیں جو منسلکے کے انٹرفیس پر لگا ہے۔ گروپ کا حوالہ دینا پتہ سخت کوڈ کرنے سے زیادہ دیرپا ہے، کیونکہ انٹرفیس کا پتہ آپ کے کنٹرول میں نہیں۔ نیٹ ورک ACL بے حالت ہیں، اس لیے جہاں اپنی اندراجیں ہوں وہاں آنے اور جانے دونوں سمتوں کو بہاؤ کی اجازت دینی ہوگی۔

انسٹانس کے نجی پتے سے بھی جڑیں۔ عوامی IP پیکٹ کو VPC سے باہر لے جاتا ہے اور دوسرے قواعد کے ساتھ دوسرے راستے سے واپس لاتا ہے، اس لیے عوامی پتے پر جانچ نجی راستے کے بارے میں کچھ نہیں کہتی۔

پہلی ناکامی پر رکنے والی تنہائی کی ترتیب

انہیں ترتیب سے کریں اور جہاں ایک ناکام ہو وہیں رکیں۔ ہر قدم تمام تہوں کو نہیں، ایک تہہ کو خارج کرتا ہے۔

1. تصدیق کریں کہ سیشن نے کون سی شناخت استعمال کی اور endpoint کس گروپ کا جائزہ لیتا ہے۔ ایک trust store کا سرٹیفکیٹ ڈائریکٹری سے آنے والے SAML دعوے جیسا ایک ہی پرنسپل نہیں ہے۔
2. تصدیق کریں کہ اجازت کا قاعدہ اس گروپ کے لیے وسیلے کا CIDR ڈھکتا ہے۔
3. تصدیق کریں کہ endpoint کا راستہ موجود ہے اور منسلک ذیلی نیٹ ورک کو نشانہ بناتا ہے، پھر کہ ذیلی نیٹ ورک کا روٹ ٹیبل آگے بھیج سکتا ہے۔
4. تصدیق کریں کہ سیکیورٹی گروپ پورٹ کو کلائنٹ پول سے نہیں، endpoint انٹرفیس سے اجازت دیتا ہے۔
5. ایپلیکیشن کے مسئلے کو کلائنٹ راستے کے مسئلے سے الگ کرنے کے لیے VPC کے اندر سے، اسی ذیلی نیٹ ورک کے کسی دوسرے انسٹانس پر SSM سیشن کے ساتھ جانچیں۔

جب قدم فیصلہ کن نہ ہوں تو میں اسی جدول پر بھروسا کرتا ہوں:

اکاؤنٹ کی دو تفصیلیں ایسی علامات پیدا کرتی ہیں جو اجازت کی ناکامی جیسی لگتی ہیں۔ ہر صارف کو الگ کلائنٹ سرٹیفکیٹ چاہیے؛ ایک کو دو مشینوں میں بانٹنے سے سیشن ایک دوسرے کو دھکیلتے ہیں، اور نتیجہ انکار نہیں بلکہ دوبارہ جڑنے کا لوپ ہوتا ہے۔ جب نیا endpoint بنتا ہے تو کنسول ایک DNS نام دکھاتا ہے جسے کچھ کلائنٹ ورژن صرف endpoint کے صفحے پر دکھائے گئے بے ترتیب سابقے کے ساتھ قبول کرتے ہیں، اس لیے نام دوبارہ بنانے کے بجائے پورا نام نقل کریں۔

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