strongSwan send_cert: IKE سرٹیفکیٹ کب بھیجا جاتا ہے

گیٹ ویز سرٹیفکیٹ سے متعلق توثیق کی ناکامیاں لاگ کرتے ہیں، اور پہلا ردِعمل وصول کنندہ میں ایک اور CA شامل کرنا ہوتا ہے۔ یہ فرض کرتا ہے کہ سرٹیفکیٹ پہنچ گیا اور مسترد ہو گیا۔ دوسرا امکان یہ ہے کہ وہ کبھی بھیجا ہی نہیں گیا، اور یہ بھیجنے والے کی کنکشن پالیسی طے کرتی ہے۔ اعتماد بدلنے سے پہلے طے کریں کہ دونوں میں سے کیا ہوا۔

send_cert دراصل کیا کنٹرول کرتا ہے

سرٹیفکیٹ کے ذریعے توثیق کے لیے ضروری ہے کہ peer کی آخری ہستی کا سرٹیفکیٹ IKE تبادلے یا پیشگی تیاری کے ذریعے دوسرے فریق تک پہنچے۔ swanctl میں کنکشن کی ترتیب send_cert طے کرتی ہے کہ یہ اختتامی نقطہ اپنا سرٹیفکیٹ پے لوڈ شامل کرتا ہے یا نہیں: کبھی نہیں، ہمیشہ یا ifasked۔ پیش فرض ifasked اسے peer کی سرٹیفکیٹ درخواست کے جواب میں بھیجتا ہے۔ سرٹیفکیٹ طلب کرنا الگ ترتیب ہے، کیونکہ دوسرے فریق سے اس کا سرٹیفکیٹ مانگنا اپنا پیش کرنے کے مترادف نہیں۔

پرانے ipsec.conf تعیناتیوں نے leftsendcert اور rightsendcert استعمال کیے، اور یہ نام مقامی اور دور دراز کے کرداروں سے مطابقت رکھتے ہیں، براہِ راست swanctl سے نہیں۔

کنکشن بدلنے سے پہلے ایک کوشش پڑھیں

ایک کنٹرول شدہ کوشش کی بنیاد پر تشخیص کریں، نہ کہ اس عمومی تاثر پر کہ سرٹیفکیٹ ملوث ہیں۔ پالیسی اور فعال ایسوسی ایشن دونوں کا جائزہ لیا جا سکتا ہے۔

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

وصول کنندہ کا اعتماد الگ فیصلہ ہے

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

جانچ دکھاتی ہے کہ کس جاری کنندہ نے سرٹیفکیٹ پر دستخط کیے اور کب اس کی مدت ختم ہوتی ہے، اور وصول کنندہ کے لنگر کو اسی سے مطابقت ہونی چاہیے۔ تعیناتی کے زیرِ ملکیت جاری کنندہ CA پر بھروسا کریں، سلسلے کے ہر درمیانی سرٹیفکیٹ پر نہیں، کیونکہ ہر درمیانی کو جڑ تک بلند کرنا اعتماد کو ایک peer سے کہیں زیادہ وسیع کر دیتا ہے۔ شناخت کی تصدیق فعال رکھیں، کیونکہ وہ کنکشن جو صرف توثیق بند کر کے کامیاب ہو، درستی نہیں۔ جہاں سلسلہ نامکمل ہو، تیاری درست کریں، بھیجنے والے کی پالیسی نہیں۔

بھیجنے والے کو صرف ثبوت کے ساتھ بدلیں

جب لاگ ظاہر کرے کہ سرٹیفکیٹ کبھی بھیجا ہی نہیں گیا اور وصول کنندہ نے واقعی اسے طلب کیا، تو send_cert کو always پر رکھنا اس کنکشن کے لیے جائز تبدیلی ہے۔ اسے swanctl ترتیب میں نافذ کریں، کنکشن دوبارہ لوڈ کریں اور موجودہ SA دوبارہ استعمال کرنے کے بجائے نیا سیشن قائم کریں۔ تصدیق کریں کہ سرٹیفکیٹ پے لوڈ اب ظاہر ہوتا ہے اور وصول کنندہ اسے مطلوبہ لنگر کے مطابق قبول کرتا ہے۔ اگر کچھ نہ بدلے تو غلطی اعتماد کی طرف تھی اور بھیجنے والے کی ترتیب سبب نہیں تھی۔

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