ProHoster > وبلاگ > اداره > Nextcloud در داخل و خارج از OpenLiteSpeed: راه اندازی پروکسی معکوس
Nextcloud در داخل و خارج از OpenLiteSpeed: راه اندازی پروکسی معکوس
چگونه OpenLiteSpeed را برای معکوس کردن پروکسی به Nextcloud در شبکه داخلی تنظیم کنم؟
با کمال تعجب، جستجو در Habré برای OpenLiteSpeed چیزی به دست نمی دهد! من برای اصلاح این بی عدالتی عجله دارم، زیرا LSWS یک وب سرور مناسب است. من آن را به دلیل سرعت و رابط مدیریت وب جذابش دوست دارم:
اگرچه OpenLiteSpeed بیشتر به عنوان یک "شتاب دهنده" وردپرس معروف است، در مقاله امروز استفاده نسبتاً خاصی از آن را نشان خواهم داد. یعنی معکوس پروکسی درخواست ها (پراکسی معکوس). شما می گویید استفاده از nginx برای این کار بیشتر رایج است؟ من موافق خواهم بود. اما خیلی دردناک است که ما عاشق LSWS شدیم!
پروکسی درست است، اما کجا؟ در سرویس نه کمتر فوق العاده - Nextcloud. ما از Nextcloud برای ایجاد "ابرهای اشتراک گذاری فایل" خصوصی استفاده می کنیم. برای هر کلاینت، ما یک VM جداگانه با Nextcloud اختصاص می دهیم و نمی خواهیم آنها را در "خارج" قرار دهیم. در عوض، ما از طریق یک پروکسی معکوس مشترک، درخواست های پراکسی را انجام می دهیم. این راه حل اجازه می دهد:
1) سروری که داده های کلاینت در آن ذخیره شده است را از اینترنت حذف کنید و
2) آدرس های IP را ذخیره کنید.
نمودار به این شکل است:
واضح است که این طرح ساده شده است، زیرا سازماندهی زیرساخت خدمات وب موضوع مقاله امروز نیست.
همچنین در این مقاله نصب و پیکربندی اولیه nextcloud را حذف میکنم، به خصوص که Habré مطالبی در مورد این موضوع دارد. اما من قطعا تنظیمات را نشان خواهم داد که بدون آن Nextcloud پشت پراکسی کار نمی کند.
داده شده:
Nextcloud بر روی میزبان 1 نصب شده و پیکربندی شده است تا از طریق http (بدون SSL) کار کند، فقط یک رابط شبکه محلی و یک آدرس IP "خاکستری" 172.16.22.110 دارد.
بیایید OpenLiteSpeed را روی هاست 2 پیکربندی کنیم. دارای دو رابط خارجی (به اینترنت به نظر می رسد) و داخلی با یک آدرس IP در شبکه 172.16.22.0/24
آدرس IP رابط خارجی Host 2 نام DNS cloud.connect.link است
sudo apt-get نصب openlitespeed
شروع sudo /usr/local/lsws/bin/lswsctrl
حداقل راه اندازی فایروال
sudo ufw اجازه دهید ssh
sudo ufw پیش فرض اجازه خروج را می دهد
sudo ufw به طور پیش فرض رد ورودی
sudo ufw اجازه http را می دهد
sudo ufw اجازه می دهد https
sudo ufw اجازه از میزبان مدیریت شما به هر پورت 7080
sudo ufw را فعال کنید
OpenLiteSpeed را به عنوان یک پروکسی معکوس تنظیم کنید.
بیایید دایرکتوری هایی را تحت میزبان مجازی ایجاد کنیم.
سی دی /usr/local/lsws/
sudo mkdirc cloud.connect.link
سی دی cloud.connect.link/
sudo mkdir {conf,html,logs}
سودو چاون lsadm:lsadm ./conf/
اجازه دهید میزبان مجازی را از رابط وب LSWS پیکربندی کنیم.
مدیریت url را باز کنید http://cloud.connect.link:7080
ورود به سیستم/رمز عبور پیش فرض: admin/123456
یک میزبان مجازی اضافه کنید (میزبان مجازی > افزودن).
هنگام اضافه کردن، یک پیام خطا ظاهر می شود - فایل پیکربندی گم شده است. این طبیعی است، با کلیک روی کلیک برای ایجاد حل می شود.
در تب General، Document Root را مشخص کنید (اگرچه نیازی به آن نیست، پیکربندی بدون آن حذف نخواهد شد). نام دامنه، اگر مشخص نشده باشد، از نام میزبان مجازی که نام دامنه خود را نامگذاری کرده ایم، گرفته می شود.
اکنون زمان آن است که به یاد داشته باشیم که ما نه فقط یک وب سرور، بلکه یک پروکسی معکوس داریم. تنظیمات زیر به LSWS می گوید که چه چیزی و کجا پروکسی کند. در تنظیمات میزبان مجازی، تب External App را باز کنید و یک برنامه جدید از نوع وب سرور اضافه کنید:
نام و آدرس را مشخص کنید. شما می توانید یک نام دلخواه را مشخص کنید، اما باید آن را به خاطر بسپارید، در مراحل بعدی مفید خواهد بود. آدرس آدرسی است که Nextcloud در شبکه داخلی آن زندگی می کند:
در همان تنظیمات میزبان مجازی، تب Context را باز کنید و یک زمینه جدید از نوع Proxy ایجاد کنید:
پارامترها را مشخص کنید: URI = /، وب سرور = nextcloud_1 (نام مرحله قبل)
LSWS را مجددا راه اندازی کنید. این کار با یک کلیک از رابط وب انجام می شود، معجزه! (یک حامل موش ارثی در من صحبت می کند)
ما گواهی را قرار می دهیم، https را پیکربندی می کنیم. مراحل اخذ گواهینامه ما آن را حذف می کنیم، موافقت می کنیم که قبلاً آن را داریم و با کلید در دایرکتوری /etc/letsencrypt/live/cloud.connect.link قرار می گیریم.
بیایید یک "شنونده" (Listeners > Add) ایجاد کنیم، بیایید آن را "https" بنامیم. آن را به پورت 443 ببرید و توجه داشته باشید که Secure خواهد بود:
در تب SSL، مسیر کلید و گواهی را مشخص کنید:
"شنونده" ایجاد شده است، اکنون در بخش Virtual Host Mappings میزبان مجازی خود را به آن اضافه می کنیم:
اگر LSWS فقط به یک سرویس پروکسی کند، پیکربندی میتواند تکمیل شود. اما ما قصد داریم از آن برای ارسال درخواست به "نمونه های" مختلف بسته به نام دامنه استفاده کنیم. و همه دامنه ها گواهینامه های خود را خواهند داشت. بنابراین باید به کانفیگ virtualhost رفته و دوباره کلید و گواهی آن را در تب SSL مشخص کنید. در آینده، این کار باید برای هر میزبان مجازی جدید انجام شود.
باقی مانده است که بازنویسی url را به گونهای پیکربندی کنید که درخواستهای http به https ارسال شوند. (به هر حال، چه زمانی این کار به پایان می رسد؟ وقت آن است که مرورگرها و سایر نرم افزارها به طور پیش فرض به https بروند و در صورت لزوم به صورت دستی به no-SSL فوروارد شوند).
Enable Rewrite را روشن کنید و Rewrite Rules را بنویسید:
به دلیل یک سوء تفاهم عجیب، نمی توان قوانین Rewrite را با راه اندازی مجدد Graceful معمولی اعمال کرد. بنابراین، ما LSWS را نه با ظرافت، بلکه بیادبانه و کارآمد راهاندازی مجدد میکنیم:
sudo systemctl lsws.service را مجددا راه اندازی کنید
برای اینکه سرور به پورت 80 گوش دهد، بیایید یک Listener دیگر ایجاد کنیم. بیایید آن را http بنامیم، پورت 80 را مشخص کنیم و غیر ایمن باشد:
به قیاس با تنظیمات شنونده https، اجازه دهید میزبان مجازی خود را به آن متصل کنیم.
اکنون LSWS به پورت 80 گوش می دهد و درخواست هایی را از آن به 443 ارسال می کند و آدرس اینترنتی را بازنویسی می کند.
در پایان، توصیه میکنم سطح ثبت LSWS را که به طور پیشفرض روی Debug تنظیم شده است، پایین بیاورید. در این حالت لاگ ها با سرعت رعد و برق ضرب می شوند! برای اکثر موارد، سطح هشدار کافی است. به پیکربندی سرور > ورود به سیستم بروید:
این پیکربندی OpenLiteSpeed را به عنوان یک پروکسی معکوس کامل می کند. یک بار دیگر، LSWS را مجددا راه اندازی کنید، پیوند را دنبال کنید https://cloud.connect.link و ببینید:
برای اینکه Nextcloud به ما اجازه ورود بدهد، باید دامنه cloud.connect.link را به لیست مورد اعتماد اضافه کنیم. بیایید به ویرایش config.php برویم. من Nextcloud را به طور خودکار هنگام نصب اوبونتو نصب کردم و پیکربندی در اینجا قرار دارد: /var/snap/nextcloud/current/nextcloud/config.
پارامتر "cloud.connect.link" را به کلید trusted_domains اضافه کنید:
علاوه بر این، در همان پیکربندی، باید آدرس IP پروکسی ما را مشخص کنید. توجه شما را به این واقعیت جلب می کنم که آدرس باید همان آدرسی باشد که برای سرور Nextcloud قابل مشاهده است، یعنی. IP رابط محلی LSWS. بدون این مرحله، رابط وب Nextcloud کار می کند، اما برنامه ها مجاز نیستند.
مشکل حل شد! اکنون هر مشتری می تواند با خیال راحت از "کلاد فایل" در آدرس اینترنتی شخصی خود استفاده کند، سرور با فایل ها از اینترنت جدا شده است، مشتریان آینده همه چیز را یکسان دریافت خواهند کرد و هیچ آدرس IP اضافی تحت تاثیر قرار نخواهد گرفت.
علاوه بر این، می توانید از یک پروکسی معکوس برای ارائه محتوای ثابت استفاده کنید، اما در مورد Nextcloud، این افزایش قابل توجهی در سرعت ایجاد نمی کند. بنابراین اختیاری و اختیاری است.
خوشحالم که این داستان را به اشتراک می گذارم، امیدوارم برای کسی مفید باشد. اگر روش های ظریف و کارآمدتری برای حل مشکل می شناسید، ممنون می شوم که نظر بدهید!