hostapd وOpenVPN على جهاز Pi واحد: من يملك المسار الافتراضي؟

تتصل الهواتف بنقطة الوصول، وتحصل على عنوان، ثم لا تصل إلى أي شيء على الإطلاق بمجرد أن يصعد النفق. يكون hostapd عادة سليماً في تلك الحالة، وكذلك OpenVPN؛ الذي ينكسر هو المسار الافتراضي، إما لأنه لم يكن موجوداً على الجسر قط أو لأن النفق استبدله دون ترك مسار إلى خادم VPN نفسه. يعيد هذا الدليل ذلك المسار إلى موضعه الصحيح ويثبت النتيجة من عميل لا من جهاز Pi. كل خطوة قابلة للتراجع، ولا شيء هنا يغيّر إعداد النفق حتى تعرف أي حركة تريدها داخله.

اجرد الواجهات قبل أن تعدّل أي شيء

التصميم المألوف يضع الراديو اللاسلكي والمنفذ السلكي داخل br0، ويشغّل hostapd على الجسر، ويوزّع عقود الإيجار من dnsmasq، بينما ينشئ عميل OpenVPN الواجهة tun0. ثم تبدو ثلاثة متطلبات منفصلة كأنها متطلب واحد: يحتاج عملاء نقطة الوصول إلى جهاز Pi كبوابة لهم، ويحتاج جهاز Pi إلى مسار إلى الإنترنت للوصول إلى خادمه، ويحتاج الجسر إلى عنوان بوابة يمكن لهؤلاء العملاء استخدامه.

اقرأ الحالة الحالية قبل تغييرها، لأن هذه الأوامر الأربعة تفصل مشكلة الواجهة عن مشكلة التوجيه.

ip -br addr
ip route show
ip link show master br0
bridge link show

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

أعطِ الجسر مساراً افتراضياً يخصه

غالباً ما يترك نظام Raspberry Pi OS الجسر بلا مسار افتراضي عندما وُجد الجسر بعد كتابة ملف الواجهة. المقطع ينتمي إلى /etc/dhcpcd.conf، وينبغي أن يسمّي الموجّه الأعلى بدلاً من جهاز Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

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

بعد systemctl restart dhcpcd يجب أن يسرد ip route show default الواجهة br0 مرة واحدة وبلا تكرار من المنفذ السلكي. تحقق من الاستعلام لا من الجدول، لأن إدخالاً قديماً قد يجلس بجانب إدخال فائز: يجب أن يسمّي ip -4 route get 203.0.113.10 الواجهة br0. يأتي ذلك العنوان من نطاق التوثيق TEST-NET-3، لذا لا يمكنه التصادم مع خادم حقيقي أثناء قراءتك هذا.

أوقف النفق عن اختطاف المسار إلى خادمه

عميل OpenVPN الذي يقبل redirect-gateway يستولي على المسار الافتراضي ويوجّهه إلى النفق. هذا صحيح عندما يجب أن يستخدم كل عميل نقطة وصول شبكة VPN، وخاطئ عندما يجب أن تستخدم بعض الوجهات فقط. على أي حال، لا يجوز أن تسير وصلة جهاز Pi نفسه إلى الخادم داخل النفق الذي لا يزال يبنيه. يضيف OpenVPN مسار مضيف إلى الطرف البعيد عبر البوابة الأصلية عندما يعيد توجيه المسار الافتراضي، وهذا بالضبط السلوك الذي يبقي النقل حياً؛ وإذا غاب ذلك المسار، ينهار النفق بمجرد أن يثبت.

مقارنة سريعة لمسار النقل ذلك قبل الاتصال وبعده تستحق الثواني العشر. يجب أن يسمّي ip -4 route get 203.0.113.10 جهاز الطبقة السفلى في الحالتين، مع تحرك القياس فقط. وإذا سمّى tun0 بعد صعود النفق، فلم يُثبّت مسار المضيف قط وستفشل إعادة الاتصال التالية.

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

قرّر مسألة إعادة التوجيه و NAT

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

قاعدة NAT هي الطريق المختصر الذي يعمل عندما لا يقبل الخادم بادئة نقطة الوصول، على حساب ظهور كل عميل كعنوان نفق جهاز Pi في سجلات الطرف البعيد. توجيه البادئة دون NAT يبقي العناوين مرئية ويعتمد على مسار عودة إلى 192.168.50.0/24 في الجانب المنزلي.

اكتب الاختيار بجانب قواعد الجدار الناري، لأن قاعدة NAT غير المرئية في التصميم تصبح غير قابلة للتفسير بعد ستة أشهر. أبقِ IPv6 في القرار نفسه؛ فمسار IPv4 عامل بجانب مسار IPv6 معطوب يظل يُقرأ كنصف معطوب في المتصفح.

تحقّق من عميل ثم تراجع بنظافة

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

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

ثم تأكد من أن جهاز Pi لا يزال يملك مساره الخاص إلى الخارج: يجب أن يسمّي ip route get 203.0.113.10 جهاز الطبقة السفلى، ويجب أن يستجيب ping -c 3 -I br0 203.0.113.10 إذا كان الخادم يسمح بـ ICMP. إذا نجحت خطوتا العميل الأوليان وفشلت الثالثة، فالخلل في إعادة التوجيه أو NAT. وإذا فشلت الخطوة الثانية، فالجسر أو DHCP لا يزالان غير مكتملين.

التراجع تعديل ملف واحد وأمران: أزل المقطع، وأعد تشغيل dhcpcd، واستبدل المسار الافتراضي صراحةً بـ ip route replace default via 192.168.50.1 dev br0. افعل ذلك قبل إغلاق نافذة الصيانة لا بعدها، لأن جهاز Pi فقد مساره الافتراضي يصبح غير قابل للوصول من الشبكة التي ستستخدمها لإصلاحه.