سرٹیفکیٹ تبدیل کرنے کے بعد OpenConnect گیٹ وے کو کیوں مسترد کرتا ہے؟
گیٹ وے کا سرٹیفکیٹ تبدیل ہونے کے بعد تصدیق کی ناکامی اعتماد کا فیصلہ ہے، ٹوٹی ہوئی سرنگ نہیں۔ جاری کرنے والی CA اور ایک ہی کلید کو پن کرنے کے درمیان انتخاب کریں۔
گیٹ وے سرٹیفکیٹ تبدیل کرتے ہیں، اور کل جوڑنے والا کلائنٹ پہلے TLS تبادلے پر رکنا شروع کر دیتا ہے۔ پیغام نیٹ ورک خرابی کے بجائے تصدیق کی وجہ بتاتا ہے، اور مشین خود نہیں بدلی، یہی کارآمد سراغ ہے۔ جو ٹوٹا وہ اب پیش کیے جانے والے سرٹیفکیٹ اور کلائنٹ کی قبول کرنے پر تیار جڑوں کے درمیان تعلق ہے۔ اسے ٹھیک کرنا اعتماد کا فیصلہ ہے، اس لیے کوئی آپشن لکھنے سے پہلے وہ فیصلہ کریں۔
کوئی بھی اعتماد کی ترتیب بدلنے سے پہلے ناکامی پڑھیں
غائب دستخط کنندہ قسم کی غلطی کا مطلب ہے کہ زنجیر کسی ایسی چیز پر ختم ہوتی ہے جسے کلائنٹ قبول نہیں کرتا۔ یہ اندرونی اتھارٹی کا تجدید شدہ سرٹیفکیٹ، کسی عوامی اتھارٹی کا متبادل، یا درمیان میں موجود آلہ اپنا سرٹیفکیٹ پیش کر رہا ہو سکتا ہے۔ محض الفاظ ان صورتوں میں فرق نہیں کر سکتے، اس لیے فیصلے سے پہلے جاری کنندہ کو دیکھیں۔
کنکشن ایک بار پیش منظر میں چلائیں اور ناکام ہونے دیں، کیونکہ تعاملی آؤٹ پٹ سرور کا نام، جاری کنندہ زنجیر اور کلائنٹ کا شمار کردہ فنگر پرنٹ رکھتا ہے۔ اُس جاری کنندہ کا موازنہ اُس اتھارٹی سے کریں جو آپ کی تنظیم واقعی چلاتی ہے۔ اگر فنگر پرنٹ بدلا مگر جاری کنندہ نہیں، تو اسے مشتبہ سمجھیں جب تک آپ کے پہلے سے قابلِ اعتماد ذریعے سے تجدید کی تصدیق نہ ہو جائے۔ اس موقع پر اندازہ لگانا ہی وہ راستہ ہے جس سے کوئی بالآخر درمیان میں آنے والے کی کلید پن کر دیتا ہے۔
اسی نوٹ میں کلائنٹ کا ورژن لکھیں۔ اعتماد کے مسئلے جیسی نظر آنے والی بہت سی ناکامیاں پرانے کلائنٹ کے نئے گیٹ وے تبادلے سے ٹکرانے سے آتی ہیں۔
جاری کنندہ پر اعتماد اور ایک کلید پن کرنے کے درمیان انتخاب کریں
دونوں آپشن کنکشن کو کامیاب بناتے ہیں۔ وہ بعد میں متضاد طریقوں سے ٹوٹتے ہیں، اس لیے انتخاب اُس ناکامی کا ہے جو آپ برداشت کر سکیں۔
| Approach | Good fit | What breaks it |
|---|---|---|
Trust the issuing CA with --cafile | Internal PKI you can obtain over an already trusted channel | CA rotation, or a client that still falls back to public roots |
Pin one key with --servercert | No CA relationship, or exactly one key should ever be accepted | Any reissue that generates a new key pair |
CA فائل کی طرف جائیں جب سرٹیفکیٹ ایسی اتھارٹی سے آئے جسے آپ خود مختار طور پر تصدیق کر سکتے ہیں، کیونکہ پھر تجدیدات کلائنٹ کے دلائل کو چھوئے بغیر کام کرتی رہتی ہیں۔ اسے اُس سوئچ کے ساتھ جوڑیں جو نظام کی جڑیں غیر فعال کرتا ہے، ورنہ کوئی عوامی اتھارٹی آپ کی طرف سے جانچ پوری کر سکتی ہے۔ اس کے بجائے پن کریں جب گیٹ وے کے پاس حاصل کرنے کے قابل CA نہ ہو یا جب ہدف ممکنہ حد تک تنگ استثنا ہو۔ کوئی راستہ بھی تجریدی طور پر زیادہ محفوظ نہیں: CA تجدیدات میں پھیلتی ہے، پن کا جائزہ لینا آسان ہے۔
آپ جو بھی چنیں، قابلِ اعتماد قدر تبدیلی سے پہلے قابلِ اعتماد رہنے والے ذریعے سے آنی چاہیے۔ منتظم، گیٹ وے پر کنسول سیشن، یا پہلے سے لی گئی نقل، سب اہل ہیں۔ پرامپٹ جو بھی فنگر پرنٹ دکھائے اُس کی نقل کرنا سہولت ہے اور ٹھیک وہی ہے جس کی درمیان میں آنے والا امید کرتا ہے۔
قدر اُسی کمانڈ میں رکھیں جو آپ واقعی شروع کرتے ہیں
پن سرور سرٹیفکیٹ آپشن میں جاتا ہے، اور اس کا سابقہ انکوڈنگ کا تعین کرتا ہے: sha1 یا sha256 کے تحت ہیکساڈیسیمل عوامی کلید کے خلاصے، اور pin-sha256 کے تحت base64 کلید پن۔ اسے دینے سے اُس رن کے لیے نظام کا اعتماد بھی غیر فعال ہو جاتا ہے، چنانچہ پن شدہ کلید ہی پورا فیصلہ بن جاتی ہے۔
sudo openconnect --protocol=gp vpn.example.com --user alice \
--servercert pin-sha256:AbCdEf... # single key pin
sudo openconnect vpn.example.com --cafile /etc/ssl/internal-ca.pem --no-system-trustکلائنٹ کٹے ہوئے خلاصے سے مطابقت کرتا ہے، سابقے کے بعد صرف چار حروف بھی قبول کرتا ہے، جو سہولت نہیں بلکہ جال ہے۔ مختصر قدر مقامی طور پر گزر جاتی ہے اور پھر بھی آپ کے مطلوبہ گیٹ وے کی شناخت نہیں کرتی۔ پیغام سے دوبارہ ٹائپ کرنے کے بجائے پہلی کوشش میں کلائنٹ کی چھاپی ہوئی پوری سٹرنگ نقل کریں۔ پھر تیار آپشن کو اُس ریپر اسکرپٹ، یونٹ فائل یا پروفائل میں منتقل کریں جو کنکشن شروع کرتا ہے، تاکہ اعتماد کا فیصلہ قابلِ جائزہ رہے اور بعد کی تدوینیں دانستہ ہوں۔
ڈیسک ٹاپ لانچر اور NetworkManager پلگ ان کنکشن دلائل کی اپنی نقل رکھتے ہیں۔ ڈسک پر تدوین شدہ اسکرپٹ پہلے درآمد شدہ پروفائل تک نہیں پہنچتی، اس لیے محفوظ قدر جیتتی رہتی ہے۔
خود کو باہر مقفل کیے بغیر تبدیلی نمٹائیں
آپشن ایک سے زیادہ بار دیا جا سکتا ہے، اس لیے منصوبہ بند تبدیلی باہر جانے والی اور اندر آنے والی کلید ایک ساتھ قبول کر سکتی ہے۔ گیٹ وے کے بدلنے سے پہلے نیا پن شامل کریں، سیشن منتقل ہوتے رہنے تک دونوں کو فہرست میں رکھیں، اور پرانی کلید جانے پر ریٹائر شدہ کو ہٹا دیں۔ اُس ونڈو کا مالک ضروری ہے، کیونکہ بھولا ہوا دوہرا پن کلید کو بغیر کسی نگرانی کے قابلِ اعتماد چھوڑ دیتا ہے۔ نئی کلید جوڑی پیدا کرنے والی تعمیرِ نو خالص پن توڑ دیتی ہے، اور بحالی مخالف سمت میں وہی طریقہ کار ہے۔
پن کے ساتھ تبدیلی کی تاریخ لکھیں۔ جائزے کی تاریخ کے بغیر پن گومڑ دینے والا نقص پیغام لیے مستقبل کی رکاوٹ ہے۔
اعتماد میں ترمیم سے پہلے کلائنٹ ورژن کو خارج کریں
پرانے کلائنٹ کو گیٹ وے کی بعد میں بدلی گئی توثیقی جواب تجزیہ کرتے وقت ناکامی ہو سکتی ہے، اور سطحی پیغام اب بھی تجزیہ کار کے بجائے کنکشن کی بات کرتا ہے۔ نصب شدہ ورژن کا موازنہ اُس سے کریں جو گیٹ وے دستاویز کرتا ہے، اور کوئی بھی اعتماد ترتیب بدلنے سے پہلے موجودہ پیکج کو ایک بار کے پروفائل میں جانچیں۔
openconnect --versionمرمت کے بعد ایک نہیں دو چیزیں جانچیں: پورٹل سرنگ سے لوڈ ہوتا ہے، اور ایک عام اندرونی پتہ جواب دیتا ہے۔ مکمل شدہ مصافحہ صرف یہ ثابت کرتا ہے کہ اعتماد کا فیصلہ قبول ہوا۔