بوابة VPN على Raspberry Pi: منفذ شبكة واحد أم منفذ عميل مخصص
يمكن لمنفذ واحد على Raspberry Pi أن يخدم عملاء مختارين، أو أن يحصر منفذ ثانٍ الأجهزة في الداخل. اختر التصميم حسب العزل وسياسة الرجوع ومن يملك DNS.
لديك Raspberry Pi واحدة، وملف تعريف VPN صادر عامل، وجهازان يجب أن يصلا إلى الإنترنت عبرها. السؤال الذي يحسم البناء كله ليس أي دليل تتبع، بل مقدار العزل الذي تحتاجه. منفذ واحد يجعل Raspberry Pi تجلس إلى جانب تلك الأجهزة على شبكة LAN الخاصة بالموجه وتعمل كبوابة إضافية؛ ومنفذ ثانٍ يتيح لك وضعها في مقطع يكون فيه Raspberry Pi المخرج الوحيد. وكل ما يأتي بعد هذا الاختيار — DHCP، ونطاق الجدار الناري، وDNS، وحالة الانقطاع — يتبع منه.
أين يختلف التصميمان فعلاً
كلا التصميمين يوجّه الحزم. الفرق هو من يقف أيضاً على السلك، وما يحدث عندما تكون سياستك خاطئة.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
العزل هو المحور الحقيقي. التصميم A استشاري: جهاز يتجاهل البوابة التي يمنحها DHCP ويختار الموجه يظل يعمل، دون تشفير. التصميم B مفروض بالطوبولوجيا، لأنه لا يوجد قفزة تالية أخرى ليختارها.
التصميم A: Raspberry Pi كبوابة إضافية على شبكة LAN القائمة
لنفترض أن موجه مزود الخدمة هو 192.168.50.1، وأن Raspberry Pi هو 192.168.50.2، وأن العملاء المختارين يشيرون إلى Raspberry Pi. المهم أن تدفقي حزم مختلفين يتشاركان كابلاً واحداً. تصل حزمة العميل الداخلية إلى Raspberry Pi ويجب أن تغادر عبر النفق؛ وحزمة Raspberry Pi المشفرة إلى نظير VPN يجب أن تغادر عبر الكابل نفسه إلى الموجه. وهي تسير في اتجاهين متعاكسين على الواجهة نفسها وتحتاج إلى معالجة مختلفة.
امنح Raspberry Pi عنوانه عبر مدير الشبكة المثبت بدلاً من وصفة قديمة لملف واجهة تتخاصم معه على الجهاز. ثم اضبط العملاء: بوابة ثابتة على جهاز واحد، أو حجز DHCP يمنح 192.168.50.2 كموجه. لا تغيّر نطاق DHCP الكامل للموجه من أجل جهازين، ولا تفترض أن العميل يحترم هذا الخيار — تحقق منه.
الضعف بنيوي وليس قابلاً للإصلاح. أي عميل على ذلك المقطع يمكنه الإشارة إلى 192.168.50.1 والمغادرة دون تشفير، وأي جهاز له واجهة ثانية أو راديو خلوي يخرج من مسار فرضك تماماً. وإذا كانت تلك الجملة غير مقبولة للجهاز المعني، فلديك جوابك بالفعل: استخدم التصميم B.
التصميم B: منفذ مخصص يحصر الأجهزة في الداخل
هنا يحتفظ Raspberry Pi بـ 192.168.50.2 على الوصلة الصاعدة مع البوابة 192.168.50.1، ويأخذ 10.20.0.1/24 على واجهة ثانية للأجهزة الموصولة. أصبح Raspberry Pi الآن موجهًا بشبكتين، وللمقطع الموصول مخرج واحد فقط.
افحص النطاق مقابل كل شيء آخر قبل أن تلتزم: الشبكة الفرعية الخاصة بالنفق، وبادئات أخرى بين المواقع، وأي شيء يمكن الوصول إليه عبر VPN. نطاق 10.20.0.0/24 يتصادم مع شبكة LAN بعيدة ينتج عنه نوع النتيجة النصف عاملة التي تستغرق أمسية كاملة للتشخيص. وإذا كان المنفذ الثاني محول USB، فتأكد من أنه مدعوم وثبّت اسمه في مدير الشبكة حتى لا يحرّك إعادة الترتيب بعد إعادة التشغيل عنوان LAN الخاص بك.
شغّل مستمع DHCP على تلك الواجهة فقط. خادم يجيب على الوصلة الصاعدة ينافس موجه مزود الخدمة ويمنح عناوين مقطعك لبقية المنزل. اربطه بواجهة LAN، وقيّده بالنطاق المعلن، وأبقِ عنوان Raspberry Pi نفسه خارج التجمع.
إعادة التوجيه والترجمة وقاعدة الإغلاق عند الفشل
أربعة أشياء كثيراً ما توصف كشيء واحد وليست كذلك. تمكين إعادة التوجيه (net.ipv4.ip_forward=1) يخبر النواة فقط أنها قد تنقل الحزم بين الواجهات؛ وهو لا يسمح بشيء بحد ذاته ولا يضمن أي مسار. اختيار المخرج قرار توجيه. والسماح بالحزمة قرار سياسة في سلسلة forward. وإعادة كتابة مصدرها قرار postrouting. والبناء الذي يفعل الأول فقط ينتج Raspberry Pi تمرر بحماس حركة العملاء خارج الوصلة الصاعدة.
احصر الإذن في المصادر التي قصدتها والواجهة التي يجب أن تستخدمها الحركة، وأدرج مسار العودة والوجهات التي يحتاجها Raspberry Pi نفسه. ثم ترجم على مخرج النفق إذا كان المزود لا يعيد توجيه بادئة LAN الخاصة بك إليك. أما دليل nftables فيتعامل مع إعادة التوجيه والإخراج المحلي وترجمة المصدر كعمليات منفصلة، وهو النموذج الذهني الصحيح هنا.
الفشل الشائع هو قاعدة masquerade عريضة على الواجهة الفيزيائية. عندئذ تصل الحركة إلى الإنترنت عبر مسار مزود الخدمة بينما تبدو، من جانب العميل، تماماً مثل VPN عامل. وهذا لا يثبت شيئاً. أبقِ الترجمة مرتبطة بالمخرج المعلن، وأبقِ قواعدك في الجدار الناري الذي يستخدمه المضيف أصلاً بدلاً من إضافة مجموعة قواعد منافسة تمسح سلسلة postrouting مشتركة.
ثم تعامل مع غياب النفق. ملف تعريف عميل يثبت مساراً افتراضياً عريضاً يعني أيضاً أنه عندما يسقط النفق يمكن أن يعود الافتراضي العادي فتعود حركة العميل بهدوء إلى الوصلة الصاعدة. وحيثما كان الرجوع إلى نص مكشوف غير مقبول، يجب أن تمنع سياسة forward حركة العميل إلى الوصلة الصاعدة صراحةً، في الحالة التي يكون فيها مسار VPN قد اختفى. اكتب ذلك كقاعدة رفض، لا كافتراض. فنقل Raspberry Pi المشفر إلى نظير VPN تدفق local-output منفصل ويجب أن يبقى مسموحاً، وإلا فلا يمكن للنفق أن يعود أبداً.
DNS وIPv6 يحتاجان إلى جواب خاص بهما
إذا استخدم العملاء Raspberry Pi كمحلّل، فإنهم يصلون إلى مستمع محلي ويبدأ Raspberry Pi استعلاماً جديداً. ذلك الاستعلام الصاعد يتبع مسار Raspberry Pi نفسه، لا قاعدة forward التي كتبتها للعملاء، لذا فإن مسار عميل مخصص للنفق مع محلّل يخرج مباشرة هو تسريب بلا رسالة خطأ. قرّر عن قصد: محلّل يُصل إليه عبر النفق، أو محلّل محلي تقبله مباشراً، واجعل سياسة إخراج Raspberry Pi نفسه مطابقة لذلك القرار.
IPv6 منفصل مرة أخرى. قاعدة forward للـ IPv4 لا تقيّد شيئاً بشأن IPv6، وإعلانات الموجه على الوصلة الصاعدة يمكن أن تمنح Raspberry Pi، ومن خلاله المقطع الموصول، افتراضياً ثانياً يتجاوز سياستك. إما أن تمنح IPv6 مساراً محمياً خاصاً به على المبدأ نفسه، أو تقيّده صراحةً على مقطع العملاء وتقول ذلك.
اختبر الحدود قبل أن تثق بها
لا تقبل التصميم إلا بعد أربعة فحوص منفصلة، لأن الاختبار الواحد المغري — فتح متصفح على عميل واحد — ينجح في عدة حالات معطلة.
تأكد من أن عميلاً حقيقياً واحداً يصل إلى الإنترنت عبر النفق، ثم تأكد من أن العميل نفسه لا يستطيع الوصول إلى الإنترنت والنفق متوقف. تأكد من أن تحليل DNS يعمل وأن الاستعلام يغادر حيث قصدت. تأكد من أن نقل Raspberry Pi نفسه لا يزال يعمل بعد إعادة تشغيل النفق، وأن الاستعادة لا تتطلب إعادة تشغيل الجهاز. وأخيراً، افحص جهازاً لم تختره: تحت التصميم A يجب أن يظل يعمل طبيعياً، وتحت التصميم B يجب ألا يكون موجوداً على ذلك المقطع إطلاقاً.
- منفذان وقاعدة رفض يمنحان الفرض؛ ومنفذ واحد وخيار DHCP يمنحان النصيحة.
- الترجمة على الواجهة الخاطئة تبدو نجاحاً وليست كذلك.
- حركة Raspberry Pi نفسه وDNS وIPv6 كلها تحتاج قراراً، لا استنتاجاً.