عملاء نقطة الاتصال على Raspberry Pi لا يصلون إلى شبكة المنزل عبر VPN من نوع TUN

يتصل عملاء Wi-Fi وEthernet المحليون بنقطة اتصال Pi، ويسحبون عنواناً من نطاق DHCP الخاص بها، ويحمّلون صفحات الإنترنت دون شكوى. ثم تنتهي مهلة هؤلاء العملاء أنفسهم عند فتح مشاركة ملفات أو واجهة ويب على شبكة المنزل، بينما يصل Pi نفسه إلى تلك الشبكة عبر النفق. لا شيء في طبقة اللاسلكي معطوب. ما ينقص هو عقد مُوجَّه: يجب حمل بادئة نقطة الاتصال داخل واجهة TUN، ويجب أن يعرف شيء ما في الجانب المنزلي كيف يرسل الردود إليها. يجب أن يوجد النصفان قبل أن تتمكن حزمة واحدة من إتمام الرحلة ذهاباً وإياباً.

ثلاثة ارتباطات بثلاث وظائف مختلفة

يجسر جسر Ethernet في Linux الإطارات حسب عنوان MAC الوجهة. OpenVPN في وضع TUN يحمل حزم IP وليس لديه طبقة MAC إطلاقاً، لذا فإن إضافة جسر محلي لا تُدخل النفق أبداً كمنفذ. وتوضح وثائق TUN/TAP في النواة هذا الفصل: جهاز TAP يبدو كواجهة Ethernet، وجهاز TUN لا يبدو كذلك. التصميم الذي يجسر منفذين محليين ثم يوجّه هو موجّه، أياً كانت أسماء الواجهات.

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

أبقِ المودم خارج جسر العملاء أيضاً. ارتباط PPP ليس جهاز Ethernet بملصق مختلف، ومنطق المسار الافتراضي الموثق في pppd يعمل بعد تفاوض IPCP ويسحب مساره عندما يسقط ذلك الرابط. ونسخ قالب DHCP وإعادة تسمية كل usb0 إلى ppp0 لا يثبت شيئاً عن البوابة أو المقياس أو دورة الحياة.

اختر البادئات قبل تحرير أي إعداد

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

المجموعة الأولى هي عنوان underlay الذي منحه الناقل للمودم؛ ويجب أن يبقى خارج كل خطة موجهة للعملاء. والثانية هي شبكة النفق الفرعية التي اختارها الخادم، وغالباً /24 خاصة به. والثالثة هي جسر نقطة الاتصال، والرابعة هي بادئة المنزل التي تريد الوصول إليها. في هذا الشرح تحصل نقطة الاتصال على 172.28.90.0/24 مع الجسر على 172.28.90.1، وتحتفظ شبكة خدمات المنزل بـ 192.168.77.0/24، وهو ما يتجنب الافتراضيين 192.168.1.0/24 و10.0.0.0/24 اللذين تأتي بهما موجّهات المستهلكين ونطاق الناقل 100.64.0.0/10.

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

وجّه كل اتجاه على الجانب الذي يملكه

يحتاج Pi إلى مسار لبادئة المنزل عبر النفق. والخوادم في وضع الخادم تدفع ذلك المسار عادةً، لذا تأكد أولاً من أن التمرير مفعّل وأن النواة تحل عنواناً منزلياً من tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

إذا كان ip route get لا يزال يبلّغ عن واجهة underlay، فتوقف هناك؛ لا شيء أبعد في المسار يمكنه إصلاح بحث خاطئ.

لا تملك أجهزة المنزل مساراً إلى 172.28.90.0/24، لذا تتبع ردودها البوابة الافتراضية وتموت عند الموجّه. يوجد إصلاحان مدعومان. إما أن تضيف مساراً ثابتاً على موجّه المنزل يوجّه بادئة نقطة الاتصال إلى عنوان LAN لخادم VPN، أو، عندما يكون الخادم نفسه هو البوابة، تسجّل بادئة العميل في جدول التوجيه الخاص بالخادم. في وضع تعدد العملاء في OpenVPN يحمل الدليل الخاص بالعميل ذلك الارتباط: ملف مسمّى بالاسم الشائع لشهادة العميل، يحتوي على iroute 172.28.90.0 255.255.255.0 بالإضافة إلى سطر route المطابق الذي يثبّته في نواة الخادم. والمسار المخمَّن في نواة الخادم ليس البيان نفسه الذي يخبر الخادم أي عميل يملك البادئة.

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

افتح التمرير دون التخمين في الجدار الناري

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

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

الترجمة خيار سياسة لا شرط. فترجمة المصدر NAT نحو شبكة المنزل تجعل كل عميل نقطة اتصال يبدو كعنوان نفق Pi، وهو ما يفقد الإسناد لكل عميل في سجلات المنزل ويكسر الخدمات التي تتوقع المصدر الأصلي. والتوجيه بدون NAT يبقي عناوين العملاء مرئية لكنه يعتمد على مسار العودة أعلاه. اختر واحداً وتعامل مع DNS وIPv6 بالطريقة نفسها، لأن مسار IPv4 العامل بجانب مسار IPv6 المعطوب يظل يُقرأ كنصف معطوب في المتصفح.

تحقق من الرحلة ذهاباً وإياباً، ثم اكسرها عمداً

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

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

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

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