Jak skonfigurować OpenLiteSpeed do działania jako reverse proxy dla Nextcloud znajdującego się w wewnętrznej sieci?
To niesamowite, ale wyszukiwanie na Habrze po zapytaniu OpenLiteSpeed nie daje nic! Spieszę naprawić tę niesprawiedliwość, ponieważ LSWS to godny serwer webowy. Uwielbiam go za szybkość i nowoczesny interfejs administracyjny:
Mimo że OpenLiteSpeed jest najbardziej znany jako "przyspieszacz" WordPressa, w dzisiejszym artykule pokażę dość specyficzne jego zastosowanie. A mianowicie reverse proxy. Powiecie, że do tego przeważnie używa się nginx? Zgadzam się. Ale wyjątkowo polubiliśmy LSWS!
Proxy jest okej, ale dokąd? Do równie znakomitej usługi – Nextcloud. Używamy Nextcloud do tworzenia prywatnych „chmur wymiany plików”. Dla każdego klienta przydzielamy oddzielną VM z Nextcloud i nie chcemy ich wystawiać „na zewnątrz”. Zamiast tego przekierowujemy zapytania przez wspólne reverse proxy. To rozwiązanie pozwala:
1) usunąć serwer, na którym przechowywane są dane klienta, z internetu oraz
2) zaoszczędzić adresy IP.
Schemat wygląda tak:
Oczywiście schemat jest uproszczony, ponieważ organizacja infrastruktury usług webowych nie jest tematem dzisiejszego artykułu.
Również w tym artykule pominę instalację i podstawową konfigurację Nextcloud, tym bardziej że na Habrze znajdują się dedykowane temu materiały. Ale koniecznie pokażę ustawienia, bez których Nextcloud nie będzie działał za proxy.
Dane:
Nextcloud zainstalowany na hoście 1 i skonfigurowany do pracy przez http (bez SSL), ma tylko lokalny interfejs sieciowy oraz „szary” adres IP 172.16.22.110.
Skonfigurujemy OpenLiteSpeed na hoście 2. Posiada on dwa interfejsy, zewnętrzny (patrzy w internet) oraz wewnętrzny z adresem IP w sieci 172.16.22.0/24
Do adresu IP zewnętrznego interfejsu hosta 2 prowadzi DNS-owa nazwa cloud.connect.link
Zadanie:
Osiągnąć dostęp z internetu pod adresem ‘‘ (SSL) do Nextcloud w wewnętrznej sieci.
- Instalujemy OpenLiteSpeed na Ubuntu 18.04.2.
Dodamy repozytorium:
wget -O — |sudo bash
sudo apt-get update
instalujemy, uruchamiamy:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Minimalnie skonfigurujemy zaporę.
sudo ufw allow ssh
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw allow http
sudo ufw allow https
sudo ufw allow from twój adres zarządzania do dowolnego portu 7080
sudo ufw enable - Skonfigurujmy OpenLiteSpeed jako reverse proxy.
Utworzymy katalogi dla wirtualnego hosta.cd /usr/local/lsws/
sudo mkdir cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Skonfigurujemy wirtualny host z interfejsu webowego LSWS.
Otwórz zarządzanie URL
Domyślny login/hasło: admin/123456
Dodajemy wirtualny host (Virtual Hosts > Add).
Podczas dodawania pojawi się komunikat o błędzie - braku pliku konfiguracyjnego. To normalne, można to rozwiązać klikając Click to create.
Na zakładce General podajemy Document Root (choć nie będzie on potrzebny, bez niego konfiguracja się nie załaduje). Nazwa domeny, jeśli nie zostanie podana, zostanie wzięta z nazwy wirtualnego hosta, którą nazwaliśmy imieniem naszej domeny.
Czas przypomnieć sobie, że to nie tylko serwer webowy, ale również reverse proxy. Następujące ustawienia wskażą LSWS, co i dokąd ma prostatować. W ustawieniach wirtualnego hosta otwieramy zakładkę External App i dodajemy nową aplikację typu Web server:
Podajemy nazwę i adres. Nazwę można podać dowolną, ale należy ją zapamiętać, będzie przydatna w kolejnych krokach. Adres to ten, w którym znajduje się Nextcloud w wewnętrznej sieci:
W tych samych ustawieniach wirtualnego hosta otwieramy zakładkę Context i tworzymy nowy kontekst typu Proxy:
Podajemy parametry: URI = /, Web server = nextcloud_1 (nazwa z poprzedniego kroku)
Restartujemy LSWS. Można to zrobić jednym kliknięciem z interfejsu webowego, cuda! (w moim głosie mówi dziedziczny myszewoz)
- Instalujemy certyfikat, konfigurujemy https.
pomijamy, umówmy się, że już go mamy i leży razem z kluczem w katalogu /etc/letsencrypt/live/cloud.connect.link.
Utworzymy 'nasłuchiwacz' (Listeners > Add), nazwiemy go 'https'. Wskaźmy mu port 443 i zaznaczmy, że będzie Bezpieczny:
Na zakładce SSL podajemy ścieżkę do klucza i certyfikatu:
'Nasłuchiwacz' utworzony, teraz w sekcji Virtual Host Mappings dodamy do niego nasz wirtualny host:
Jeśli LSWS będzie prostatować tylko do jednego serwisu, można zakończyć konfigurację. Ale planujemy używać go do przekazywania zapytań do różnych 'instancji' w zależności od nazwy domeny. A wszystkie domeny będą miały swoje certyfikaty. Dlatego trzeba wejść do konfiguracji wirtualnego hosta i ponownie wskazać w zakładce SSL jego klucz i certyfikat. W przyszłości trzeba to robić dla każdego nowego wirtualnego hosta.
Pozostaje skonfigurować przepisanie URL, aby zapytania http były kierowane na https.
(Swoją drogą, kiedy to już się skończy? Czas, aby przeglądarki i inne oprogramowanie domyślnie korzystały z https, a przekierowania na no-SSL były robione ręcznie w razie potrzeby).
Włączamy Enable Rewrite i zapisujemy Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Nie można zastosować reguł Rewrite w zwykły sposób za pomocą Graceful restart z powodu dziwnego nieporozumienia. Dlatego zrestartujemy LSWS w sposób nieco brutalny, ale efektywny:
sudo systemctl restart lsws.service
Aby serwer nasłuchiwał na porcie 80, stworzymy jeszcze jeden Listener. Nazwiemy go http, wskażemy port 80 i ustawimy, że będzie niebezpieczny:
Analogicznie do konfiguracji listenera https, przypiszemy go naszemu wirtualnemu hoście.
Teraz LSWS będzie nasłuchiwał na porcie 80 i przekazywał żądania na port 443, przepisując url.
Na zakończenie zalecam obniżenie poziomu logowania LSWS, który domyślnie ustawiony jest na Debug. W takim trybie logi rozmnażają się błyskawicznie! W większości przypadków poziom Warning jest wystarczający. Przechodzimy do Server Configuration > Log:
Na tym konfiguracja OpenLiteSpeed jako odwrotnego proxy została zakończona. Jeszcze raz restartujemy LSWS i idziemy pod link i widzimy:
Aby Nextcloud nas wpuścił, musimy dodać domenę cloud.connect.link do listy zaufanych. Edytujemy plik config.php. Nextcloud zainstalowałem automatycznie podczas instalacji Ubuntu i konfiguracja znajduje się tutaj: /var/snap/nextcloud/current/nextcloud/config.
Do klucza trusted_domains dodajemy parametr 'cloud.connect.link':
'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Następnie w tej samej konfiguracji musimy wskazać adres IP naszego proxy. Zwracam uwagę, że adres musi być widoczny dla serwera Nextcloud, tzn. IP lokalnego interfejsu LSWS. Bez tego kroku działa interfejs webowy Nextcloud, ale aplikacje nie będą się autoryzować.
'trusted_proxies' =>
array (
0 => '172.16.22.100',
),
Świetnie, po tym możemy przejść do interfejsu logowania:
Zadanie zostało rozwiązane! Teraz każdy klient może bezpiecznie korzystać z "chmury plikowej" pod swoją osobistą url, serwer z plikami jest oddzielony od internetu, przyszli klienci dostaną to samo i żaden dodatkowy adres IP nie ucierpi.
Dodatkowo można użyć reverse proxy do dostarczania statycznych treści, ale w przypadku Nextcloud nie przyniesie to zauważalnego wzrostu prędkości. Więc jest to opcjonalne i zależy od życzenia.
Cieszę się, że mogłem podzielić się tą historią, mam nadzieję, że komuś się przyda. Jeśli znasz bardziej eleganckie i efektywne metody rozwiązania postawionego zadania – będę wdzięczny za komentarze!
Źródło: habr.com
