ہر گھنٹے OpenVPN کٹنا: دوبارہ مذاکرات یا حقیقی دوبارہ رابطہ؟

ساٹھ منٹ، یا تیس، یا ایک سو بیس: گول وقفے پر پڑنے والا کٹنا تقریباً کبھی نیٹ ورک نہیں ہوتا۔ OpenVPN ٹائمر کے مطابق ڈیٹا چینل کی حفاظت کرنے والا کلیدی مواد تازہ کرتا ہے، اور آپ کے اندازے سے چھوٹا ٹائمر مسلسل ناکام ہونے والے لنک جیسا ہی دکھائی دیتا ہے۔ صارفین ٹوٹے رابطے کی اطلاع دیتے ہیں جبکہ لاگ کامیاب کلید کے تبادلے کی اطلاع دیتا ہے۔ نیچے دی گئی رہنمائی اس تجدید کو حقیقی دوبارہ آغاز سے الگ کرتی ہے، واقعی نافذ قدر پڑھتی ہے، اور لاگت میز پر آنے کے بعد ہی اسے بدلتی ہے۔

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

نرم ری سیٹ کو دوبارہ آغاز سے الگ پہچانیں

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

نافذ ٹائمر پڑھیں، اپنی فائل نہیں

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

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

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

اسے وہیں بدلیں جہاں یہ واقعی دھکیلا جاتا ہے

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

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

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

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

دوبارہ مذاکرات بند کر کے آپ کیا چھوڑتے ہیں

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

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

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

جب وقفہ کہیں اور اشارہ کرے

ترتیب میں دو پڑوسی ملتے جلتے علامات اور مختلف حل پیدا کرتے ہیں۔ مقررہ مدت تک کچھ نہ آنے پر ping-restart سرنگ دوبارہ شروع کرتا ہے، جبکہ ping-exit کلائنٹ کو مکمل طور پر نیچے اتارتا ہے۔ لاگ میں کہیں بھی دوبارہ مذاکرات کے بغیر بیکار کٹنا انہی کا ہے، یا ایسے NAT آلے کا جس نے اپنے ہی شیڈول پر UDP نقشہ کی مدت پوری کر دی۔

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

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