Client VPN اینڈ پوائنٹ کو ہمیشہ TLS سرور سرٹیفکیٹ درکار ہوتا ہے۔ یہی وہ شناخت ہے جو منظم اینڈ پوائنٹ کلائنٹ کے جڑنے پر پیش کرتا ہے۔ یہ ان سرٹیفکیٹس سے مختلف شے ہے جو انفرادی کلائنٹ باہمی تصدیق کے وقت پیش کرتے ہیں۔ ان دونوں کو خلط ملط کرنا ہی وہ عام ترین وجہ ہے کہ بصورت دیگر درست ACM ترتیب پہلے کنکشن پر ناکام ہو جاتی ہے۔

ذیل میں کنسول سے باہر کی طرف، اسی ترتیب میں ایک جائزہ ہے جس سے ایک کنکشن واقعی گزرتا ہے۔

دو کردار، ایک اینڈ پوائنٹ

اینڈ پوائنٹ کے پاس سرور کی شناخت ہے اور اختیاری طور پر کلائنٹ شناختوں کی تصدیق کا ذریعہ بھی۔ یہ دونوں الگ الگ ترتیب دیے جاتے ہیں۔ ایک طے کرتا ہے کہ آیا کلائنٹ سروس پر بھروسا کر سکتا ہے؛ دوسرا طے کرتا ہے کہ آیا سروس کلائنٹ کو قبول کرتی ہے۔

MaterialPurposeWhere it lives
Server certificate and private keyThe managed endpoint proves its TLS identityACM, in the endpoint's Region
Client certificate and matching keyAn individual client proves its identityOn the device
CA trust materialThe verifier checks the issuer chainSelected for the client role

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

ACM سرور سرٹیفکیٹ کیا کرتا ہے

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

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

باہمی تصدیق کیا اضافہ کرتی ہے

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

اینڈ پوائنٹ کی تصدیق کا طریقہ ایک انتخاب ہے، کوئی عالمیری تقاضا نہیں۔

Active Directory اور وفاقی تصدیق اسی سوال کا دوسرے ذرائع سے جواب دیتے ہیں۔ باہمی سرٹیفکیٹ کا نسخہ خودبخود ان تعیناتوں کا لاگ ان ڈیزائن نہیں بنتا، اور صارف کو کیسے داخل کیا جاتا ہے اس سے قطع نظر سرور کی TLS تصدیق برقرار رہتی ہے۔

ایک ہی CA ARN کلید شیئر کرنا کیوں نہیں

AWS دستاویز کرتا ہے کہ جب سرور اور کلائنٹ سرٹیفکیٹ ایک ہی CA جاری کرے، تو سرور سرٹیفکیٹ کا ARN کلائنٹ سرٹیفکیٹ کے انتخاب کے لیے بھی استعمال ہو سکتا ہے۔ وہ جملہ اس بارے میں ہے کہ تصدیق کے وقت اینڈ پوائنٹ کس سلسلے پر بھروسا کرتا ہے۔ یہ کلائنٹس کو سرور کی نجی کلید استعمال کرنے کو نہیں کہتا۔ لیپ ٹاپ کو اب بھی اپنا کلائنٹ سرٹیفکیٹ اور اپنی مطابق کلید درکار ہے۔

جب کلائنٹ کا CA کوئی دوسرا جاری کنندہ ہو، تو دستاویزی راستہ یہ ہے کہ وہ CA ACM میں درآمد کریں اور کلائنٹ کے کردار کے لیے اسے منتخب کریں۔

ناکامی کو کسی مرحلے تک واپس لے جائیں

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

ایک وقت میں ایک ہی شے بدلیں، کیوں کہ دونوں سرے بیک وقت بدلنا وہی ابہام دوبارہ پیدا کر دیتا ہے جس سے آپ نے آغاز کیا تھا۔

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

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

متعلقہ مضامین