Nextcloud всередині, а зовні OpenLiteSpeed: налаштовуємо зворотне проксування
Як настроїти 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
Завдання:
Потрапляти з інтернету за посиланнямhttps://cloud.connect.link' (SSL) на Nextcloud у внутрішній мережі.
sudo ufw дозволити SSH
sudo ufw за умовчанням дозволяє вихідні
sudo ufw за замовчуванням забороняє вхідні
sudo ufw дозволити http
sudo ufw дозволити https
sudo ufw дозволити з ваш хост управління to any port 7080
sudo ufw enable
Налаштуємо 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/
Додаємо віртуалхост (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:
Застосувати 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, йдемо за посиланням https://cloud.connect.link і бачимо:
Щоб Nextcloud пустив нас, необхідно внести домен cloud.connect.link до списку довірених. Йдемо редагувати config.php. Nextcloud я ставив автоматично при встановленні Ubuntu і конфіг знаходиться тут: /var/snap/nextcloud/current/nextcloud/config.
Ключу trusted_domains додаємо параметр 'cloud.connect.link':
Далі, в тому ж конфізі треба вказати IP-адресу нашого проксі. Звертаю увагу, що адресу треба зазначити той, що видно серверу Nextcloud, тобто. ІР локального інтерфейсу LSWS. Без цього кроку працює веб-інтерфейс Nextcloud, але не авторизуються програми.
Відмінно, після цього ми можемо потрапити до інтерфейсу авторизації:
Завдання вирішено! Тепер кожен клієнт може безпечно користуватися «файловою хмарою» за своїм персональним url, сервер з файлами відокремлений від інтернету, майбутні клієнти отримають все те саме і жодна додаткова IP-адреса не постраждає.
Додатково можна використовувати reverse proxy для доставки статичного контенту, але у разі Nextcloud це не дасть відчутного збільшення швидкості. Тож це опціонально і за бажанням.
Радий поділитися цією історією, сподіваюся комусь буде корисно. Якщо ви знаєте витонченіші та ефективніші методи вирішення поставленого завдання – буду вдячний за коментарі!