Nextcloud داخل وخارج OpenLiteSpeed: إعداد وكيل عكسي

كيف أقوم بإعداد OpenLiteSpeed ​​لعكس الوكيل إلى Nextcloud على الشبكة الداخلية؟

والمثير للدهشة أن البحث في Habré عن OpenLiteSpeed ​​لا يعطي شيئًا! أسارع لتصحيح هذا الظلم ، لأن LSWS هو خادم ويب لائق. أنا أحبه لسرعته وواجهته الرائعة لإدارة الويب:

على الرغم من أن OpenLiteSpeed ​​هو الأكثر شهرة باعتباره "مسرّع" WordPress ، سأعرض في مقال اليوم استخدامًا محددًا له. وهي عكس التوكيل العكسي للطلبات (الوكيل العكسي). أنت تقول أنه من الشائع استخدام nginx لهذا الغرض؟ سوف أوافق. لكن الأمر مؤلم للغاية لأننا وقعنا في حب LSWS!

الوكلاء على ما يرام ، ولكن أين؟ في خدمة لا تقل روعة - Nextcloud. نستخدم Nextcloud لإنشاء "سحب مشاركة الملفات" الخاصة. لكل عميل ، نخصص جهاز VM منفصلًا مع Nextcloud ، ولا نريد كشفه "بالخارج". بدلاً من ذلك ، نقوم بتوكيل الطلبات من خلال وكيل عكسي مشترك. يتيح هذا الحل:
1) إزالة الخادم الذي يتم تخزين بيانات العميل عليه من الإنترنت و
2) حفظ عناوين IP.

يبدو الرسم التخطيطي كما يلي:

من الواضح أن المخطط مبسط ، لأن تنظيم البنية التحتية لخدمات الويب ليس موضوع مقال اليوم.

في هذه المقالة أيضًا ، سأحذف التثبيت والتكوين الأساسي للسحابة التالية ، خاصة وأن هناك مواد حول هذا الموضوع على Habré. لكنني سأعرض بالتأكيد الإعدادات ، والتي بدونها لن تعمل Nextcloud خلف وكيل.

الممنوحة:
يتم تثبيت Nextcloud على المضيف 1 وتهيئته للعمل عبر http (بدون SSL) ، وله واجهة شبكة محلية فقط وعنوان IP "رمادي" 172.16.22.110.
لنقم بتكوين OpenLiteSpeed ​​على المضيف 2. له واجهتان ، خارجية (تنظر إلى الإنترنت) وداخلية بعنوان IP على الشبكة 172.16.22.0/24
عنوان IP للواجهة الخارجية للمضيف 2 هو DNS name cloud.connect.link

المشكلة:
احصل من الإنترنت عبر الرابط 'https://cloud.connect.link(SSL) إلى Nextcloud على الشبكة الداخلية.

• تثبيت OpenLiteSpeed ​​على Ubuntu 18.04.2.

دعنا نضيف مستودعًا:

wget -O http://rpms.litespeedtech.com/debian/enable_lst_debain_repo.sh | sudo bash
سودو الرابطة بين الحصول على التحديث

التثبيت والتشغيل:

sudo apt-get install openlitespeed
بدء sudo / usr / local / lsws / bin / lswsctrl

• الحد الأدنى من إعداد جدار الحماية.
  

  sudo ufw تسمح ssh
  يسمح sudo ufw الافتراضي بالصادرات
  sudo ufw الافتراضي ينكر الوارد
  sudo ufw تسمح http
  sudo ufw allowhttps
  sudo ufw يسمح من مضيف إدارتك إلى أي منفذ 7080
  sudo ufw تمكين

• قم بإعداد OpenLiteSpeed ​​كوكيل عكسي.
  دعونا ننشئ الدلائل تحت Virtualhost.

  cd / usr / local / lsws /
  sudo mkdirc cloud.connect.link. رابط
  القرص المضغوط cloud.connect.link/
  sudo mkdir {conf، html، logs}
  sudo chown lsadm: lsadm ./conf/

لنقم بتكوين المضيف الظاهري من واجهة الويب LSWS.
افتح إدارة عنوان url http://cloud.connect.link:7080
تسجيل الدخول / كلمة المرور الافتراضية: admin / 123456

أضف مضيفًا افتراضيًا (Virtual Hosts> Add).
عند الإضافة ، ستظهر رسالة خطأ - ملف التكوين مفقود. هذا أمر طبيعي ، يتم حله بالنقر فوق انقر لإنشاء.

في علامة التبويب "عام" ، حدد "جذر المستند" (على الرغم من عدم الحاجة إليه ، لن يتم تشغيل التكوين بدونه). سيتم أخذ اسم المجال ، إذا لم يتم تحديده ، من اسم المضيف الظاهري ، والذي أطلقنا عليه اسم المجال الخاص بنا.

حان الوقت الآن لنتذكر أنه ليس لدينا خادم ويب فحسب ، بل وكيل عكسي. ستخبر الإعدادات التالية LSWS بالوكيل وأين. في إعدادات المضيف الظاهري ، افتح علامة التبويب تطبيق خارجي وأضف تطبيقًا جديدًا لنوع خادم الويب:

حدد الاسم والعنوان. يمكنك تحديد اسم تعسفي ، ولكن عليك تذكره ، سيكون مفيدًا في الخطوات التالية. العنوان هو العنوان الذي تعيش فيه Nextcloud في الشبكة الداخلية:

في نفس إعدادات المضيف الظاهري ، افتح علامة تبويب السياق وقم بإنشاء سياق جديد لنوع الوكيل:

حدد المعلمات: URI = / ، خادم الويب = nextcloud_1 (الاسم من الخطوة السابقة)

أعد تشغيل LSWS. يتم ذلك بنقرة واحدة من واجهة الويب ، معجزات! (حامل فأر وراثي يتكلم في داخلي)

• نضع الشهادة ، تكوين https.
  إجراءات الحصول على الشهادة سنحذفه ، ونتفق على أنه لدينا بالفعل ونكذب مع المفتاح في الدليل /etc/letsencrypt/live/cloud.connect.link.

لنقم بإنشاء "مستمع" (مستمعون> إضافة) ، دعنا نسميه "https". أشر إلى المنفذ 443 ولاحظ أنه سيكون آمنًا:

في علامة التبويب SSL ، حدد المسار إلى المفتاح والشهادة:

تم إنشاء "المستمع" ، والآن في قسم تعيينات المضيف الظاهري ، سنضيف مضيفنا الافتراضي إليه:

إذا كان LSWS سيقوم بالوكيل لخدمة واحدة فقط ، فيمكن إكمال التكوين. لكننا نخطط لاستخدامه لإرسال الطلبات إلى "مثيلات" مختلفة اعتمادًا على اسم المجال. وستكون لجميع المجالات شهاداتها الخاصة. لذلك ، تحتاج إلى الانتقال إلى تهيئة المضيف الظاهري وتحديد مفتاحه وشهادته مرة أخرى في علامة التبويب SSL. في المستقبل ، يجب أن يتم ذلك لكل مضيف افتراضي جديد.

يبقى تكوين إعادة كتابة عنوان url بحيث يتم توجيه طلبات http إلى https.
(بالمناسبة ، متى تنتهي هذه؟ لقد حان الوقت للمتصفحات والبرامج الأخرى للانتقال إلى https افتراضيًا وإعادة التوجيه إلى no-SSL يدويًا إذا لزم الأمر).
قم بتشغيل تمكين إعادة الكتابة وكتابة قواعد إعادة الكتابة:

RewriteCond٪ {SERVER_PORT} 80
إعادة كتابة القاعدة ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R = 301، L]

بسبب سوء فهم غريب ، من المستحيل تطبيق قواعد إعادة الكتابة مع إعادة التشغيل المعتادة. لذلك ، سنعيد تشغيل LSWS ليس برشاقة ، ولكن بوقاحة وكفاءة:

أعد تشغيل sudo systemctl lsws.service

لجعل الخادم يستمع إلى المنفذ 80 ، فلنقم بإنشاء مستمع آخر. دعنا نسميها http ، حدد المنفذ 80 وأنه سيكون غير آمن:

بالتشابه مع إعدادات مستمع https ، دعنا نعلق مضيفنا الظاهري به.

الآن سوف يستمع LSWS على المنفذ 80 ويرسل الطلبات منه إلى 443 ، ويعيد كتابة عنوان url.
في الختام ، أوصي بتخفيض مستوى تسجيل LSWS ، والذي تم تعيينه على التصحيح افتراضيًا. في هذا الوضع ، تتكاثر السجلات بسرعة البرق! بالنسبة لمعظم الحالات ، يكون مستوى التحذير كافياً. انتقل إلى تكوين الخادم> السجل:

هذا يكمل تكوين OpenLiteSpeed ​​كوكيل عكسي. مرة أخرى ، أعد تشغيل LSWS ، اتبع الرابط https://cloud.connect.link ونرى:

لكي يسمح لنا Nextcloud بالدخول ، نحتاج إلى إضافة مجال cloud.connect.link إلى القائمة الموثوقة. دعنا نذهب لتحرير config.php. لقد قمت بتثبيت Nextcloud تلقائيًا عند تثبيت Ubuntu وكان التكوين موجودًا هنا: / var / snap / nextcloud / current / nextcloud / config.
أضف المعلمة "cloud.connect.link" إلى مفتاح Trust_domains:

"Trusted_domains" =>
مجموعة مصفوفة (
0 => "172.16.22.110" ،
1 => "cloud.connect.link" ،
),

علاوة على ذلك ، في نفس التكوين ، يجب عليك تحديد عنوان IP لوكيلنا. أود أن ألفت انتباهك إلى حقيقة أنه يجب تحديد العنوان هو العنوان المرئي لخادم Nextcloud ، أي عنوان IP لواجهة LSWS المحلية. بدون هذه الخطوة ، تعمل واجهة الويب Nextcloud ، لكن التطبيقات غير مصرح بها.

'trust_proxies' =>
مجموعة مصفوفة (
0 => "172.16.22.100" ،
),

رائع ، بعد ذلك يمكننا الدخول إلى واجهة التفويض:

تم حل المشكلة! الآن يمكن لكل عميل استخدام "سحابة الملفات" بأمان على عنوان url الشخصي الخاص به ، ويتم فصل الخادم الذي يحتوي على الملفات عن الإنترنت ، وسيتلقى العملاء المستقبليون كل شيء كما هو ولن يتأثر عنوان IP إضافي واحد.
بالإضافة إلى ذلك ، يمكنك استخدام وكيل عكسي لتقديم محتوى ثابت ، ولكن في حالة Nextcloud ، لن يؤدي ذلك إلى زيادة ملحوظة في السرعة. لذلك فهو اختياري واختياري.

يسعدني مشاركة هذه القصة ، وآمل أن تكون مفيدة لشخص ما. إذا كنت تعرف طرقًا أكثر أناقة وفعالية لحل المشكلة ، فسأكون ممتنًا للتعليقات!

المصدر: www.habr.com