مناطق Shorewall لمساري حزم OpenVPN
افصل نقل OpenVPN المشفَّر عن حركة العميل المفكوكة التشفير، وامنح النفق منطقته الخاصة، واسمح فقط بالخدمة الواحدة التي يحتاجها العميل.
يعبر تدفّقان من الحزم بوابة Shorewall تنهي OpenVPN، وواحد منهما فقط مشفَّر. الأول هو نقل العميل إلى مستمع VPN على الواجهة المواجهة للإنترنت. والثاني هو الطلب المفكوك التشفير الذي يغادر واجهة النفق نحو خادم مكتبي أو خدمة على البوابة. ارسم كلا التدفقين قبل تعديل السياسة، لأن قاعدة تفي بالأول لا تفعل شيئًا للثاني.
ارسم التدفقين قبل تعديل السياسة
اكتب التدفقين في صفوف تتضمن المصدر والوجهة والبروتوكول والمنفذ. في المسار الخارجي، المصدر هو العنوان العام للعميل والوجهة هي منفذ المستمع على البوابة؛ وتتعامل Shorewall مع ذلك كحركة من الإنترنت إلى الجدار الناري. وفي المسار الداخلي، المصدر هو نطاق عناوين النفق والوجهة هي الخدمة المعتمدة. وللصفين مالكَان مختلفان حتى عندما يديرهما مسؤول واحد.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
أضف صفًا فقط إذا كان الطلب ينتهي عند البوابة نفسها، مثل الوصول إلى المفسّر أو إلى الإدارة. فالخدمة على المضيف تتبع سياسة إدخال المضيف، لا مسار التمرير. وخلط الاثنين هو ما يجعل قاعدة نفق ضيقة تكشف واجهة إدارة.
عيّن منطقة النفق ونطاق الواجهة
تُعرَّف منطقة المستخدم المتنقل في /etc/shorewall/zones، وتُربط واجهة النفق في /etc/shorewall/interfaces، ويوصف الاتصال الخارجي في /etc/shorewall/tunnels. طابق صياغة الإصدار المثبَّت، لأن ترتيب الأعمدة وأسماء الخيارات تغيّرت بين الإصدارات الرئيسية. والمنفذ المذكور كمثال في الدليل ليس سببًا للسماح بمنفذ مختلف عن الذي يستمع عليه الخادم فعليًا. وTCP وUDP ليسا قابلين للتبادل لمجرد تطابق الأرقام.
يجمع الدليل الواجهات باستخدام tun+. وعلى مضيف فيه أكثر من نفق، قد تضع تلك العلامة البديلة شبكة VPN ثانية بمستوى ثقة مختلف في المنطقة نفسها. راجع النطاق مقابل الواجهات الموجودة فعلًا، وأبقِ التسمية تحت دورة حياة مدير الاتصال بدلًا من تعديل أسماء الواجهات يدويًا.
يحتوي الدليل التاريخي على نماذج إعداد OpenVPN أقدم بكثير، ولا ينبغي نسخ نصائحه التشفيرية إلى نشر حالي. استعر نموذج المنطقة والتدفق بدلًا من ذلك. وخُذ الأساس التشفيري من سياسة OpenVPN المصانة على البوابة.
اسمح فقط بالمسار الذي صنّفته
القبول الواسع من منطقة VPN إلى الشبكة المحلية مخطط بداية، لا سياسة منتهية. اكتب مصدر العميل المسموح به، وعنوان الخدمة الفعلي، والبروتوكول والمنفذ. ثم اقرأ القواعد التي فوقه والافتراضي الخاص بالمنطقة، لأن إضافة ضيقة لا تلغي تصريحًا واسعًا يطابقه أصلًا. وحركة المرور إلى مضيف البوابة علاقة منفصلة عن الحركة الممرَّرة عبره.
تحتاج حركة العملاء بعضهم إلى بعض قرارًا خاصًا. فخيار client-to-client في OpenVPN وخيار routeback في Shorewall يؤثران معًا في إمكانية وصول العملاء إلى بعضهم، ولا ينبغي تفعيل أي منهما لمجرد تشغيل تطبيق شبكة محلية واحد. قرّر أين يُفرض العزل قبل أن تختبره.
أبقِ مسار الرد في الخطة نفسها. يجب أن تعرف الخدمة أو موجّهها كيف يعيد الحركة إلى نطاق النفق، أو يجب أن يحوّل التصميم المصدر عمدًا وضمن النطاق المقصود.
تحقّق، ثم أثبت المسارين
تحقّق من الإعداد قبل إعادة تشغيل أي شيء، وأبقِ جلسة إدارية مستقلة مفتوحة في حال كانت السياسة الجديدة خاطئة.
shorewall checkبعد فحص نظيف، طبّق الإعداد واقرأ ما حمّلته Shorewall. فهذه القراءات تصف السياسة الجارية لا ما يبدو أن ملفًا يقوله.
shorewall show zones
ip route get 192.168.10.20اختبر طلبًا مسموحًا جديدًا وطلبًا مرفوضًا عمدًا من العميل نفسه. فمصافحة OpenVPN الناجحة تثبت التبادل الخارجي فقط؛ أما الخدمة المسموح بها والمورد المرفوض فيثبتان السياسة الداخلية التي قصدتها. ثم أعد اتصال العميل وكرّر، لأن اسم واجهة النفق وعنوانها قد يتغيران بين الجلسات. وإذا اختلفت النتيجة، فأصلح نطاق المنطقة بدلًا من توسيع القاعدة.