بیکار وقت میں VPN کے کٹنے کا ازالہ: Wi-Fi پاور سیونگ کے لیے چیک لسٹ

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

پہلی جانچ: کیا کٹنا بیکاری کے پیچھے چلتا ہے؟

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

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

دوسری جانچ: کیا یہ صرف VPN ٹریفک ہے؟

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

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

تیسری جانچ: پاور سیونگ کی حالت پڑھیں

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

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

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

Windows پر powercfg /q SCHEME_CURRENT فعال اسکیم چھاپتا ہے، اور وائرلیس اڈاپٹر کی ذیلی شاخ دکھاتی ہے کہ اڈاپٹر کو توانائی بچانے کا حکم دیا جا سکتا ہے یا نہیں؛ یہی انتخاب اڈاپٹر کے پاور مینجمنٹ ٹیب پر Device Manager میں بھی ہے۔ macOS پر ہر انٹرفیس کے لیے 802.11 پاور سیونگ آپ کو نہیں دکھائی جاتی، اس لیے اس کے بجائے pmset -g نیند اور اسٹینڈ بائی کے رویے کو دیکھیں۔ وہاں خرابی عام طور پر ریڈیو کے بیکار رویے میں نہیں، بلکہ نیند اور جاگنے کے راستے میں نکلتی ہے۔

چوتھی جانچ: ایک چیز بدلیں، پھر دوبارہ جانچیں

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

کنکشن کو زندہ رکھنا دوسرا خود مختار متغیر ہے اور اسے مسلسل پاور سیونگ سے خلط ملط کیا جاتا ہے۔ WireGuard کا PersistentKeepalive = 25 NAT میپنگ کو گرم رکھتا ہے؛OpenVPN دونوں سروں پر keepalive اور ping-restart استعمال کرتا ہے۔ دونوں ورنہ خاموش ٹنل پر ٹریفک پیدا کرتے ہیں، اس لیے جو زندہ رکھنا کٹنے کو درست کرتا دکھتا ہے وہ ریڈیو کے مسئلے کو حل کرنے کے بجائے چھپا سکتا ہے۔ انہیں الگ الگ، ایک وقت میں ایک جانچیں:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

پانچویں جانچ: جب ریڈیو بے قصور ہو

اگر پاور سیونگ بند اور زندہ رکھنا چالو ہونے کے باوجود بیکاری کے کٹنے جاری رہیں تو لیپ ٹاپ سے باہر دیکھیں۔ ایکسیس پوائنٹس اور گھریلو راؤٹر اپنے ہی شیڈول کے مطابق بیکار NAT یا سیشن اندراجات کو ختم کرتے ہیں، اور VPN سرور بغیر ٹریفک کے سیشن گرا سکتا ہے۔ایک ہی SSID شیئر کرنے والے ایکسیس پوائنٹس کے درمیان رومنگ بھی لنک کو ری سیٹ کر سکتی ہے، بغیر کلائنٹ کے یہ واضح طور پر کہے.

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

اسے مستقل بنانے سے پہلے

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

• اصل پاور سیونگ قدر اسکرپٹ کے پاس لکھیں تاکہ اسے بحال کیا جا سکے۔
• ہر ڈرائیور یا کلائنٹ اپ ڈیٹ کے بعد بیکاری کا تجربہ دہرائیں؛ ڈیفالٹ بدلتے ہیں۔
• مسئلہ بتاتے وقت ping لاگ اور کلائنٹ لاگ ساتھ رکھیں۔
• اگر دوسرا قدم ناکام ہوا تو VPN سیٹنگز بدلنا بند کریں اور اسے مقامی لنک کی خرابی سمجھیں۔

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