شبكة VPN على الراوتر تعمل لكن أجهزة الشبكة المحلية بلا إنترنت

تقول الحالة إن النفق قائم، ومتصفح على الراوتر نفسه يحمّل الصفحات، وكل جهاز خلفه لا يزال ينتهي إلى مهلة. هذا المزيج يحصر المشكلة في طبقة لا تذكرها معظم أدلة VPN: الراوتر ليس المضيف الوحيد الذي تحتاج حزمه إلى عبور النفق. فالحركة المتولدة محليًا والحركة المعاد توجيهها تسلكان مسارين مختلفين عبر الصندوق نفسه. اختبر من جهاز عميل وستكف الفروق عن أن تكون نظرية.

اقرأ العطل من مضيف على الشبكة المحلية

ابدأ من الجهاز الذي يفشل، لأن تشغيل تشخيص على الراوتر يجيب عن سؤال مختلف. تأكد من أن البوابة الافتراضية للعميل هي هذا الراوتر، وسجّل عنوان مصدره وشبكته الفرعية، ثم انظر إلى ما يخرج من واجهة النفق في الراوتر.

إذا كان عنوان العميل يُترجم، فإن الطرف البعيد يرى عنوان النفق، ويبدو كل شيء سليمًا من هناك بينما يظل العميل فاشلًا. وإذا لم يُترجم، فيجب أن يعرف الطرف البعيد مسارًا يعود إلى شبكة العميل الفرعية، وكثير من البوابات لا يملك هذا المسار افتراضيًا. وفي الحالتين لا يهم نجاح الراوتر نفسه، لأن حزمه تولدت محليًا ولم تعبر مسار إعادة التوجيه أبدًا.

الحركة المحلية والحركة المعاد توجيهها مختلفتان

يعامل لينكس ومعظم برامج الراوتر الثابتة الحزم التي ينشئها الصندوق نفسه معاملة مختلفة عن الحزم التي تمر عبره. سلسلة الإخراج ترى النوع الأول، وسلسلة إعادة التوجيه ترى الثاني، بينما السياسة المضبوطة لحركة الراوتر نفسه قد تترك إعادة التوجيه دون تغيير.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

تحقق من أن إعادة التوجيه مفعلة أصلًا، ثم اقرأ سلسلة إعادة التوجيه بدلًا من سلسلة الإخراج. القاعدة التي تسمح بالاتصال الخارجي المشفر ليست قاعدة تسمح بتمرير الحزم المفكوكة التشفير، والخلط بين الاثنين ينتج هذه الأعراض بالضبط. كون النفق قائمًا يثبت الأول فقط.

يجب أن يوجد مسار العودة أيضًا

ترجمة المصدر تحدد ما إذا كان مسار العودة مطلوبًا. مع التمويه على واجهة النفق، تعود الردود إلى عنوان النفق ويترجمها الراوتر عكسيًا. وبدونه تحتاج البوابة البعيدة إلى مسار صريح إلى شبكة العميل الفرعية، وإلى سياسة تسمح بذلك الاتجاه.

سجّل أي التصميمين يستخدمه النشر قبل تغيير أي شيء، لأن الإصلاحات تشير في اتجاهين متعاكسين. إضافة الترجمة تخفي مسار عودة مفقودًا وتكسر التطبيقات التي تحتاج عنوان المصدر الأصلي. وإضافة مسار عودة بلا ترجمة تفشل بصمت عندما تُسقط جدار الحماية البعيد المصدر غير المألوف. اختر واحدًا، ووثّقه، واجعل الطرف الآخر يطابقه.

DNS العميل ينتمي إلى المراجعة نفسها. يمكن لمحلل الراوتر أن يجيب بينما عميل موجه إلى خادم مختلف لا يحصل على شيء إطلاقًا.

تحقق من تدفق مسموح واحد وتدفق مرفوض واحد

بعد التصحيح، اختبر اتصالًا جديدًا من عميل بدلًا من جلسة قائمة على الراوتر. ثم تأكد من أن مقطعًا لا ينبغي أن يستخدم النفق لا يزال لا يستخدمه.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

افحص عنوان المصدر المرصود عند الطرف البعيد، لأنه يخبرك أي تصميم يعمل فعليًا. وتحقق من استعلام اسم إلى جانب العنوان، لأن سلوك المحلل مسار منفصل عبر الصندوق نفسه.

أبقِ القواعد محصورة في شبكات العملاء التي تحتاج النفق، وقاوم إغراء تعطيل مرشح إعادة التوجيه لنجاح اختبار واحد. ذلك التغيير يصلح الاختبار ويزيل الحد الذي يفترض أن يوفره النفق. اكتب عنوان المصدر وقرار الترجمة ومسار العودة في ملاحظة واحدة، مع تاريخ.