نقطة اتصال VPN جسرية: أي مسار افتراضي يستخدم الهاتف؟
المسار الافتراضي في Pi ليس بوابة الهاتف. افصل القرارين، وأبقِ الوصلة الصاعدة خارج الجسر، واختبر الإيجار قبل النفق.
الهاتف المتصل بنقطة الاتصال الجسرية يحصل على عنوانه وبوابته من مصدر ما، وهذا ليس المسار الافتراضي في Pi. تغيير المسار الافتراضي في Pi يغيّر الوجهة التي يرسل إليها Pi حركة المرور الخاصة به. أما الهاتف فيواصل استخدام البوابة التي أُبلغ بها، وعندما تكون تلك البوابة على الشبكة المحلية البعيدة فإن إطاره يعبر الجسر ببساطة. مستهلكان، قراران. وفصل القرارين يفسّر معظم التقارير عن نقطة اتصال بلا إنترنت بينما Pi نفسه سليم.
جهازان، قراران مختلفان للبوابة
لدى Pi حزمة IP ومسار افتراضي خاص به. ولدى الهاتف حزمة IP ومسار افتراضي خاص به.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
هذا الجدول هو النموذج كله. بوابة الهاتف عنوان على الشبكة المحلية البعيدة، وإطاره يُمرَّر عند الطبقة 2 نحو ذلك الموجه. أما المسار الافتراضي في Pi فيخص النقل الخارجي الخاص بـ Pi، الذي عليه الوصول إلى نظير VPN عبر وصلة السفر الصاعدة.
الجسر يمرّر الإطارات ولا يوجّه الحزم
جسر Linux يمرّر إطارات Ethernet حسب عنوان MAC الوجهة، وهذا كل ما يفعله بين منافذه. إطار الهاتف الموجّه إلى MAC الموجه البعيد يُحوَّل إلى منفذ TAP ويعبر النفق دون أن يمس جدول التوجيه في Pi. لهذا يمكن أن يبقى الهاتف عاملاً مع مسار افتراضي معطوب في Pi، ولهذا لا يستطيع مسار صحيح إصلاح هاتف أُعطي بوابة خاطئة.
TAP يحمل إطارات Ethernet ويمكن أن يكون منفذ جسر. TUN يحمل حزم IP ولا يمكنه ذلك. إذا استبدل تصميمك أحدهما بالآخر، فالجسر ليس جسراً وباقي هذا لا ينطبق.
حدّد من يوزّع إيجار الهاتف
الخيار 3 في DHCP هو خيار الموجه، ويخبر العميل بأي بوابة يستخدم لشبكته الفرعية. عندما يكون خادم DHCP في الشبكة المحلية البعيدة هو الموزّع الوحيد، يحصل الهاتف على بوابة بعيدة ويكون التصميم متسقاً. أما إذا أجاب شيء آخر على جانب السفر أولاً، فيحصل الهاتف على بوابة محلية، وتخرج حركته إلى الإنترنت عبر وصلة السفر الصاعدة، ولا يكون لحركته إلى الشبكة البعيدة أي مسار إطلاقاً.
شغّل موزّعاً واحداً لذلك النطاق العريض، وسجّل ما يوزّعه.
Pi حالة منفصلة حتى عندما يأخذ عنواناً من الإيجار نفسه. قرّر عمداً ما إذا كان ينبغي أن يثبّت المسارات التي يعرضها الإيجار، لأن مساراً افتراضياً بعيداً مستورداً قد يجرّ نقل VPN الخاص بـ Pi إلى النفق الذي يحاول إبقاءه حياً. مع systemd-networkd يكون ذلك القرار UseRoutes= ضمن قسم DHCP؛ ومع dhclient يكون خيار routers في قائمة الطلب.
أبقِ الوصلة الصاعدة خارج الشبكة المحلية الجسرية
الواجهة التي تحمل اتصال VPN الخارجي في Pi يجب ألا تصبح منفذ جسر. إن حدث ذلك، يُحوَّل النقل المشفّر إلى الشبكة المحلية الموسّعة وينتهي النفق بحمل حزمه الخارجية، وهو ما يفشل بطريقة تشبه فقدان الحزم أكثر من الحلقة. أبقِ قدرة AP ودعم الجسر صريحين أيضاً. الواجهة اللاسلكية في وضع المحطة لا يمكنها عادة أن تكون منفذ جسر، لأن ترويسة 802.11 لا تتسع لعنوان MAC الثاني الذي يحتاجه الجسر.
عرّف نطاق البث الموسّع، وخطة عناوين واحدة، وترشيح الإطارات الذي تريده فعلاً. السماح لمستمع VPN على Pi لا يمنح كل عميل جسري الوصول إلى خدمات إدارة Pi. فهذه قواعد منفصلة، والتعامل معها كقاعدة واحدة هو كيف تتحول نقطة الاتصال بهدوء إلى باب مفتوح.
اختبر الأمور الأربعة كلٌّ على حدة عند حدوث عطل
عندما لا يستطيع الهاتف الوصول إلى الشبكة المحلية البعيدة، تفصل أربع ملاحظات الأسباب. نفّذها بهذا الترتيب وتوقف عند أول فشل.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpابدأ بالإيجار: هل يحمل الهاتف عنواناً وبوابة على الشبكة الفرعية البعيدة؟ ثم انظر إلى الجسر، وتأكد من أن منفذ AP ومنفذ TAP يمرران معاً. ثم اقرأ جدول الجيران، لأن مدخلاً غير محلول للموجه البعيد يعني أن الإطارات تغادر ولا شيء يجيب. وأخيراً راقب الإطارات على الجسر بينما يرسل الهاتف ping، وهذا يخبرك هل العطل تحت IP أصلاً.
سجّل أي جهاز يملك كل مسار افتراضي عند الانتهاء. سطر واحد من التوثيق يحوّل الخروج المحلي مقابل البعيد إلى قرار عميل مدروس، ومرجع الجسر يستحق أن يُحفظ بجانبه.