Client VPN سرٹیفکیٹ دوبارہ درآمد کرنے کے لیے نیا اینڈ پوائنٹ کیوں ضروری ہے

Client VPN کنکشن ٹوٹ جاتا ہے، ACM میں سرٹیفکیٹ بدل دیا جاتا ہے، اور کچھ نہیں بدلتا۔ سرٹیفکیٹ آبجیکٹ وہ چیز کبھی نہیں تھا جو اینڈ پوائنٹ استعمال کر رہا تھا۔ اینڈ پوائنٹ بنتے وقت سرٹیفکیٹ سے تعلق محفوظ کرتا ہے، ساتھ ہی وہ کلائنٹ CA جس کے سامنے توثیق کرے گا، توثیق کی قسم، ذیلی نیٹ اور اجازت کے قواعد، اور ان تعلقات میں سے کسی میں بھی متبادل سرٹیفکیٹ قبول کرنے والی تبدیلی کال نہیں ہے۔ ARN کے پیچھے موجود بائٹس بدلنا سرٹیفکیٹ میں تبدیلی ہے، اس اینڈ پوائنٹ میں نہیں جس نے اسے پکڑا۔

اینڈ پوائنٹ سرٹیفکیٹ نہیں، حوالہ جات محفوظ کرتا ہے

اس طریقہ کار کو درست طریقے سے بیان کرنا مناسب ہے، کیونکہ یہ پوری ناکامی کی وضاحت کرتا ہے۔ create-client-vpn-endpoint سرور سرٹیفکیٹ کا ARN اور کلائنٹ روٹ سرٹیفکیٹ زنجیر کا ARN لیتا ہے، اور نتیجے میں بننے والا اینڈ پوائنٹ ان حوالہ جات کو توثیق کے اختیارات کے ساتھ مستقل خصوصیات کے طور پر رکھتا ہے۔ API موجودہ اینڈ پوائنٹ پر سرور سرٹیفکیٹ بدلنے کی کوئی کارروائی فراہم نہیں کرتا۔

آپ اندازہ لگائے بغیر تعلق کی تصدیق کر سکتے ہیں۔ aws ec2 describe-client-vpn-endpoints --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 سرٹیفکیٹ کا ARN، کلائنٹ روٹ زنجیر کا ARN، توثیق کی قسم، کلائنٹ CIDR اور متعلقہ ذیلی نیٹ چھاپتا ہے، جو ان خصوصیات کا مکمل مجموعہ ہے جنہیں آپ کو دوبارہ بنانا ہوگا۔ اسے دوبارہ درآمد سے پہلے اور بعد چلائیں، آؤٹ پٹ نہیں ہلے گا۔ یہی ثبوت ہے کہ دوبارہ درآمد کبھی مدد نہیں کرتی۔

دوبارہ درآمد اینڈ پوائنٹ تک کیوں نہیں پہنچ سکتی

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

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

زنجیر کلائنٹ سرٹیفکیٹ کا حصہ ہے

ناکامی کا دوسرا نصف کلائنٹ سرٹیفکیٹ میں ہے، اور اسے نظر انداز کرنا آسان ہے۔ کلائنٹ سرٹیفکیٹ کو اسی زنجیر کے ساتھ درآمد کرنا ضروری ہے جس نے اسے جاری کیا، اگرچہ درآمد فارم اس خانے کو اختیاری دکھاتا ہے۔ زنجیر کے بغیر اینڈ پوائنٹ کلائنٹ سرٹیفکیٹ سے اس کلائنٹ روٹ CA تک راستہ نہیں بنا سکتا جس کے ساتھ اسے ترتیب دیا گیا تھا، اور کنکشن نرم ری سیٹ پر ختم ہوتا ہے جو پیکٹ گرانے والے فائر وال جیسا لگتا ہے۔ openssl verify -CAfile root-ca.pem client.crt اس سوال کا جواب مقامی طور پر ایک سیکنڈ میں دیتا ہے، اور آپ کو چلانے والا پہلا کمانڈ وہی ہونا چاہیے۔

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

اینڈ پوائنٹ دوبارہ بنانا ایک منتقلی ہے

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

اسے محفوظ رکھنے والا ترتیب مختصر ہے: اسی CIDR، ذیلی نیٹ اور اجازت کے قواعد کے ساتھ نیا اینڈ پوائنٹ بنائیں، aws ec2 export-client-vpn-client-configuration سے تازہ پروفائل برآمد کریں، اور ایک صارف کے ساتھ تصدیق کریں۔ اس کے بعد ہی پرانا اینڈ پوائنٹ نیچے آتا ہے۔

پرانا اینڈ پوائنٹ سروس سے ہٹانے کا اپنا ترتیب ہے۔ اسے حذف کرنے سے پہلے وہ کلائنٹ سرٹیفکیٹ منسوخ کریں جنہیں ہٹانا تھا، کیونکہ پرانے CA پر اب بھی بھروسہ کرنے والا نیا اینڈ پوائنٹ ان سرٹیفکیٹ کو قبول کرتا رہتا ہے جنہیں آپ گئے ہوئے سمجھتے تھے۔ پھر پرانا اینڈ پوائنٹ حذف کریں اور اس کے اجازت کے قواعد ہٹائیں، تاکہ پرانا پروفائل آپ کے بند سمجھے گئے ہدف نیٹ ورک سے دوبارہ نہ جڑ سکے۔ پرانے اینڈ پوائنٹ کا ID اور تعلق کے شناخت کنندگان تبدیلی ریکارڈ میں لکھیں، کیونکہ یادداشت سے موازنہ کی گئی منتقلی ہی کام کرنے والے اینڈ پوائنٹ کو دو بار دوبارہ بنانے کا راستہ ہے۔

تشخیص کو ترتیب دیں

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

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

اگلی دوبارہ تعمیر فوری تدبیر نہیں بلکہ diff بنے، اس لیے چار چیزیں ورژن کنٹرول میں رکھیں: اینڈ پوائنٹ کے پیرامیٹر، سرٹیفکیٹ اور زنجیر کے ARN، اجازت کے قواعد اور کلائنٹ CIDR۔ Client VPN توثیق کی دستاویز بتاتی ہے کہ کون سا سرٹیفکیٹ کیا کردار ادا کرتا ہے، اور سرٹیفکیٹ کو ہی مسئلہ سمجھنے سے پہلے یہ دیکھنا مناسب ہے۔ اگر دوبارہ درآمد کچھ نہ بدلے اور اینڈ پوائنٹ اب بھی ری سیٹ ہو، تو مشتبہ تعلق ہی ہے اور جواب ریکارڈ شدہ پیرامیٹرز سے بنایا گیا نیا اینڈ پوائنٹ ہے۔ اگر اینڈ پوائنٹ واقعی نیا آبجیکٹ لے لے، تو تعلق پہلے ہی درست تھا اور خرابی کلائنٹ زنجیر یا اجازت کی تہہ میں ہے۔