TLS خرابی کے بعد OpenVPN بار بار دوبارہ کوشش کرتا رہتا ہے: اسے کیسے روکیں

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

پہلی خرابی چھپانے والا چکر

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

تفاعلی نشستیں اسے برداشت کرتی ہیں کیونکہ عارضی ناکامی اگلی کوشش میں ختم ہو سکتی ہے۔ خودکار روابط ایسی ہی امید برداشت نہیں کر سکتے: عمل کو رکنا ہوگا تاکہ کوئی شخص یا مانیٹر حالت دیکھ سکے۔

کچھ بھی بدلنے سے پہلے ایک مکمل چکر قلمبند کریں۔ دور دراز کا پتہ، خرابی میں بتایا گیا TLS مرحلہ اور یہ کہ عمل بالکل نکلتا ہے یا نہیں، لکھ لیں۔

چکر کے پیچھے دوبارہ کوشش کا نظام

دوبارہ کوشش طے شدہ ہے کیونکہ کئی غیر متعلق ٹائم آؤٹ ایک ہی نظام استعمال کرتے ہیں۔ connect-retry رابطے کی کوششوں کے درمیان وقفہ مقرر کرتا ہے، connect-retry-max ہر دور دراز اندراج کتنی بار آزمایا جائے محدود کر سکتا ہے، اور resolv-retry بار بار نام کی تلاش کو کنٹرول کرتا ہے۔ TLS گفت و شنید کی ناکامی اس نظام تک نقل و حمل کے واقعے کے طور پر پہنچتی ہے، اس لیے کلائنٹ رپورٹ کرنے کے بجائے ایک اور کوشش طے کرتا ہے۔ طے شدہ قدر غیر مستحکم لنک میں مدد دیتی ہے اور ایسے نقص میں نقصان دیتی ہے جو ٹھیک نہیں ہو سکتا۔

--tls-exit آپشن صرف گفت و شنید کی صورت بدلتا ہے۔ دستی کتاب اسے TLS گفت و شنید کی ناکامی پر اخراج بتاتی ہے، جو ہر خرابی پر اخراج سے زیادہ تنگ ہے۔ ٹائم آؤٹ، حل کنندہ کی ناکامیاں اور توثیق کی مستردیاں اپنا رویہ برقرار رکھتی ہیں۔

TLS ناکامی پر کلائنٹ کو باہر نکلنے دینا

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

وہ اخراج نظر آئے گا یا نہیں، یہ نگران طے کرتا ہے۔ Restart=always یا Restart=on-failure والا systemd یونٹ کلائنٹ کو دوبارہ شروع کرتا ہے، اس لیے چکر جاری رہتا ہے اور آپشن کچھ نہ کرتا دکھائی دیتا ہے۔ کلائنٹ کو قصوروار ٹھہرانے سے پہلے پالیسی دیکھیں:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no عمل کو رکا ہوا رہنے دیتا ہے، اور Restart=on-failure غیر صفر حالت کے بعد بھی دوبارہ شروع کرتا ہے۔ اگر آپ چاہتے ہیں کہ ناکامی نظر آئے مگر سروس غیر متعلقہ حادثات سے سنبھل جائے، تو Restart=on-failure مقرر کریں اور دوبارہ آغاز کی آندھی روکنے کے لیے StartLimitBurst اور StartLimitIntervalSec استعمال کریں۔ پھر آخری اخراجی کوڈ کی تصدیق کے لیے یونٹ کی حالت پڑھیں: systemctl status اس کی اطلاع دیتا ہے، اور جرنل پہلی خرابی کو دوبارہ آغاز کے اوپر رکھتا ہے۔

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

ایک بار استعمال ہونے والے اینڈ پوائنٹ سے ثابت کریں

اس رویے پر بھروسہ کرنے سے پہلے اسے دیکھنے کے لیے پروفائل کی نقل کریں اور نقل کو ایسے اینڈ پوائنٹ کی طرف بھیجیں جو TCP رابطہ قبول کرتا ہے مگر کبھی OpenVPN نہیں بولتا۔ اتنا ہی کافی ہے کہ سننے والا جواب دے اور پھر خاموش رہے۔ tls-exit کے ساتھ، مصافحہ ناکام ہونے پر کلائنٹ کو ختم ہونا چاہیے؛ اس کے بغیر وہی پروفائل گردش کرتا رہنا چاہیے۔ نقل استعمال کریں، کبھی کام کرنے والا پروفائل نہیں۔

دونوں رن کا موازنہ اخراجی حالت اور پہلی خرابی کی سطر سے کریں، اس سے نہیں کہ ہر ایک کتنی دیر چلا۔ حالت بتاتی ہے کہ آپشن چلا یا نہیں، اور پہلی سطر بتاتی ہے کہ کون سا مرحلہ ناکام ہوا۔

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

وہ مراحل جن تک یہ آپشن کبھی نہیں پہنچتا

توثیق کی مستردی بعد کا مرحلہ ہے۔ اگر سرور اکاؤنٹ کا جائزہ لے کر مسترد کر دے، تو TLS پہلے ہی طے ہو چکا ہے، اس لیے tls-exit کام نہیں کرتا۔ توثیق کی دوبارہ کوشش کی ترتیبات اگلی دیکھنے کی جگہ ہیں، اور سرور کی وجہ کلائنٹ کی آخری سطر سے زیادہ اہم ہے۔ غلط پاس ورڈ اور غائب سرٹیفکیٹ کلائنٹ کی طرف ملتے جلتے پیغامات پیدا کر سکتے ہیں۔

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

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