OpenConnect کو منقطع VPN پر کتنی دیر دوبارہ کوشش کرنی چاہیے؟

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

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

دوبارہ جڑنے کی کھڑکی دراصل کیا محدود کرتی ہے

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

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

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

نگران کی دوبارہ چلائیں اور کلائنٹ کی نئی کوششیں دو تہیں ہیں

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

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

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

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

حوالگی کو دوبارہ کوشش کے دھاگے سے مقابلہ کرنے سے روکنا

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

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

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

خلل کے دوران اور بعد میں کیا تصدیق کرنی ہے

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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