VPN بار بار منقطع ہو رہا ہے؟ اسی ترتیب سے جانچیں

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

پہلا مرحلہ: وقفہ اور خرابی کا متن ریکارڈ کریں

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

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

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

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

دوسرا مرحلہ: پروفائل نہیں، ایک متغیر بدلیں

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

Ethernet پورٹ والا لیپ ٹاپ دوسرا موازنہ دیتا ہے جو Wi-Fi کو تصویر سے مکمل طور پر ہٹا دیتا ہے۔ اگر ٹنل دونوں متبادلات پر قائم رہے تو اصل رسائی نیٹ ورک توجہ کا حقدار ہے: رسائی مقامات کے درمیان رومنگ، ترجمے کی جدول کی میعاد ختم ہونے والا گھریلو راؤٹر، یا لمبے بہاؤ کو دوبارہ ترتیب دینے والا بالائی لنک۔

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

تیسرا مرحلہ: وقفے کو تہہ سے جوڑیں

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

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

بیکار حالت میں ترتیبات پروٹوکول کے مطابق ہوتی ہیں اور دونوں سرے اہم ہیں۔ سرور پر OpenVPN کا keepalive 10 60 ہر 10 سیکنڈ میں پنگ بھیجتا ہے اور ایک بھی نہ آنے پر 60 سیکنڈ بعد لنک دوبارہ شروع کرتا ہے؛ NAT کے پیچھے WireGuard کلائنٹ ہم منصب بلاک میں PersistentKeepalive = 25 استعمال کرتے ہیں۔ OpenVPN ٹائمر کے مطابق ڈیٹا چینل کی دوبارہ گفت و شنید بھی کرتا ہے، reneg-sec، جو 2.x میں بطور ڈیفالٹ 3600 سیکنڈ ہے۔

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

چوتھا مرحلہ: ایک معاون متبادل کا موازنہ کریں

اگر آپریٹر UDP اور TCP دونوں پروفائل شائع کرتا ہے تو وہی ڈیوائس اور نیٹ ورک دوسرے کے سامنے چلائیں۔ کاپی شدہ پروفائل میں ٹرانسپورٹ میں ترمیم کرنے کی بجائے واقعی مماثل فائل استعمال کریں۔ جہاں UDP دوبارہ ترتیب پاتا ہے وہاں مستحکم TCP پروفائل مسئلے کو اسی راستے تک محدود کرتا ہے؛ یہ ثابت نہیں کرتا کہ TCP ہر جگہ بہتر ٹرانسپورٹ ہے۔

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

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

مرمت کی تصدیق کریں، اور واپسی کا امکان رکھیں

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

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

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

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