أي وضع من Sophos RED يناسب شبكة فرعك؟
RED دور للموقع البعيد وليس بروتوكولًا. اختر Standard/Unified أو Standard/Split أو Transparent/Split بحسب مالك بوابة الفرع وخدمة DHCP.
RED عند Sophos دور للموقع البعيد لا بروتوكول VPN، ولهذا فإن مقارنته بـ IPsec أو OpenVPN تجيب عن السؤال الخطأ. يمدّ الجهاز سيطرة جدار حماية مركزي إلى فرع، والوضع الذي تختاره يحدد من يوفّر بوابة الفرع، ومن يوزّع العناوين، وأي حركة مرور تعبر النفق. هذه الإجابات الثلاث أهم من أسماء الأوضاع. وتدوينها أولًا يحوّل اختيار منتج إلى قرار تصميم.
RED دور وليس بروتوكولًا
ينضم جهاز RED بفرع إلى جدار حماية Sophos مركزي، وتهيئة جدار الحماية هي التي تحدد ما يصبح عليه الفرع. النفق تفصيل تنفيذي في هذا الانضمام، لا نقطة نهاية VPN عامة الغرض يمكن توجيهها إلى أي نظير.
هذا التأطير مهم لأن RED ليس بديلًا عن أي نظير IPsec عشوائي. فهو يتوقع أن يديره جدار الحماية المركزي، والأوضاع المدعومة تصف مقدار ما يستولي عليه من الفرع. والتعامل معه كنقطة نهاية نفق عادية يخلق توقعات لم يعد بها المنتج قط. أما التعامل معه كدور فينتج الأسئلة التي تحدد التصميم فعليًا.
الشروط الثلاثة أدناه تغيّر الإجابة، وكلها تتعلق بالملكية لا بالتشفير.
ثلاثة شروط تحدد الوضع
اسأل من يملك بوابة الفرع، ومن يدير DHCP و DNS لعملاء الفرع، وهل يجب أن يصمد الخروج المحلي إلى الإنترنت عند انقطاع النفق.
يجيب Standard/Unified عن الأسئلة الثلاثة بالطريقة نفسها: جدار الحماية المركزي يملك الشبكة المحلية للفرع، بما في ذلك مهام البوابة و DHCP، وحركة المرور تعبر النفق. ويحتفظ Standard/Split بالإدارة المركزية ويرسل الشبكات المهيأة فقط عبر النفق. أما Transparent/Split فيترك شبكة الفرع القائمة تتولى بوابتها وعناوينها، ويعيد توجيه حركة مختارة فقط إلى النفق. ثلاثة أوضاع وثلاثة ملاك مختلفون.
| Mode | Branch gateway and DHCP | Traffic through the tunnel |
|---|---|---|
| Standard/Unified | Central firewall owns both | All branch traffic |
| Standard/Split | Central firewall owns both | Only the configured networks |
| Transparent/Split | The existing branch router keeps both | Only the selected flows |
اقرأ العمود الأوسط أولًا، لأنه يحدد مقدار ما يظل يعمل في الفرع عند غياب النفق.
من يملك بوابة الفرع و DHCP
في الترتيب الموحّد لا يملك الفرع بوابة مستقلة تُذكر، وهذا يبسّط التهيئة ويركّز العطل. وهذا التركيز مقبول حين يكون الفرع صغيرًا وجدار الحماية المركزي عالي الإتاحة.
في النشر الشفاف يحتفظ الفرع بموجّهه ويجلس جهاز RED في المسار لإعادة توجيه حركة مختارة. وهذا يحفظ التحكم المحلي ويضيف جهازًا صار موقعه في المسار مهمًا لكل تدفق يُعاد توجيهه. وثّق موقعه، لأن تغييرًا لاحقًا في موجّه الفرع قد يتجاوزه بصمت. ولا يفضّل أي من الترتيبين على وجه العموم؛ فهما يوزعان المسؤولية بطريقتين مختلفتين.
ملكية العناوين هي الجزء الذي يجب تدوينه، لأن خادمي DHCP على مقسم واحد ينتجان أعطالًا متقطعة تُبلَّغ كمشكلات VPN.
ماذا يحدث عند سقوط النفق
كثيرًا ما يُقرأ تشغيل Split كوعد بأن الإنترنت المحلي يظل يعمل أثناء عطل النفق، وهذه القراءة غير آمنة. فالسلوك الدقيق يعتمد على الوضع المختار والبرنامج الثابت والجهاز، ولذلك موضعه معايير القبول لا الافتراضات.
حدد ما يجب أن يفعله الفرع دون نفق: الوصول إلى طابعات محلية، أو حل الأسماء، أو تحصيل المدفوعات، أو لا شيء على الإطلاق. ثم اختبر تلك الحالة عمدًا بحجب النفق ومراقبة الفرع. فالفرع الذي يفقد DNS بهدوء أسوأ من فرع يفشل بصوت عالٍ، لأن اتصال الدعم يصل بعد ساعات. واكتب النتيجة المرصودة في سجل التصميم.
الاعتماد المركزي واحد في كل وضع: لا بد أن يملك أحدهم مسار الاستعادة للجهاز نفسه.
اكتب عقد الفرع قبل النشر
عقد الفرع يتسع في صفحة واحدة: الملاك، ومصادر العناوين، والبادئات التي تمر عبر النفق، وسياسة الخروج، وسلوك الانقطاع الذي قبلته.
ثم تحقق من النتيجة المنشورة لا من النتيجة المقصودة. افحص عنوان عميل الفرع، وبوابته الافتراضية، وأي البادئات تُحل عبر النفق، وما يظل يستجيب عند حجب النفق. والتوافق والوصول والترخيص كلها تحتاج فحصًا مقابل وثائق المورّد الحالية للطراز نفسه، لأن اسم المنتج لا يضمن وضعًا. واحفظ تلك الصفحة مع سجل الجهاز ليرث المهندس التالي القرارات بدل المخطط.
ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.exampleأعد تلك الكتلة والنفق محجوب، فالفرق بين التشغيلين هو سلوك الانقطاع الذي اشتريته فعلًا.