VPN وشبكة المنزل تستخدمان الشبكة الفرعية نفسها: تتبّع المسار أولاً
كلا المحوّلين يطالب بـ 192.168.1.0/24 ومسار واحد يفوز. تتبّع قائمة المحوّلات والمسار الفائز ومسار العودة قبل أن تعيد الترقيم أو تلوم DNS.
تتصل بشبكة VPN الخاصة بالمكتب، فيتحول رمز التطبيق إلى الأخضر، وتُحمَّل الشبكة الداخلية، ثم تتوقف الطابعة الواقعة على بعد مترين عن الاستجابة. المشاركة التي كانت تعمل هذا الصباح تنتهي مهلتها على الجهاز نفسه، ولا يذكر أي سجل شيئاً عن طابعة. ردّ الفعل الفوري هو DNS، لأن الاسم الذي لا يُحلَّل يبدو كاسم غير موجود، لكن المشكلة في العنوان: محوّلان يطالبان الآن بالشبكة 192.168.1.0/24 ولا يمكن إلا لمسار واحد أن يفوز بهذه البادئة. تتبّع الأمر بهذا الترتيب وسوف ترى أي محوّل أخذه قبل أن تغيّر أي شيء.
ابدأ من العَرَض لا من النفق
الدليل هو النطاق. إذا عملت الشبكة الداخلية وفشل كل جهاز محلي، فالنفق سليم والمسار المحلي ليس كذلك. وإذا عملت الأجهزة المحلية وفشلت الشبكة الداخلية، فالعكس هو الصحيح. وإذا عمل كل شيء عدا مضيف واحد، فأنت أمام عنوان واحد موجود على الجانبين.
سجّل عنواناً محلياً واحداً وعنواناً بعيداً واحداً قبل أن تلمس أي إعداد. عبارة «الطابعة» لا يمكن اختبارها، أما 192.168.1.40 فيمكن. هذه الخطوة وحدها تمنع أكثر ساعة مهدورة شيوعاً في هذه المشكلة، وهي إعادة كتابة إعدادات DNS من أجل قرار توجيه.
الخطوة 1: انظر إلى المحوّلين وكلاهما يطالب بالبادئة
افتح «اتصالات الشبكة» (ncpa.cpl) واقرأ المحوّلين جنباً إلى جنب. يُظهر محوّل Ethernet العنوان 192.168.1.50/24 مع البوابة 192.168.1.1. ويُظهر محوّل VPN العنوان 192.168.1.201/24 مدفوعاً من الخادم. كلاهما شرعي، وكلاهما يعتقد أن البادئة على الرابط، وسيحتفظ المكدس بمسار واحد لها.
يسرد Get-NetIPAddress -AddressFamily IPv4 العناوين، ويُظهر Get-NetIPInterface | Sort-Object InterfaceMetric الترتيب الذي سيستخدمها به المكدس. عمود المقياس ذلك هو القرار الذي أنت على وشك قراءته، لذا دوّن الأرقام بدلاً من محاولة تذكّرها.
أثبت خطأ نظرية DNS بتكلفة زهيدة: يعيد Resolve-DnsName printer.office.lan العنوان نفسه الذي أعاده أمس. الاسم قد حُلّ، ثم غادرت الحزمة عبر المحوّل الخطأ. دقيقتان هنا توفّران بعد ظهر كامل في إعدادات المحلّل.
الخطوة 2: اقرأ المسار الذي فاز فعلاً
يطبع Find-NetRoute -RemoteIPAddress 192.168.1.40 الواجهة والخطوة التالية والمصدر الذي سيستخدمه المكدس لذلك العنوان. اعتبر هذا الناتج هو الجواب لا مجرد تلميح. ويعطي route print -4 الجدول كاملاً حين تريد أن ترى أي إدخال خسر وبكم.
التخصيص يتغلب على النية. إن 192.168.0.0/25 المدفوعة تتغلب على 192.168.0.0/24 المحلية لأن البادئة أطول، لذا تغادر العناوين من 192.168.0.0 إلى 192.168.0.127 عبر النفق بينما يبقى النصف الأعلى محلياً. اختفاء نصف شبكة محلية دون رسالة خطأ سلوك صحيح لذلك الجدول.
يؤكد ذلك tracert -d 192.168.1.40 من خارج الجدول: إذا كانت الخطوة الأولى عنوان نفق بدلاً من موجّهك، فالمسار هو القصة كلها. وعلى Linux يكون السؤال نفسه ip route get 192.168.1.40، الذي يطبع عنوان المصدر والجهاز في سطر واحد. وحين يذكر الرد tun0، توقف عن النظر إلى المتصفح.
الخطوة 3: افحص مسار العودة قبل أن تلوم العميل
المسار الأمامي الصحيح يفشل مع ذلك إذا لم يستطع الجانب البعيد الرد. فعندما يُوصَل إلى شبكة محلية للعميل عبر النفق، يجب أن تعرف بوابة تلك الشبكة أين يعيش مجمّع النفق: ip route add 10.8.0.0/24 via 192.168.1.12 على ذلك الموجّه، مع push “route 192.168.1.0 255.255.255.0” من الخادم ليعرف العملاء المسار العكسي.
بدون الإدخال الأول يغادر الرد الهدف نحو بوابته الافتراضية، التي تمرّر عنواناً خاصاً إلى مزوّد الخدمة ثم تُسقطه. والعَرَض أحادي الاتجاه ويسهل إساءة قراءته: تظهر الطلبات على tun0 ولا تظهر الردود أبداً.
قاعدة masquerade على مضيف VPN تغني عن ذلك المسار الثابت: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. وهي تخفي أيضاً عناوين المصدر الحقيقية، ما يجعل كل سؤال سجل لاحق أصعب. والمضيف الهدف ذو البوابة الافتراضية الخاطئة ينتج الصمت نفسه، مع إعادة توجيه ICMP في أفضل الحالات وثقب أسود في الحالة العادية، ولهذا يخصّص التقاط الحزم على الطرفين.
الخطوة 4: اختر إصلاحاً يمكنك التعايش معه
تُستخدم خمسة إصلاحات لهذا، وهي ليست قابلة للتبادل. اختر حسب ما يجب أن يبقى قابلاً للوصول في الوقت نفسه، لا حسب أي أمر أقصر.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
المقاييس هي الخيار الرخيص والذي يلجأ إليه الناس أولاً. ينسحب التغيير على الواجهة، لذا يعمل ما دام النفق قائماً، ومكانه سكربت بجانب العميل لا صدفة أوامر ستنساها. ولا يمكنه منح وصول متزامن إلى العنوان نفسه على شبكتين، وهذا هو الحد الذي يدفع كل الآخرين إلى الجدول.
إعادة ترقيم شبكة المنزل إلى 10.10.0.0/24 هي الإصلاح النظيف: تجديد إيجار DHCP واحد إضافة إلى الحجوزات وقوائم الطباعة والعناوين المضمّنة التي تذكر النطاق القديم. أما إعادة ترقيم جانب المكتب فليست قرارك عادة. ويزيل IPv6 التصادم تماماً حين تحمله الشبكتان، ببادئة محلية فريدة من fd00::/8 بدلاً من شيء سهل التذكّر، لكن اختبر التطبيق عبر TCP لا بـ ping، لأن ICMP قد يعمل بينما لا تعمل الخدمة.
خيار الترجمة في OpenVPN نفسه هو الملاذ الأخير، يُدفع من الخادم إلى إدخال دليل خاص بالعميل. يأخذ أربعة وسطاء بعد اسم الخيار — الاتجاه والشبكة وقناع الشبكة والاسم البديل — والاسم البديل ليس اختيارياً: push "route 192.168.2.0 255.255.255.0" و push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". الشبكة وقناع الشبكة هما النطاق الذي يراه العميل (192.168.2.0/24)، والاسم البديل هو نطاق المكتب الحقيقي على جانب الخادم (192.168.1.0/24)، والمسار المدفوع هو ما يجعل ذلك النطاق المرئي قابلاً للوصول. حينها يظهر المكتب لذلك العميل تحت 192.168.2.x. وثّق التعيين في الملف الشخصي، وإلا فسيبحثه الشخص التالي كخطأ في التوجيه.
نشر خدمة واحدة هو النسخة الضيقة من الترجمة، ولا يحتاج خيار OpenVPN إطلاقاً. قاعدة DNAT على مضيف VPN تعيد نشر منفذ واحد، فتحتفظ الشبكة المحلية بعناوينها وتصل إلى الخدمة على عنوان المضيف الذي تعرفه. والتكلفة هي المعتادة: ترى الخدمة مضيف VPN كمصدر، فتتوقف سجلات كل عميل والاستعلامات العكسية عن معنى أي شيء. وهذا يغطي قائمة طباعة أو صفحة إدارة واحدة، لا مضيفين على الجانبين يصل كل منهما إلى الآخر.
ما لن يعمل بعد، وما يجب تسجيله
البث لا يعبر نفقاً موجّهاً. تعتمد DLNA وUPnP وتصفح NetBIOS وWake-on-LAN على بث أو بث متعدد لا يحمله جهاز tun، لذا لا مسار يصلح الاكتشاف. والجسر عبر dev tap يوسّع المقطع، ومعه بث DHCP وARP وكل حزمة اكتشاف أخرى؛ فضّل مسار مضيف أحادي البث مثل route 192.168.2.1 255.255.255.255 لعنوان الجانب المحلي من موجّه بعيد.
موجّهان يستخدمان 192.168.1.1 على المسار نفسه ينتميان إلى العائلة نفسها من المشكلة: العنوان المحلي يفوز دائماً، فتبقى صفحة الموجّه البعيد غير قابلة للوصول حتى تنتقل إحدى الشبكتين. وإضافة محوّل ثانٍ لا تغيّر شيئاً في أي من الحالتين.
سجّل الأدلة قبل أن تعدّل أي شيء: ip route get أو Find-NetRoute، وping -c 3 إلى العنوان المعني، وtraceroute، وtcpdump -ni tun0 icmp على العميل، ثم جدول التوجيه وعدادات NAT على الخادم. والـ ping الذي يعمل في اتجاه ويموت في الآخر يشير إلى مسار العودة لا إلى النفق، وهذا التمييز وحده يحدد أي الإصلاحات أعلاه تحتاجه فعلاً.