VPN گاڑی چلاتے وقت دوبارہ جڑتا ہے: ریڈیو کی تبدیلی یا IP کی تبدیلی؟
ٹاورز کے درمیان منتقلی IP راستہ سلامت چھوڑ سکتی ہے۔ جو کلائنٹ ٹنل کو منتقل کرتے ہیں ان کا اُن سے موازنہ کریں جو اسے دوبارہ بناتے ہیں، اور نیٹ ورک کا واقعہ پڑھیں، سفر نہیں۔
کال اُس وقت منقطع ہوتی ہے جب آپ قصبے کے کنارے سے گزرتے ہیں، اور VPN کا نشان اُسی لمحے غائب ہو جاتا ہے۔ یہ لکھنا دلکش ہے کہ ”ٹاور کی تبدیلی نے ٹنل کو مار ڈالا“۔ دو مختلف چیزیں ہوئیں، اور اِن میں سے صرف ایک ٹاورز سے متعلق ہے۔ ریڈیو کی منتقلی آپ کا IP پتہ، طے شدہ راستہ اور سیشن بالکل سلامت چھوڑ سکتی ہے، جبکہ پتے کی حقیقی تبدیلی ہر ایسی ٹنل کو توڑ دے گی جو اُس کے ساتھ نہیں چل سکتی۔ یہ موازنہ کرنا کہ کلائنٹ دوسری صورت حال سے کیسے نمٹتے ہیں وہی مفید مشق ہے، کیونکہ یہ بتاتی ہے کہ آپ ڈیزائن کردہ رویہ دیکھ رہے ہیں یا نقص۔
ٹاور کی تبدیلی لازماً پتے کی تبدیلی نہیں
موبائل نیٹ ورک منتقلیوں کے دوران پیکٹ سیشن کو زندہ رکھتے ہیں جب تک آپریٹر کا موبلٹی اینکر یکساں رہے۔ ریڈیو لنک بدلتا ہے، ٹنل کو پتہ نہیں چلتا، اور کسی بھی لاگ میں دوبارہ جڑنا ظاہر نہیں ہونا چاہیے۔ یہ شہر کے اندر حرکت کی عام صورتِ حال ہے۔
پتہ وہ چیز بدلتی ہے جو اینکرز کے درمیان منتقلی، Wi-Fi سے سیلولر پر جانا، یا طویل وقفے کے بعد آپریٹر کی طرف ٹنل کا دوبارہ قیام ہے۔ یہ واقعات آپ کے پیکٹوں کے اٹھائے ہوئے ماخذ پتے کی جگہ لیتے ہیں، اور VPN کا ساتھی ایک منتقل شدہ ساتھی دیکھتا ہے۔
عملی نتیجہ یہ ہے کہ حرکت ثبوت نہیں۔ چالیس کلومیٹر چلنے والا آلہ پورے راستے ایک ہی پتہ رکھ سکتا ہے، اور ساکن آلہ دو بار پتہ بدل سکتا ہے کیونکہ نیٹ ورک نے ایسا فیصلہ کیا۔ واقعے کا ریکارڈ رکھنا ہی اِن دونوں میں تمیز کا واحد طریقہ ہے۔
دو ڈیزائن: ٹنل کو منتقل کریں یا دوبارہ بنائیں
کلائنٹ اس بات میں مختلف ہیں کہ اُنہیں کتنی پروا ہے کہ بیرونی ماخذ بدلا۔ بعض ٹنل کو اُس پتے سے باندھتے ہیں جس پر بنی تھی اور مکمل دوبارہ قیام کا مطالبہ کرتے ہیں۔ دیگر ہر پیکٹ کی آزادانہ تصدیق کرتے ہیں اور صرف یہ اپ ڈیٹ کرتے ہیں کہ جوابات کہاں بھیجیں۔
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
اوپر والی سطر بہت سی الجھی ہوئی رپورٹوں کی وضاحت کرتی ہے۔ WireGuard کے پاس کوئی سیشن نہیں جو ٹوٹ سکے: ہر پیکٹ ساتھی کا اشاریہ اٹھاتا ہے اور تصدیق شدہ ہوتا ہے، سو نئے پتے سے آنے والا درست پیکٹ تعریفاً اُسی ساتھی کا ہے، اور ریکارڈ شدہ اختتامی نقطہ اُس کی پیروی کرتا ہے۔ سفر بھر مسلسل ”منسلک“ دکھانے والا کلائنٹ سچ کہتا ہے۔
نیچے والی سطر بھی نقص نہیں۔ سیشن کا دوبارہ قیام تصدیق کو موجودہ پتے کے خلاف پھر چلاتا ہے، اور یہی وہ چیز ہے جو آپ چاہتے ہیں جب پرانا پتہ اب کسی اور کا ہو سکتا ہے۔
واقعہ دیکھیں، حرکت نہیں
Android میں رابطہ کا ذیلی نظام نیٹ ورک کی تبدیلیاں واقعات کے طور پر رپورٹ کرتا ہے، اور وہی ہیں جنہیں کلائنٹ کے رویے سے جوڑنا چاہیے۔ آؤٹ پٹ طویل ہے، مگر اہم حصے طے شدہ نیٹ ورک اور اُس کا پتہ ہیں:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40سرور کی طرف رومنگ کی صورت کے لیے براہِ راست پیمائش موجود ہے۔ WireGuard ہر ساتھی کے لیے آخری تصدیق شدہ اختتامی نقطہ محفوظ رکھتا ہے، سو پتے کی تبدیلی دوبارہ جڑنے کے بجائے بدلی ہوئی قدر کے طور پر ظاہر ہوتی ہے:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesسفر سے پہلے اور بعد میں اختتامی نقطہ کا موازنہ کریں۔ اگر پتہ اور پورٹ نہیں بدلے، تو ٹنل کو کچھ کرنے کی ضرورت نہ تھی اور دوبارہ جڑنا کہیں اور سے آیا، عام طور پر ایپلیکیشن سے۔ اگر اختتامی نقطہ بدلا جبکہ مصافحے کا وقت نشان عام کلید تجدید کی وقفے کے قریب رہا، تو ٹنل منتقل ہوئی، دوبارہ شروع نہیں ہوئی۔
دوبارہ شروع ہونا مختلف دکھتا ہے: مصافحے کا وقت نشان دوبارہ جڑنے کے لمحے پر مقرر ہو جاتا ہے، اور کلائنٹ پرسکون تسلسل کے بجائے ابتدا کا تسلسل ریکارڈ کرتا ہے۔
دوبارہ جڑنا کب درست رویہ ہے
ہر دوبارہ جڑنے کو نقص سمجھنا ایسی ترتیبات کی طرف لے جاتا ہے جو مردہ سیشنوں کو زندہ رکھتی ہیں۔ جس ساتھی کا پتہ اِس لیے بدلا کہ نیٹ ورک نے اسے دوبارہ تقسیم کیا، اُسے پرانی نقشہ بندی کے لیے ٹریفک وصول کرنا جاری نہیں رکھنا چاہیے، اور خاموشی سے جاری رہنے والا کلائنٹ نشان کے سبز رہتے ہوئے کالے سوراخ میں بھیج سکتا ہے۔
دونوں ناکامیوں کا صارف کے نقطہ نظر سے موازنہ کریں۔ دوبارہ جڑنا چند سیکنڈ اور ایک نئی تصدیق کی قیمت ہے۔ پرانی ٹنل ایسی ایپلیکیشن کی قیمت ہے جو بغیر نقص کے لٹک جائے، جس کی وضاحت بہت مشکل ہے اور ”انٹرنیٹ خراب ہو گیا“ کے طور پر رپورٹ ہونے کا زیادہ امکان ہے۔
اِس کے نیچے پالیسی کا سوال بھی چھپا ہے۔ ایک راستہ کھونے اور دوسرا قائم کرنے کے درمیانی وقفے میں بعض کلائنٹ ٹریفک براہِ راست بھیجنے پر واپس آ جاتے ہیں۔ اِسے روکنا خودکار بحالی سے الگ کنٹرول ہے، اور کلائنٹ ایک میں اچھا اور دوسرے میں برا ہو سکتا ہے۔ فیصلہ کریں کہ آپ کو کس کی ضرورت ہے، اِس سے پہلے کہ کوئی ایک بھی ترتیب دیں۔
مشاہدہ شدہ ترتیب لکھیں
مفید رپورٹ واقعے کے ماخذ کا نام لیتی ہے: نئے پتے کے ساتھ طے شدہ نیٹ ورک کی تبدیلی، Wi-Fi سے سیلولر پر جانا، یا پتے کی کسی تبدیلی کے بغیر منتقلی۔ پھر بتاتی ہے کہ کلائنٹ نے کیا کیا، سرور کی طرف کے وقت نشان کے ساتھ، حافظے سے نہیں۔
اگر ٹنل منتقل ہوئی، یہ کہیں اور نئے اختتامی نقطوں کا خاندان نوٹ کریں۔ اگر دوبارہ قائم ہوئی، نوٹ کریں کہ تصدیق پہلی کوشش میں کامیاب ہوئی اور وقفہ کتنا رہا۔ یہ تین حقائق صحت مند موبائل ڈیزائن کو نیٹ ورکوں کے درمیان بھٹکنے والے کلائنٹ سے ممتاز کرتے ہیں۔
اور ”ٹاور کی تبدیلی“ کے جملے سے بچیں، الا یہ کہ آلے کا لاگ واقعی اُسے ثابت کرے۔ Android کے رابطہ کی دستاویزات اُن کال بیکس کی وضاحت کرتی ہیں جو دستیابی کو طے شدہ نیٹ ورک کی تبدیلی سے الگ کرتے ہیں، اور آپ کی رپورٹ کو وہی امتیاز درکار ہے۔ باقی سب گاڑی چلانے کی کہانی ہے۔