لماذا ينقطع اتصال VPN عند تغيّر شبكة Wi-Fi أو عند توصيل Ethernet
'معرّف SSID جديد، وانتقال بين نقاط وصول، وكابل يُوصَل: ثلاثة أشياء تكسر النفق في ثلاثة مواضع مختلفة. افحص عنوان المصدر، ثم المسار، ثم البروتوكول.'
يُبلَّغ عن أمرين كعطل واحد: الحاسوب انتقل إلى شبكة Wi-Fi أخرى، أو أُوصِل كابل بينما بقي Wi-Fi يعمل. العميل ما زال يقول إنه متصل، والأيقونة تبدو سليمة، والنفق لا ينقل شيئًا. في العمق، لا يمكن أن تتغيّر إلا ثلاث قطع من الحالة - الوصلة، والعنوان المحلي، والمسار الافتراضي - وأي واحدة تحرّكت هي التي تحدّد إن كان النفق يستعيد نفسه بنفسه أم يحتاج إلى إعادة اتصال. أفحصها بهذا الترتيب، لأن تغيير إعدادات الحساب لم يصلح أيًّا منها قط.
الوصلة والعنوان والمسار تتحرّك باستقلال
التنقّل بين نقاط الوصول في الشبكة نفسها حدث على مستوى L2 عادةً. تعيد الراديوية الارتباط، وتحتفظ الواجهة بعنوانها وبوّابتها، ولا يتغيّر شيء يعتمد عليه النفق، ولهذا يمرّ المشي في مكتب كبير أحيانًا بلا ملاحظة. الانضمام إلى SSID مختلف ليس كذلك: قد تهبط الواجهة القديمة، ويمنح DHCP عنوانًا جديدًا وبوّابة جديدة ومُحلِّلات جديدة، ويتوقف وجود التدفّق الخارجي الذي كان النفق يستخدمه.
يضيف Ethernet شكلًا ثالثًا. شبكة Wi-Fi لا تسقط أبدًا، فلا يُطلق أي حدث وصلة إطلاقًا، ومع ذلك تظهر الواجهة السلكية بعنوانها الخاص وغالبًا تفوز بالمسار الافتراضي في المقياس. يستمر النفق في العمل عبر مسار لم يعد مفضّلًا، أو يُبقي العميل مقبسه مثبَّتًا على الشبكة اللاسلكية التي بدأ عليها. الاثنان يبدوان متطابقين من المتصفح: تتوقف الصفحات في اللحظة التي يستقر فيها الكابل.
إذن السؤال الأول ليس هل تغيّرت Wi-Fi. بل هل تغيّر العنوان الذي أنت مرتبط به، أو المسار إلى نقطة النهاية، أثناء عمل النفق.
المقبس الخارجي مثبَّت على عنوان اختفى للتوّ
كل نفق هو تدفّق خارجي: عنوان محلي ومنفذ يتحدثان إلى عنوان الخادم ومنفذه. على Linux ذلك مقبس UDP مرتبط بالمصدر القديم؛ وعند إزالة الواجهة التي تحمل العنوان، تفشل الإرسالات بـ EADDRNOTAVAIL أو تخرج عبر الواجهة الجديدة بمصدر لم يره الخادم قط.
الجانب البعيد يحتفظ بمثبّته الخاص. تُعرَّف SA الخاصة بـ IKEv2 من دون MOBIKE بزوج العناوين، وجلسة 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 يرسل حزمة من 1500 بايت مع تعيين DF؛ الصمت يعني أن المسار أصغر مما افترضت.
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 على المسار، واحفظ سياقي الشبكة في التقرير حتى يقارنهما الشخص التالي.