ساٹھ سیکنڈ کی TLS مہلت: کون سا سرا واقعی رکا؟

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

ایک کوشش کو ایسی شناخت دیں جسے آپ تلاش کر سکیں

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

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

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

چار مشاہدے، چار مختلف اگلے قدم

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

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

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

جس مرحلے کا نام ثبوت لیتے ہیں اسے درست کریں

مکمل ہوا TCP کنکشن صرف یہ ثابت کرتا ہے کہ کسی چیز نے ساکٹ قبول کیا۔ یہ ثابت نہیں کرتا کہ سننے والا وہ OpenVPN سروس ہے جو آپ نے ترتیب دی، اور اسی ہوسٹ نام پر ویب سرور براؤزر کو بہترین جواب دیتا ہے جبکہ ٹنل کے لیے وہ غیر متعلق ہے۔

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

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

grep -nE 'TLS Error|VERIFY ERROR|CRL|handshake failed' /var/log/openvpn/server.log
date -u; timedatectl | head -3

ونڈو بڑھانے سے واقعی کیا بدلتا ہے

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

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