کنکشن کا انکار سرٹیفکیٹ کا مسئلہ نہیں: VPN رن بک

کلائنٹ کہتا ہے کہ CRL دوبارہ بنانے کے فوراً بعد کنکشن کا انکار ہوا، اس لیے CRL مجرم لگتا ہے۔ ایسا نہیں ہے۔ انکار ٹرانسپورٹ پرت کا جواب ہے، اور سرٹیفکیٹ کی توثیق بعد میں، ٹنل ہینڈ شیک کے اندر ہوتی ہے۔ وقت کا میل سیاق ہے، ثبوت نہیں۔

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

خرابی کو اسی پرت پر پڑھیں جس نے اسے پیدا کیا

connect سے ECONNREFUSED کا مطلب ہے کہ ٹرانسپورٹ کی کوشش مسترد ہوئی: کسی چیز نے reset سے جواب دیا، یا اسٹیک نے ناقابل رسائی پورٹ کی اطلاع دی۔ سرٹیفکیٹ کا مسئلہ یہ خرابی پیدا نہیں کر سکتا، کیونکہ ٹرانسپورٹ کنکشن کے بغیر TLS ہینڈ شیک کبھی شروع نہیں ہوتا۔ اگر انکار نظر آئے تو کلائنٹ سرٹیفکیٹ پیش کرنے کے مرحلے تک بھی نہیں پہنچا۔ یہی ایک حقیقت منسوخی کو وجہ کے طور پر خارج کرتی ہے۔

اس کا الٹ بھی درست ہے۔ منسوخ شدہ سرٹیفکیٹ مکمل TCP کنکشن اور ناکام ہینڈ شیک پیدا کرتا ہے، جو سرور پر توثیق کی خرابی کے طور پر درج ہوتا ہے۔

TCP انکار: کوئی سن نہیں رہا

TCP کے لیے، دیکھیں کہ مطلوبہ انسٹنس چل رہا ہے اور پروفائل میں دیے گئے پتے اور پورٹ سے بندھا ہے۔ ss -lntp سننے والوں کو دکھاتا ہے، اور ان میں سے کسی کا نہ ہونا ہی معمول کی وضاحت ہے۔ جو فائر وال خارج کرنے کے بجائے انکار کرتا ہے وہ کلائنٹ کی طرف وہی پیغام پیدا کرتا ہے، اسی لیے دونوں جانچتے ہیں۔

پتہ خاندان بھی جانچیں۔ 127.0.0.1 یا صرف IPv6 سے بندھی سروس دوسرے پر حل ہونے والے کلائنٹ سے انکار کرے گی۔

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

UDP کے پاس انکار کے لیے ہینڈ شیک نہیں

UDP پر OpenVPN TCP کے معنی میں کنکشن قائم نہیں کرتا، اس لیے connect کے وقت انکار کرنے کو کچھ نہیں۔ Linux میں، UDP ساکٹ کی دکھائی گئی خرابی پچھلے ڈیٹاگرام کے پیدا کردہ ICMP port-unreachable سے آ سکتی ہے۔ udp(7) مین پیج اس غیر ہم وقت رویے کی وضاحت کرتا ہے۔

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

CRL اصل میں کہاں جانچا جاتا ہے

CRL سے مشورہ TLS ہینڈ شیک کے دوران، سامنے والے فریق کے اپنا سرٹیفکیٹ پیش کرنے کے بعد، اور صرف اس صورت میں کیا جاتا ہے جب سرور کی تشکیل اجازت دے۔ OpenVPN کا crl-verify اختیار فائل کی طرف اشارہ کرتا ہے، اور ناکامی سرور لاگ میں سرٹیفکیٹ کا نام لینے والی توثیق کی خرابی کے طور پر ظاہر ہوتی ہے۔

لہٰذا منسوخ شدہ کلائنٹ ٹرانسپورٹ پرت پر جڑتا ہے اور پھر توثیق میں ناکام ہوتا ہے۔ وہی سرور، وہی پورٹ، بالکل مختلف پیغام۔

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

اگلی بار کے لیے مختصر رن بک

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

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