آپ کا VPN کیوں منقطع ہوتا ہے جب Wi-Fi بدلے یا Ethernet لگے
'نیا SSID، رسائی نکات کے درمیان روئمنگ اور لگا ہوا کیبل ٹنل کو تین مختلف جگہوں پر توڑ دیتے ہیں۔ ماخذ پتہ، پھر راستہ، پھر پروٹوکول چیک کریں۔'
دو چیزیں ایک ہی خرابی کے طور پر رپورٹ ہوتی ہیں: لیپ ٹاپ دوسرے Wi-Fi نیٹ ورک پر چلا گیا، یا Wi-Fi چلتے رہنے کے دوران کیبل لگ گیا۔ کلائنٹ اب بھی کہتا ہے منسلک ہے، آئیکن صحت مند لگتا ہے، اور ٹنل کچھ نہیں لے جاتی۔ اندر صرف تین حالت کے ٹکڑے حرکت کر سکتے ہیں - لنک، مقامی پتہ، طے شدہ راستہ - اور کون سا ہلا، یہی طے کرتا ہے کہ ٹنل خود بحال ہو گی یا دوبارہ جڑنا پڑے گا۔ میں انہیں اسی ترتیب سے دیکھتا ہوں، کیونکہ اکاؤنٹ کی ترتیبات بدلنے سے ان میں سے کوئی بھی کبھی درست نہیں ہوا۔
لنک، پتہ اور راستہ آزادانہ حرکت کرتے ہیں
ایک ہی نیٹ ورک کے رسائی نکات کے درمیان روئمنگ عام طور پر L2 واقعہ ہے۔ ریڈیو دوبارہ منسلک ہوتا ہے، انٹرفیس اپنا پتہ اور گیٹ وے برقرار رکھتا ہے، اور ٹنل جس چیز پر منحصر ہے اس میں کچھ نہیں بدلتا، اسی لیے بڑے دفتر میں چلنا بعض اوقات توجہ میں نہیں آتا۔ دوسرے SSID میں شامل ہونا ایسا نہیں: پرانا انٹرفیس نیچے جا سکتا ہے، DHCP نیا پتہ، نیا گیٹ وے اور نئے حل کنندہ دیتا ہے، اور ٹنل جو بیرونی بہاؤ استعمال کر رہی تھی وہ وجود میں نہیں رہتا۔
Ethernet تیسری شکل شامل کرتا ہے۔ Wi-Fi کبھی نہیں گرتا، اس لیے کوئی لنک واقعہ سرے سے پیش نہیں آتا، لیکن تار والا انٹرفیس اپنے پتے کے ساتھ نمودار ہوتا ہے اور اکثر میٹرک پر طے شدہ راستہ جیت لیتا ہے۔ ٹنل ایسے راستے پر چلتی رہتی ہے جو اب پسندیدہ نہیں، یا کلائنٹ اپنا ساکٹ اسی وائرلیس نیٹ ورک سے باندھے رکھتا ہے جہاں سے شروع ہوا تھا۔ براؤزر سے دونوں ایک جیسے دکھتے ہیں: کیبل بیٹھتے ہی صفحے رک جاتے ہیں۔
لہٰذا پہلا سوال یہ نہیں کہ Wi-Fi بدلا یا نہیں۔ سوال یہ ہے کہ جس پتے سے آپ بندھے ہیں، یا آخری مقام تک کا راستہ، ٹنل چلنے کے دوران بدلا یا نہیں۔
بیرونی ساکٹ ایسے پتے سے بندھی ہوئی ہے جو ابھی غائب ہوا
ہر ٹنل ایک بیرونی بہاؤ ہے: مقامی پتہ اور پورٹ سرور کے پتے اور پورٹ سے بات کرتے ہیں۔ Linux پر یہ پرانے ماخذ سے بندھا UDP ساکٹ ہے؛ جب پتہ رکھنے والا انٹرفیس ہٹایا جاتا ہے، تو ارسالگیاں یا تو EADDRNOTAVAIL کے ساتھ ناکام ہوتی ہیں یا نئے انٹرفیس سے ایسے ماخذ کے ساتھ نکلتی ہیں جو سرور نے کبھی نہیں دیکھا۔
دوسرا سرا اپنی بندش رکھتا ہے۔ MOBIKE کے بغیر IKEv2 SA پتوں کے جوڑے سے پہچانی جاتی ہے، اور ایک OpenVPN سیشن اس ہم منصب پتے سے بندھا ہوتا ہے جو اس نے سیکھا، اور NAT نقشہ اس نجی پتے، پورٹ اور عوامی پتے کا ہوتا ہے جنہوں نے اسے بنایا۔ کسی دوسرے NAT کے پیچھے جائیں اور ہر جواب ایسے نقشے پر جاتا ہے جو اب موجود نہیں۔ آپ کی مشین پر کچھ بھی غلط ترتیب نہیں دیا گیا؛ پانچہ اس نیٹ ورک کی طرف اشارہ کرتا ہے جو آپ نے چھوڑا۔
نظریہ بنانے سے پہلے حالت پڑھیں:
ss -unpدکھاتا ہے کہ ہر ٹنل ساکٹ حقیقت میں کون سا مقامی پتہ اور پورٹ رکھتی ہے۔ip route get 203.0.113.10وہ ماخذ پتہ اور ڈیوائس چھاپتا ہے جو کرنل ابھی آخری مقام کے لیے استعمال کرے گا۔wg show wg0 endpoints،swanctl --list-sasیا کلائنٹ لاگ وہ ہم منصب پتہ دکھاتا ہے جس سے دوسرا سرا سمجھتا ہے کہ بات کر رہا ہے۔
اگر ساکٹ کا پتہ اور راستے کی تلاش مطابقت نہ رکھیں، تو آپ نے ٹوٹ پا لی، اور کوئی اسناد کی تبدیلی اسے نہیں چھوئے گی۔
نئے ماخذ پتے کے ساتھ ہر پروٹوکول کیا کرتا ہے
کلائنٹ تبدیلی کو مختلف درجوں میں جذب کرتے ہیں، اور جدول وہی ہے جسے میں کلائنٹ کنفیگریشن سے موازنہ کرتا ہوں، دوبارہ جڑنے کے رویے سے اندازہ لگانے کے بجائے۔
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard کا روئمنگ اصول صرف ایک سمت میں کام کرتا ہے: کلائنٹ کو پہلے نئے پتے سے بھیجنا ہوگا۔ پرانے انٹرفیس سے بندھا ساکٹ ایسا کبھی نہیں کرتا، اسی لیے ٹنل زندہ دکھ سکتی ہے جبکہ اس کا ہینڈ شیک ٹائمر پرانا ہو رہا ہو۔ پروٹوکول کی وضاحت آخری مقام کی تجدید کی شرط ٹھیک ٹھیک بتاتی ہے، اور کنفیگریشن بدلنے سے پہلے اسے پڑھنا لائق ہے۔
MOBIKE پر بات چیت ہوتی ہے، فرض نہیں کیا جاتا۔ اگر سرور یہ پیش نہ کرے، تو کلائنٹ کو دوبارہ قائم کرنا ہوگا، اور یہ وہ حقیقت ہے جو آپ SA فہرست یا لاگ سے تصدیق کرتے ہیں، کسی گھومتے پہیے سے اندازہ نہیں لگاتے۔
راستہ راستے کی ترجیح طے کرتی ہے، Wi-Fi آئیکن نہیں
جب دونوں انٹرفیس اوپر ہوں، کرنل میٹرک اور سابقہ کی لمبائی کے مطابق چنتا ہے۔ ip route show default امیدواروں کی فہرست دیتا ہے اور ip route get 203.0.113.10 ماخذ پتے سمیت اصل فیصلہ حل کرتا ہے۔ میٹرک 100 پر تار والا طے شدہ اور 600 پر وائرلیس کا مطلب ہے کہ آخری مقام کیبل بیٹھنے ہی کے لمحے ہل جاتا ہے، جبکہ پہلے ساکٹ کھولنے والی ہر ایپلیکیشن اپنا پرانا ماخذ رکھتی ہے۔
Windows بھی خودکار انٹرفیس میٹرک کے ساتھ یہی کرتا ہے، لنک کی رفتار سے متعصب۔ Get-NetRoute -DestinationPrefix 0.0.0.0/0 امیدواروں کو ترتیب دیتا ہے اور Find-NetRoute -RemoteIPAddress 203.0.113.10 وہ انٹرفیس اور ماخذ واپس کرتا ہے جو اسٹیک چنے گا۔ جو کلائنٹ اپنا بیرونی ساکٹ ایک انٹرفیس سے باندھتا ہے وہ میٹرک پلٹنے کے بعد بھی اسیے استعمال کرتا ہے؛ یہ بندھن کا فیصلہ ہے، روٹنگ کی خرابی نہیں۔
Android تقسیم کو نظر آنے والا بناتا ہے: ConnectivityManager دستیاب نیٹ ورک اور الگ طے شدہ کی اطلاع دیتا ہے، اور جو VPN ایپ ساکٹ کو Network آبجیکٹ سے باندھتی ہے وہ دوبارہ نہ باندھنے تک یہ بندش رکھتی ہے۔ macOS پر، scutil --nwi بنیادی انٹرفیس اور وہ ترتیب چھاپتا ہے جو نظام استعمال کرے گا۔
DNS، MTU اور IPv6 رابطے کے ساتھ حرکت کرتے ہیں
نیا رابطہ نئے حل کنندہ لاتا ہے۔ systemd-resolved کے ساتھ DNS فی لنک ہے، resolvectl status دکھاتا ہے کہ کون سا لنک کسی نام کا جواب دیتا ہے، اور مہمان نیٹ ورک جو اپنا حل کنندہ تقسیم کرتا ہے ٹنل کے دھکیلے DNS کو غیر استعمال شدہ چھوڑ سکتا ہے جب تک لنک دوبارہ ترجیحی نہ ہو۔ پکڑنے والا پورٹل اسے مزید بگاڑتا ہے: پہلی HTTPS درخواست کا جواب آخری مقام کے بجائے پورٹل دیتا ہے، اور کلائنٹ مردہ سرور درج کرتا ہے۔
راستے کا MTU بھی بدلتا ہے۔ Ethernet اور Wi-Fi عام طور پر 1500 بائٹ اٹھاتے ہیں، PPPoE 1492، اور موبائل لنک اکثر کم۔ چھوٹا MTU ورثے میں ملنے پر ٹنل بڑے پیکٹوں پر رک جاتی ہے جبکہ چھوٹی درخواستیں گزر جاتی ہیں، جسے آدھا ٹوٹا کنکشن پڑھا جاتا ہے۔ ping -M do -s 1472 203.0.113.10 DF لگا کر 1500 بائٹ کا پیکٹ بھیجتا ہے؛ خاموشی کا مطلب ہے کہ راستہ آپ کے اندازے سے چھوٹا ہے۔
IPv6 دوسرا نصف ہے۔ نیا سابقہ دینے والا نیٹ ورک دوہرے اسٹیک والے کلائنٹ کا ماخذ بدل دیتا ہے، اور صرف v4 والی ٹنل پالیسی آنے تک v6 ٹریفک کو باہر رکھتی ہے۔ ip -6 route show default اور ip -6 addr show جواب دیتے ہیں کہ نئے لنک کو v6 راستہ ہے بھی یا نہیں۔
بیان کرنے کے بجائے منتقلی دوبارہ پیدا کریں
ایک بے ضرر درخواست چنیں اور تبدیلی کے دونوں طرف وہی تین کمانڈ چلائیں: ip -br addr، ip route show default، ip route get 203.0.113.10۔ پھر دیکھیں کہ ٹنل اب بھی پیکٹ خارج کرتی ہے یا نہیں - tcpdump -ni any udp port 51820 WireGuard کے لیے یہ، باقی سب کے لیے موزوں پورٹ۔ پرانے ماخذ سے نکلنے والے پیکٹ بندھن کا مسئلہ بتاتے ہیں۔ نئے ماخذ سے بغیر جواب نکلنے والے پیکٹ دوسرے سرے یا درمیانی NAT کو ظاہر کرتے ہیں۔
یاد رکھیں کہ پہلی خرابی کے ساتھ کون سا واقعہ ملا لنک کا گرنا، پتے کی تبدیلی، یا طے شدہ راستے کی تبدیلی۔ یہ مختلف ذمہ داروں کی طرف اشارہ کرتے ہیں - وہ کلائنٹ جسے دوبارہ باندھنا ہے، وہ پتہ جو دوبارہ لینا ہے، یا وہ راستہ جو کنفیگریشن فائل کا ہے، مستقل بائی پاس قاعدے کا نہیں۔
درست ہوا کہنے سے پہلے تصدیق کریں کہ براہ راست ٹریفک کی روک خلاء کے دوران بھی قائم ہے اور نام نئے رابطے سے حل ہوتے ہیں۔ اگر تبدیلی کے بعد بھی کلائنٹ پرانا آخری مقام رکھتا ہے، تو پہلے روئمنگ یا float کی ترتیب درست کریں۔ اگر صحیح روئم کرتا ہے اور پھر بھی جواب نہیں ملتا، تو سرور کی ہم منصب شناخت اور راستے کے NAT کو دیکھیں، اور دونوں نیٹ ورک سیاق و سباق رپورٹ میں رکھیں تاکہ اگلا شخص موازنہ کر سکے۔