استخدم خاصية وكيل Zimbra zimbraReverseProxyMailModeلإعادة توجيه طلبات الويب من HTTP إلى HTTPS. فعّلها redirectعلى كل عقدة من عقد وكيل Zimbra، ثم أعد تشغيل خدمة الوكيل وتحقق من وجود Location: https://...ترويسة في استجابة HTTP. قبل ذلك، تأكد من أن اسم مضيف HTTPS العام يُشير بالفعل إلى الوكيل أو موازن الأحمال الخاص بك، وأن الشهادة صالحة.
هذا الإعداد مخصص للوصول إلى الويب عبر Zimbra Proxy. وهو لا يقوم تلقائيًا بتكوين HTTPS لمخزن البريد، أو تثبيت شهادة، أو ضمان اتباع جميع تطبيقات البريد لإعادة التوجيه. إذا كنت بحاجة إلى رفض طلبات HTTP بشكل كامل، ففكّر في استخدام وضع الوكيل HTTPS فقط بدلاً من إعادة التوجيه.
| وضع البريد الإلكتروني عبر الوكيل | ماذا يحدث لبروتوكول HTTP؟ | متى يُستخدم؟ |
|---|---|---|
redirect | يقوم الخادم الوكيل بإرجاع استجابة HTTP 302 لتوجيه العميل إلى HTTPS. | مفيد عندما لا يزال الأشخاص يدخلون عنوان URL من نوع HTTP ويجب إرسالهم إلى عنوان الويب الآمن. |
https | يقوم الخادم الوكيل بخدمة عميل الويب عبر بروتوكول HTTPS؛ فهو لا يوفر نفس تدفق إعادة التوجيه من HTTP إلى HTTPS. | يفضل هذا الخيار عندما لا ينبغي للعملاء بدء جلسة عبر بروتوكول HTTP. |
bothأوmixed | هذه أوضاع بروكسي منفصلة ذات سلوك مختلف لبروتوكول HTTP/HTTPS. | استخدمه فقط عندما يتطلب النشر تحديدًا السلوك الموثق؛ لا تفترض أنهم يفرضون إعادة توجيه HTTP. |
تحذر إرشادات أمان Zimbra من أن بعض العملاء، بما في ذلك عملاء ActiveSync، قد لا يستجيبون لإعادة توجيه HTTP، وقد يرسلون بيانات الاعتماد في الطلب الأولي غير المشفر. لذا، تُعد إعادة التوجيه مفيدة لتسهيل استخدام المتصفح، ولكنها ليست بديلاً عن الوصول عبر HTTPS فقط عندما يتعين على جميع العملاء تجنب HTTP. في حال اختيار وضع إعادة التوجيه، يجب حماية مستمع HTTP على حافة الشبكة حسب الحاجة، وإبلاغ المستخدمين بعنوان URL الخاص بـ HTTPS.
mail.example.com، إلى الخادم الوكيل العام أو موازن الأحمال. يجب أن يعمل بروتوكول HTTPS بالفعل على اسم المضيف والمنفذ المتوقعين.استخدم حساب Zimbra لتنفيذ الأوامر الإدارية الموضحة أدناه. استبدل proxy1.example.comباسم خادم Zimbra الخاص بعقدة الوكيل، واستبدل mail.example.comباسم مضيف البريد الإلكتروني العام. لا تقم بلصق أسماء الأمثلة حرفيًا في نظام الإنتاج.
على مضيف Zimbra مع توفر أدوات سطر الأوامر، استعلم عن الإعداد الحالي للوكيل:
zmprov gs proxy1.example.com zimbraReverseProxyMailModeسجّل المخرجات لتتمكن من مقارنتها بعد التغيير أو استعادة الوضع السابق إذا لزم الأمر. gsيقرأ الأمر خصائص الخادم؛ msأما الأمر المستخدم أدناه فيُعدّلها.
قم بتعيين السمة على كائن خادم الوكيل:
zmprov ms proxy1.example.com zimbraReverseProxyMailMode redirectتُحدد وثائق تكوين Zimbra Proxy redirectوضع إعادة توجيه طلبات HTTP إلى HTTPS. طبّق الأمر نفسه على كل عقدة بروكسي تقبل حركة مرور الويب العامة. إذا كان بإمكان موازن الأحمال إرسال طلب HTTP إلى عدة بروكسيات، فيجب أن يكون سلوك كل بروكسي مؤهل متسقًا.
لا تخلط بين هذا الإعداد و zimbraMailMode... تُوثّق زيمبرا تلك السمة بشكل منفصل لاتصال خادم البريد. تغيير وضع تخزين البريد ليس هو الخطوة التي تُفعّل إعادة توجيه HTTP للمتصفح على الخادم الوكيل.
redirect؛ كرر ذلك مع كل اسم خادم وكيل في عملية نشر متعددة العقد.أعد تشغيل خدمة الوكيل على العقدة التي قمت بتغيير الإعداد عليها:
zmproxyctl restartثم تحقق من حالة الخدمة:
zmproxyctl statusأعد تشغيل كل عقدة بروكسي على حدة، إذا كان لديك طبقة احتياطية. اتبع إرشادات التشغيل الخاصة بإصدار Zimbra المُثبّت لديك إذا كانت بيئتك تتضمن عملية تحديث ذاكرة التخزين المؤقت للإعدادات أو عملية تنسيق الخدمات. تجنّب تعديل ملفات Nginx المُنشأة مباشرةً: إذ يُدير Zimbra إعدادات البروكسي من إعدادات الخادم، وقد تُستبدل التعديلات اليدوية.
تستخدم الأمثلة دليل إدارة Zimbra Daffodil v10 ووثائق Zimbra المنشورة الخاصة بالوكيل/الأمان. قد تختلف إصدارات ZCS الأقدم في التغليف أو الإجراءات المدعومة، لذا يُرجى مراجعة دليل الإدارة لمعرفة الإصدار المُثبّت لديك قبل إجراء أي تغيير.
من نظام يمكنه الوصول إلى نقطة النهاية العامة، اطلب عنوان URL الخاص ببروتوكول HTTP دون اتباع عمليات إعادة التوجيه:
curl -sS -D - -o /dev/null http://mail.example.com/في وضع إعادة التوجيه، ابحث عن استجابة 302 وعنوان Locationيبدأ بـ https://mail.example.com/. قد تختلف العناوين الدقيقة ومعالجة الحالة باختلاف إصدار Zimbra والمسار وأي موازن تحميل أو بوابة ويب أمام الوكيل. الشاشة التالية مثال توضيحي لنمط العنوان المتوقع، وليست اختبارًا تم التقاطه من خادم فعلي.
قم بإجراء طلب منفصل إلى عنوان URL الآمن:
curl -sS -D - -o /dev/null https://mail.example.com/تأكد من صحة شهادة TLS لاسم المضيف، وأن الاستجابة هي صفحة البريد الإلكتروني المتوقعة أو إعادة توجيه التطبيق. لا تستخدم curl -kأي وسيلة لتجاوز التحقق من الشهادة، فهذا يخفي مشكلة الشهادة التي قد يواجهها المستخدمون. قد تُعيد صفحة تسجيل الدخول إعادة توجيه أو حالة غير 200، وذلك بحسب إصدار المنتج وآلية المصادقة، لذا قيّم الاستجابة بالتزامن مع فحص المتصفح.
افتح http://mail.example.comالمتصفح في جلسة جديدة. يجب أن يتغير العنوان إلى عنوان HTTPS قبل إدخال بيانات الاعتماد. ثم افتح عنوان HTTPS مباشرةً وتأكد من تحميل صفحة تسجيل الدخول دون ظهور تحذير بشأن الشهادة. كرر العملية من خارج شبكتك الداخلية إذا كانت نتائج استخدام نظام أسماء النطاقات العام (DNS) أو قواعد جدار الحماية أو موازن الأحمال مختلفة.
لا تختبر العملية بإدخال كلمة مرور حقيقية بينما لا يزال شريط العنوان يعرض HTTP. إذا فشلت عملية إعادة التوجيه، فتوقف وقم بتصحيح إعدادات الخادم الوكيل أو خادم الحافة أو الشهادة أولاً.
| الأعراض | ما الذي يجب فحصه؟ |
|---|---|
| يبقى بروتوكول HTTP على نفس عنوان URL | استعلم zimbraReverseProxyMailModeعن الخادم الوكيل الذي تعامل مع الطلب؛ تحقق من أن كل عقدة متوازنة الأحمال تحتوي على القيمة المقصودة وتم إعادة تشغيلها. |
| يستخدم عنوان الموقع اسم مضيف أو منفذ خاطئ | تحقق من عنوان URL العام، وقواعد الخادم الوكيل العكسي أو موازن التحميل، وإعدادات اسم المضيف/البروتوكول/المنفذ لخدمة Zimbra العامة المستخدمة لإنشاء الروابط العامة. |
| يُبلغ المتصفح عن تحذير بشأن الشهادة | تأكد من تثبيت الشهادة على نقطة إنهاء TLS، وأنها تغطي اسم المضيف العام، وتتضمن شهادات السلسلة اللازمة. |
| يرى المستخدمون حلقة إعادة توجيه | راجع ما إذا كان موازن الأحمال الأمامي يُنهي بروتوكول TLS ولكنه يُعيد توجيه HTTP إلى Zimbra، وتأكد من قدرة الخادم الوكيل على تحديد بروتوكول الطلب الخارجي بشكل صحيح. واضبط إعدادات TLS وإعادة التوجيه على حافة الشبكة. |
| لا يزال برنامج البريد الإلكتروني يرسل رسائل HTTP | لا تفترض أن العميل يتبع إعادة التوجيه 302. فضل استخدام HTTPS فقط للعملاء الذين يجب ألا يرسلوا بيانات الاعتماد عبر HTTP، وقم بتكوين كل عميل باستخدام عنوان URL لخادم HTTPS. |
zimbraReverseProxyMailModeيتم ضبطه redirectعلى كل عقدة وكيل قابلة للتطبيق.Locationرأس HTTPS، ويقوم طلب HTTPS المباشر بالتحقق من صحة الشهادة.تعرف على كيفية طلب رمز التحقق من المفتاح (TOTP) من Keycloak لتسجيل الدخول إلى ownCloud Infinite Scale، وتسجيل المستخدمين الحاليين والجدد، وإعداد عملية الاسترداد، واختبار تسجيل الدخول الموحد (SSO) وترقية المصادقة متعددة العوامل (MFA).
قم بربط ownCloud Infinite Scale بـ Keycloak باستخدام OpenID Connect. قم بتهيئة مُصدر النطاق، وعميل الويب، والمطالبات، وTLS، وتوفير الحساب، وفحوصات تسجيل الدخول.
قم ببناء مجموعة Nextcloud مرنة باستخدام MariaDB Galera، والتخزين المشترك، وRedis، وموازنة الأحمال، وفحوصات النصاب، والاسترداد المختبر - بالإضافة إلى المقايضات التي يجب التخطيط لها.
تعرف على كيفية تكوين النسخ الاحتياطي لمفاتيح Element، ومفاتيح الاسترداد، والتوقيع المتبادل، ومقارنة المفاضلات الأمنية، والتحقق من الأجهزة، وتجنب فقدان السجل المشفر.
قارن بين Zextras Backup و imapsync لنقل خادم Zimbra. جهّز الحسابات، واختبر عملية النقل، وقم بمزامنة التغييرات، وانقل سجلات MX، وتحقق من بيانات البريد والتعاون.
قم بإصلاح خطأ قاعدة بيانات Nextcloud WebGUI بعد التحديث عن طريق التحقق من السجلات، وإكمال ترقية occ، وإصلاح مشكلات المخطط، والتحقق من سلامة قاعدة البيانات.
قم بتكوين Zimbra Proxy لإعادة توجيه حركة مرور البريد الإلكتروني من HTTP إلى HTTPS، وأعد تشغيل كل عقدة وكيل، وتحقق من إعادة التوجيه، وتجنب المخاطر الأمنية الشائعة.
قم بربط BigBlueButton بنظام إدارة التعلم Moodle باستخدام النشاط المدمج، وعنوان URL للخادم، والكلمة السرية المشتركة. اتبع ثماني خطوات لإعداد غرفة الدورة التدريبية واختبار وصول الطلاب.
قم بتخصيص العلامة التجارية لموقع ownCloud الإلكتروني باستخدام شعارك، وأيقونة الموقع، وخلفية تسجيل الدخول، واسم علامتك التجارية، وألوان السمة باستخدام إعدادات JSON للسمة المدعومة من Infinite Scale.
قم بتكوين توقيع Zimbra DKIM، وتفويض SPF، وسياسة DMARC بشكل صحيح، وتحقق من DNS والمحاذاة، وتجنب السجلات الشائعة التي تكسر مصادقة البريد.
