دعنا نرى مقدار الجهد الذي سيستغرقه تحويل هذا التكوين إلى نظام جدار
حماية مختلف تمامًا – PF على OpenBSD. هناك طرق مختلفة للقيام بذلك. يمكنني عمل نسخة من جدار حماية كل عضو (linux-test-1 و linux-test-2) ، وتعيين النظام الأساسي ونظام التشغيل المضيف في النسخة إلى PF و OpenBSD ثم إنشاء كائن كتلة جديد. ستكون هذه طريقة معقولة لأنها تحافظ على الأشياء القديمة مما يساعد على التراجع في حالة عدم نجاح شيء ما. ومع ذلك ، لجعل الشرح أقصر ، سأقوم بإجراء التغييرات في مكانها عن طريق تعديل الكائنات الموجودة.
أبدأ بجدران الحماية للأعضاء. افتح كل واحد في المحرر وقم بتغيير اسمه والنظام الأساسي ونظام التشغيل المضيف كما هو موضح في الشكل 26 للعضو الأول:
الشكل 26: تحويل جدار حماية العضو إلى PF / OpenBSD
اضبط إصدار PF لمطابقة إصدار جهاز OpenBSD الخاص بك. قم بنفس التغيير على جدار حماية العضو الثاني ، ثم تحقق من مجموعة تجاوز الفشل للواجهة “eth0” لكائن الكتلة:
الشكل 27. تشير مجموعة تجاوز الفشل إلى أن تكوين الكتلة لا يتطابق مع الأعضاء
تعلن مجموعة تجاوز الفشل حالة كلا العضوين “غير صالح" ، وذلك لأن النظام الأساسي ونظام التشغيل المضيف للأعضاء لا يتطابقان مع تكوين كائن الكتلة بعد الآن. يجب أن تتطابق تمامًا ، لذلك يتعين علينا إعادة تكوين كائن الكتلة إلى النظام الأساسي “PF" ونظام التشغيل المضيف “OpenBSD" أيضًا. يجب أن يؤدي هذا إلى إصلاح حالة كلا العضوين في مربع حوار مجموعة تجاوز الفشل.
للتبديل إلى OpenBSD من Linux ، نحتاج إلى تغيير بروتوكول تجاوز الفشل من Heartbeat إلى CARP أيضًا. تم تكوين البروتوكول في كائن مجموعة تجاوز الفشل. تعتمد قائمة البروتوكولات المتاحة على النظام الأساسي لجدار الحماية المختار في كائن الكتلة الأصل. بينما تم إنشاء المجموعة على أنها “iptables" ، كانت الخيارات الممكنة لبروتوكولات تجاوز الفشل هي “heartbeat" و “VRRP" و “OpenAIS" و “None". لم يكن “CARP" في القائمة لأنه غير متوفر على Linux. بعد تبديل الكتلة إلى “PF" ، تتكون القائمة فقط من “CARP" و “لا شيء" كما هو موضح في الشكل 28:
الشكل 28: خيارات بروتوكول تجاوز الفشل لـ PF / OpenBSD
يمكن لـ Firewall Builder تكوين واجهات CARP على BSD. لذلك ، يحتاج إلى بعض معلمات بروتوكول CARP. يمكنك تكوين هذه إذا قمت بالنقر فوق الزر “تحرير معلمات البروتوكول" في مربع حوار كائن مجموعة تجاوز الفشل. يؤدي هذا إلى إحضار مربع حوار آخر حيث يمكنك تكوين كلمة مرور CARP و vhid وبعض المعلمات الأخرى:
الشكل 29 Â معلمات CARP
آخر شيء علينا تغييره هو أسماء الواجهات. في OpenBSD loopback هي “lo0" ويمكن أن تكون واجهة ethernet على سبيل المثال “pcn0". لإعادة تسمية الواجهات ، ابحث عنها في الشجرة ، افتح المحرر وقم بتغيير الاسم. يجب القيام بذلك مع كائنات الواجهة لكل من جدران الحماية الأعضاء والمجموعة. يتمثل الاختلاف الكبير بين بروتوكول CARP و Heartbeat على Linux في أن CARP ينشئ واجهات شبكية خاصة به تسمى “carpNN". في مصطلحات Firewall Builder ، هذا يعني أننا بحاجة إلى تسمية كائن واجهة الكتلة “carp0" (تذكر أنه في حالة Linux العنقودية ، كان اسم واجهة الكتلة هو نفسه أسماء جدران حماية الأعضاء المقابلة). بعد إعادة تسمية جميع الواجهات ، يبدو التكوين النهائي كما هو موضح في الشكل 30:
ملحوظة
لقد غيرت أيضًا عناوين IP لواجهات pcn0 لكل من جدر الحماية الخاص بالعضو لتجنب التعارض مع جدر الحماية لينكس الذي لا يزال قيد التشغيل.
الشكل 30: التشكيل النهائي لمجموعة PF
الآن يمكننا إعادة تجميع الكتلة مرة أخرى. بالنسبة لـ PF ، يقوم fwbuilder بإنشاء ملفين لكل جدار حماية عضو. ملف واحد له امتداد .conf ويحتوي على تكوين PF. الملف الآخر له الامتداد .fw وهو برنامج نصي للتنشيط.
بالنظر داخل ملف .conf الذي تم إنشاؤه ، نرى تنفيذ PF لقواعد السياسة نفسها (هذا مجرد جزء مع القواعد القليلة الأولى):
# Tables: (2)
table { 10.3.14.50 , 10.3.14.152 , 10.3.14.151 , 10.3.14.150 }
table { 10.3.14.152 , 10.3.14.151 , 10.3.14.150 , 10.3.14.50 }
# # Rule -2 CARP (automatic)
pass quick on pcn0 inet proto carp from any to any label “RULE -2 — ACCEPT “
#
# Rule backup ssh access rule
# backup ssh access rule
pass in quick inet proto tcp from 10.3.14.0/24 to port 22
flags any label “RULE -1 — ACCEPT “
#
# Rule 0 (carp0)
block in log quick on pcn0 inet from to
no state label “RULE 0 — DROP “
#
# Rule 1 (lo0)
pass quick on lo0 inet from any to any no state label “RULE 1 — ACCEPT “
شكل 31: مثال على قاعدة مرتبطة بواجهة كتلة
انظر إلى القاعدة رقم 0 في لقطة الشاشة ، شكل 19 (قاعدة مكافحة الانتحال). تظهر القاعدة نفسها في الشكل Â 31 ، باستثناء أنني أزلت التسمية “الخارج" من الواجهة carp0 لتوضيح الواجهة الموضوعة في عمود “الواجهة" من القاعدة.
تحتوي هذه القاعدة على كائن واجهة ينتمي إلى الكتلة في عمود “الواجهة" الخاص بها. لا تقبل واجهة المستخدم الرسومية لـ Firewall Builder واجهة جدار حماية العضو في هذا العمود. يُسمح فقط بواجهات الكتلة في عمود “الواجهة" من مجموعة القواعد التي تنتمي إلى الكتلة. واجهات مجموعة Linux لها نفس أسماء واجهات جدار حماية الأعضاء المناظرة. في المثال أعلاه ، كانت واجهات الأعضاء “eth0" وواجهة الكتلة تحمل الاسم نفسه. هذا لأن كائن واجهة الكتلة هو تجريد يخدم عدة أغراض: إنه مكان يتم فيه تكوين معلمات بروتوكول تجاوز الفشل وأيضًا يمثل واجهات جدار حماية الأعضاء في القواعد عندما يقوم البرنامج بتجميع السياسة وإنشاء برنامج نصي لجدار الحماية أو ملف التكوين. سيتم استبدال كائن واجهة الكتلة بواجهة جدار حماية العضو الذي يتم تجميع النهج من أجله. عندما يقوم fwbuilder بترجمته للعضو رقم 1 ، فإنه يستبدل كائنات واجهة الكتلة بواجهات العضو رقم 1. عندما يقوم بعد ذلك بتجميع نفس القواعد للعضو رقم 2 ، فإنه يستبدل واجهات المجموعة بواجهات للعضو رقم 2.
هذا يبدو بديهيًا عندما نبني نظام Linux العنقودي لأن أسماء واجهات الأعضاء وواجهات الكتلة هي نفسها. عندما أستخدم واجهة المجموعة “eth0" في القاعدة ، فهي في الأساس مماثلة لاستخدام واجهة جدار الحماية التي تحمل نفس الاسم (باستثناء أنها ليست هي نفسها داخليًا) ، لذا فهي التهيئة التي اعتدت عليها عندما أبدأ في تكوين المجموعات. قضى بعض الوقت في العمل مع جدران الحماية العادية في fwbuilder.
تحتوي واجهات مجموعة BSD على أسماء تتوافق مباشرة مع أسماء واجهات بروتوكول تجاوز الفشل carpNN الموجودة بالفعل على جهاز جدار الحماية. تكمن المشكلة في أن PF لا يفحص الحزم الموجودة على هذه الواجهات ، وبالتالي لا ينبغي إرفاق قواعد PF بهذه الواجهات. ومع ذلك ، يستخدم fwbuilder واجهات مجموعة BSD carpNN بنفس الطريقة الموضحة أعلاه. إذا كنت تريد إرفاق قواعد بواجهات معينة باستخدام عبارة “on " ، فأنت بحاجة إلى استخدام كائن واجهة الكتلة في القواعد. في هذه الحالة ، تمامًا مثلما كنا نبني كتلة Linux ، سيحل fwbuilder محل carpNN بواجهات جدار حماية عضو تم تكوينه في مجموعة تجاوز الفشل لواجهة الكتلة.
أدرك أن هذا قد يكون غير بديهي ، خاصة لأولئك الذين يعرفون كل تفاصيل تكوين مجموعة BSD عن ظهر قلب وهم معتادون جدًا على العمل مع CARP. قد نتمكن من تحسين النموذج في الإصدارات المستقبلية من fwbuilder إذا كان هناك طلب كافٍ من المستخدم.
ملحوظة
بالإضافة إلى قواعد بروتوكول تجاوز الفشل ، يمكن لـ Firewall Builder تلقائيًا إضافة قواعد للسماح بالحزم التي يستخدمها بروتوكول مزامنة الحالة. في حالة PF هذا هو pfsync. يتم تكوين معلمات البروتوكول في كائن “State Sync Group" الموجود في الشجرة أسفل الكتلة مباشرة. يمكن للبرنامج النصي الذي تم إنشاؤه أيضًا تكوين واجهة pfsync وبعض معلمات البروتوكول.
الجزء السفلي من نص التنشيط مثير للاهتمام. هذا هو المكان الذي يتم فيه تكوين واجهة CARP وتنشيط تكوين PF. إليك كيف يبدو هذا:
configure_interfaces() {
sync_carp_interfaces carp0
$IFCONFIG carp0 vhid 100 pass secret carpdev pcn0
update_addresses_of_interface
“carp0 10.3.14.152/0xffffff00 10.3.14.151/0xffffff00 10.3.14.150/0xffffff00" “"
update_addresses_of_interface “lo0 ::1/128 127.0.0.1/0xff000000" “"
update_addresses_of_interface “pcn0 10.3.14.50/0xffffff00" “"
}
log “Activating firewall script generated Thu Mar 18 20:19:42 2010 by vadim"
set_kernel_vars
configure_interfaces
prolog_commands
$PFCTL
-f
${FWDIR}/bsd-test-1.conf || exit 1
تم تعريف دالة Shell “sync_carp_interfaces" في بداية نفس البرنامج النصي ، وهي تقارن قائمة واجهات الكارب المحددة في Firewall Builder بواجهات الكارب الموجودة بالفعل على جهاز جدار الحماية. يتم إنشاء الواجهات المفقودة ويتم حذف الواجهات الموجودة ولكن لم يتم تعريفها في fwbuilder. إذا كانت مجموعة واجهات carp تتطابق مع تلك المحددة في fwbuilder ، فإن هذه الوظيفة لا تفعل شيئًا. بعد ذلك ، تم تكوين الواجهة carp0 للبرنامج النصي باستخدام المعلمات التي تم إدخالها في مربع حوار بروتوكول تجاوز الفشل الشكل 29 الموضح أعلاه. المكالمات إلى وظيفة shell “update_addresses_of_interface" تقوم بتحديث عناوين IP للواجهات ، بما في ذلك carp0. تقوم هذه الوظيفة أيضًا بعمل ذلك بشكل تدريجي من خلال مقارنة قائمة العناوين المطلوبة بتلك التي تم تكوينها بالفعل على الواجهة. في حالة تطابق القوائم ، لا تفعل الوظيفة أي شيء ، وإلا فإنها تضيف العناوين أو تحذفها بالشكل المناسب.
بشكل أساسي ، يمكنك البدء باستخدام جهاز OpenBSD أو FreeBSD الذي تم تكوينه بعنوان IP واحد على الواجهة التي يمكنك استخدامها للتواصل معها. سيقوم البرنامج النصي الذي تم إنشاؤه بواسطة fwbuilder بإعداد عناوين أخرى وبروتوكول تجاوز الفشل.
كما ترى ، تطلب التحويل تغييرات قليلة ولكن ليس كثيرًا. اضطررت إلى تغيير نظام جدار الحماية ونظام التشغيل المضيف في جدران الحماية الأعضاء وكائن الكتلة ، وإعادة تسمية الواجهات ، وربما تغيير عناوين IP ، وتغيير اسم بروتوكول تجاوز الفشل ومعلماته. ظلت العلاقات بين الكتلة والجدران النارية للأعضاء كما هي ، ولذا لم أضطر إلى إضافة جدران الحماية أو إزالتها إلى كائنات مجموعة تجاوز الفشل العنقودية. الأهم من ذلك ، لم يكن عليّ أن أتطرق إلى القواعد على الإطلاق. من المؤكد أن هذا كان مثالًا بسيطًا جدًا وفي الحالات الأكثر تعقيدًا قد تحتاج بعض القواعد إلى تعديل. غالبًا ما يكون هذا هو الحال عندما استخدمت سياسة iptables الأصلية بعض الوحدات والميزات الفريدة من نوعها في iptables. يمكن ترجمة معظم القواعد النموذجية تلقائيًا دون تغيير في واجهة المستخدم الرسومية.