Як наладзіць OpenLiteSpeed на зваротнае праксіраванне ў Nextcloud, які знаходзіцца ва ўнутранай сетцы?
Дзіўна, але пошук на Хабры па запыце OpenLiteSpeed не дае нічога! Спяшаюся выправіць гэтую несправядлівасць, бо LSWS - годны вэб-сервер. Я люблю яго за хуткасць і модны вэб-інтэрфейс адміністравання:
Нягледзячы на тое, што OpenLiteSpeed найболей знакаміты як паскаральнік вордпресса, у сённяшнім артыкуле я пакажу даволі спецыфічнае яго ўжыванне. А менавіта зваротнае праксіраванне запытаў (reverse proxy). Вы скажаце, што для гэтага больш звыкла выкарыстоўваць nginx? Я пагаджуся. Але балюча ўжо нам пакахаўся LSWS!
Праксіраванне ок, але куды? У не менш выдатны сэрвіс - Nextcloud. Мы выкарыстоўваем Nextcloud для стварэння прыватных "файлаабменных аблокаў". Для кожнага кліента мы вылучаем асобную VM з Nextcloud, і не жадаем выстаўляць іх "вонкі". Замест гэтага мы праксуем запыты праз агульны reverse proxy. Гэтае рашэнне дазваляе:
1) прыбраць сервер, на якім захоўваюцца дадзеныя кліента, з інтэрнэту і
2) зэканоміць ip-адрасы.
Схема выглядае так:
Зразумела, што схема спрошчаная, т.я. арганізацыя інфраструктуры вэб-сэрвісаў - не тэма сённяшняга артыкула.
Таксама ў дадзеным артыкуле я апушчу ўстаноўку і базавую наладу некстклауда, тым больш што на Хабры ёсць прысвечаныя гэтай тэме матэрыялы. Але абавязкова пакажу наладкі, без якіх Nextcloud не будзе працаваць за проксі.
Дадзена:
Nextcloud усталяваны на хасце 1 і наладжаны на працу па http (без SSL), мае толькі лакальны сеткавы інтэрфейс і "шэры" IP-адрас 172.16.22.110.
Наладзім OpenLiteSpeed на хасце 2. У яго два інтэрфейсу, вонкавы (глядзіць у інтэрнэт) і ўнутраны з IP-адрасам у сетцы 172.16.22.0/24
На IP-адрас знешняга інтэрфейсу хаста 2 вядзе DNS-імя cloud.connect.link
задача:
Пападаць з інтэрнэту па спасылцы' (SSL) на Nextcloud ва ўнутранай сетцы.
- Усталёўваны OpenLiteSpeed на Ubuntu 18.04.2.
Дадамо рэпазітар:
wget -O - |sudo bash
Суда apt-get абнаўлення
ставім, запускаем:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Мінімальна наладзім файрвол.
sudo ufw дазваляюць ssh
sudo ufw па змаўчанні дазваляе выходныя
sudo ufw па змаўчанні забараняе ўваходныя
Sudo UFW дазваляюць HTTP
sudo ufw дазволіць https
sudo ufw дазвол ад ваш хост кіравання to any port 7080
Sudo UFW ўключыць - Наладзім OpenLiteSpeed as a reverse proxy.
Створым дырэкторыі пад віртуалхост.cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Наладзім віртуалхост з вэб-інтэрфейсу LSWS.
Адкрываем менеджмент урл
Дэфолтны лагін/пароль: admin/123456
Дадаем віртуалхост (Virtual Hosts > Add).
Пры даданні з'явіцца паведамленне аб памылцы - адсутнасці канфігурацыйнага файла. Гэта нармальна, вырашаецца націскам Click to create.
Ва ўкладцы General пакажам Document Root (хоць ён і не спатрэбіцца, без яго канфіг не ўзляціць). Domain Name, калі яго не ўказваць, будзе ўзяты з Virtual Host Name, які мы назвалі імем нашага дамена.
Цяпер сітавіна ўспомніць, што ў нас не проста вэб-сервер, а reverse proxy. Наступныя налады пакажуць LSWS, што праксіраваць і куды. У наладах віртуалхаста адкрываем укладку External App і дадаем новую аплікацыю тыпу Web server:
Указваем імя і адрас. Імя можна ўказаць адвольнае, але яго трэба запомніць, спатрэбіцца на наступных кроках. Адрас - той, дзе жыве Nextcloud ва ўнутранай сетцы:
У тых жа наладах віртуалхаста адкрываем укладку Context і ствараем новы кантэкст тыпу Proxy:
Указваем параметры: URI = /, Web server = nextcloud_1 (імя з папярэдняга кроку)
Перазапускаем LSWS. Гэта робіцца адным клікам з вэб-інтэрфейсу, цуды! (у мне кажа патомны мышавоз)
- Ставім сертыфікат, наладжваем https.
мы апусцім, дамовімся што ён у нас ужо ёсць і ляжыць разам з ключом у дырэкторыі /etc/letsencrypt/live/cloud.connect.link.
Створым «слухача» (Listeners> Add), назавём яго «https». Пакажам яму на 443 порт і адзначым, што ён будзе Secure:
Ва ўкладцы SSL пакажам шлях да ключа і сертыфіката:
«Слухач» створаны, зараз у раздзеле Virtual Host Mappings дадамо да яго наш віртуалхост:
Калі LSWS будзе праксіраваць толькі да аднаго сэрвісу, настройку можна заканчваць. Але мы плануем выкарыстоўваць яго для перадачы запытаў у розныя "інстанцыі" у залежнасці ад даменнага імя. І ва ўсіх даменаў будуць свае сертыфікаты. Таму трэба пайсці ў канфіг віртуалхаста і зноў паказаць ва ўкладцы SSL яго ключ і сертыфікат. У будучыні гэта трэба рабіць для кожнага новага віртуалхоста.
Засталося наладзіць перазапіс url, каб http-запыты адрасаваліся на https.
(Дарэчы, калі ўжо гэта скончыцца? Час ужо браўзэрам і іншаму софту па змаўчанні хадзіць на https, а перасылку на no-SSL рабіць уручную пры неабходнасці).
Уключаем Enable Rewrite і запісваем Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Ужыць Rewrite rules звыклым Graceful restart па дзіўным непаразуменні нельга. Таму перазапусцім LSWS не хупава, а грубіянска і эфектыўна:
sudo systemctl restart lsws.service
Каб сервер слухаў і 80-й порт, створым яшчэ адзін Listener. Назавем яго http, пакажам 80-й порт і тое, што ён будзе не-Secure:
Па аналогіі з наладай https listener, прымапім да яго наш віртуалхост.
Цяпер LSWS будзе слухаць 80-й порт і накіроўваць з яго запыты на 443, перапісваючы url.
У завяршэнне рэкамендую зменшыць узровень лагавання LSWS, які па змаўчанні ўсталяваны як Debug. У такім рэжыме логі размножваюцца вокамгненна! Для большасці выпадкаў дастаткова ўзроўню Warning. Ідзем у Server Configuration > Log:
На гэтым налада OpenLiteSpeed у якасці зваротнага проксі завершана. У чарговы раз перазапускаем LSWS, ідзем па спасылцы і бачым:
Каб Nextcloud пусціў нас, неабходна ўнесці дамен cloud.connect.link у спіс давераных. Ідзем кіраваць config.php. Nextcloud я ставіў аўтаматычна пры ўсталёўцы Ubuntu і канфіг знаходзіцца тут: /var/snap/nextcloud/current/nextcloud/config.
Ключу trusted_domains дадаем параметр 'cloud.connect.link':
'trusted_domains' =>
масіў (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Далей, у тым жа канфігу трэба ўказаць IP-адрас нашага проксі. Зважаю, што адрас трэба паказаць той, які бачны серверу Nextcloud, г.зн. IP лакальнага інтэрфейсу LSWS. Без гэтага кроку працуе вэб-інтэрфейс Nextcloud, але не аўтарызуюцца прыкладанні.
'trusted_proxies' =>
масіў (
0 => '172.16.22.100',
),
Выдатна, пасля гэтага мы можам патрапіць у інтэрфейс аўтарызацыі:
Задача вырашана! Цяпер кожны кліент можа бяспечна карыстацца "файлавым воблакам" па сваім персанальным url, сервер з файламі аддзелены ад інтэрнэту, будучыя кліенты атрымаюць усё тое ж самае і ні адзін дадатковы IP-адрас не пацерпіць.
Дадаткова можна выкарыстоўваць reverse proxy для дастаўкі статычнага кантэнту, але ў выпадку Nextcloud гэта не дасць адчувальнага прыросту хуткасці. Так што гэта апцыянальна і па жаданні.
Рады падзяліцца гэтай гісторыяй, спадзяюся каму-небудзь будзе карысна. Калі вы ведаеце больш хупавыя і эфектыўныя метады рашэння пастаўленай задачы - буду ўдзячны за каментары!
Крыніца: habr.com