Jak skonfigurować OpenLiteSpeed do odwrotnego proxy do Nextcloud w sieci wewnętrznej?
Co zaskakujące, wyszukiwanie w Habré dla OpenLiteSpeed nic nie daje! Spieszę naprawić tę niesprawiedliwość, ponieważ LSWS to porządny serwer WWW. Uwielbiam go za szybkość i fantazyjny interfejs do zarządzania siecią:
Choć OpenLiteSpeed jest najbardziej znany jako „akcelerator” WordPressa, w dzisiejszym artykule pokażę jego dość specyficzne zastosowanie. Mianowicie odwrotne proxy żądań (reverse proxy). Mówisz, że częściej używa się do tego nginx? Zgodzę się. Ale to boli tak bardzo, że zakochaliśmy się w LSWS!
Proxy jest ok, ale gdzie? W nie mniej wspaniałej usłudze - Nextcloud. Używamy Nextcloud do tworzenia prywatnych „chmur do udostępniania plików”. Każdemu klientowi przydzielamy osobną maszynę wirtualną z Nextcloud i nie chcemy ich wystawiać „na zewnątrz”. Zamiast tego obsługujemy żądania za pośrednictwem wspólnego odwrotnego serwera proxy. To rozwiązanie umożliwia:
1) usunięcia z sieci Internet serwera, na którym przechowywane są dane Klienta
2) zapisz adresy IP.
Schemat wygląda tak:
Oczywiste jest, że schemat jest uproszczony, ponieważ organizacja infrastruktury usług sieciowych nie jest tematem dzisiejszego artykułu.
Również w tym artykule pominę instalację i podstawową konfigurację nextclouda, tym bardziej, że Habré ma materiały na ten temat. Ale na pewno pokażę ustawienia, bez których Nextcloud nie będzie działać za proxy.
Biorąc pod uwagę:
Nextcloud jest zainstalowany na hoście 1 i skonfigurowany do pracy przez http (bez SSL), ma tylko lokalny interfejs sieciowy i „szary” adres IP 172.16.22.110.
Skonfigurujmy OpenLiteSpeed na hoście 2. Ma dwa interfejsy, zewnętrzny (wygląda na Internet) i wewnętrzny z adresem IP w sieci 172.16.22.0/24
Adres IP zewnętrznego interfejsu hosta 2 to nazwa DNS cloud.connect.link
Zadanie:
Pobierz z Internetu za pomocą łącza „' (SSL) do Nextcloud w sieci wewnętrznej.
- Instalowanie OpenLiteSpeed na Ubuntu 18.04.2.
Dodajmy repozytorium:
wget -O |sudobash
sudo apt-get update
zainstalować, uruchomić:
sudo apt-get zainstaluj openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Minimalna konfiguracja zapory.
sudo ufw zezwól ssh
sudo ufw domyślnie zezwala na wychodzące
Sudo ufw domyślnie odrzuca przychodzące
sudo ufw zezwalaj na http
sudo ufw zezwala na https
sudo ufw zezwól z Twój host zarządzający do dowolnego portu 7080
sudo ufw włącz - Skonfiguruj OpenLiteSpeed jako odwrotne proxy.
Stwórzmy katalogi pod virtualhost.cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Skonfigurujmy wirtualnego hosta z interfejsu internetowego LSWS.
Otwórz zarządzanie adresami URL
Domyślny login/hasło: admin/123456
Dodaj wirtualnego hosta (Hosty wirtualne > Dodaj).
Podczas dodawania pojawi się komunikat o błędzie - brak pliku konfiguracyjnego. Jest to normalne, rozwiązane przez kliknięcie Kliknij, aby utworzyć.
W zakładce General określ Document Root (chociaż nie jest to potrzebne, konfiguracja nie wystartuje bez niego). Nazwa domeny, jeśli nie zostanie określona, zostanie zaczerpnięta z nazwy wirtualnego hosta, którą nazwaliśmy naszą domeną.
Teraz nadszedł czas, aby pamiętać, że mamy nie tylko serwer WWW, ale odwrotne proxy. Poniższe ustawienia powiedzą LSWS, co ma być proxy i gdzie. W ustawieniach virtualhost otwórz zakładkę External App i dodaj nową aplikację typu Web server:
Podaj nazwę i adres. Możesz podać dowolną nazwę, ale musisz ją zapamiętać, przyda się w kolejnych krokach. Adres to ten, pod którym Nextcloud mieszka w sieci wewnętrznej:
W tych samych ustawieniach virtualhost otwórz zakładkę Kontekst i utwórz nowy kontekst typu Proxy:
Określ parametry: URI = /, Web server = nextcloud_1 (nazwa z poprzedniego kroku)
Uruchom ponownie LSWS. Odbywa się to jednym kliknięciem z interfejsu internetowego, cuda! (mówi we mnie dziedziczny nosiciel myszy)
- Umieszczamy certyfikat, konfigurujemy https.
pominiemy go, zgodzimy się, że już go mamy i leżymy z kluczem w katalogu /etc/letsencrypt/live/cloud.connect.link.
Stwórzmy „listenera” (Listeners > Add), nazwijmy go „https”. Skieruj go na port 443 i zwróć uwagę, że będzie bezpieczny:
W zakładce SSL określ ścieżkę do klucza i certyfikatu:
„Nasłuchiwacz” został utworzony, teraz w sekcji Virtual Host Mappings dodamy do niego naszego wirtualnego hosta:
Jeśli LSWS będzie pośredniczyć tylko w jednej usłudze, konfiguracja może zostać zakończona. Ale planujemy użyć go do wysyłania żądań do różnych „instancji” w zależności od nazwy domeny. Wszystkie domeny będą miały własne certyfikaty. W związku z tym należy przejść do konfiguracji wirtualnego hosta i ponownie określić jego klucz oraz certyfikat w zakładce SSL. W przyszłości należy to zrobić dla każdego nowego hosta wirtualnego.
Pozostaje skonfigurować przepisywanie adresów URL, aby żądania http były adresowane do https.
(Nawiasem mówiąc, kiedy to się skończy? Nadszedł czas, aby przeglądarki i inne oprogramowanie domyślnie przechodziły na protokół HTTPS iw razie potrzeby ręcznie przekierowywały do trybu bez SSL).
Włącz Włącz przepisywanie i zapisuj reguły przepisywania:
PrzepiszCond %{SERVER_PORT} 80
Przepisz regułę ^(.*)$ } [R=301,L]
Z powodu dziwnego nieporozumienia niemożliwe jest zastosowanie reguł Rewrite przy zwykłym restarcie Graceful. Dlatego zrestartujemy LSWS nie z wdziękiem, ale niegrzecznie i skutecznie:
sudo systemctl uruchom ponownie lsws.service
Aby serwer nasłuchiwał na porcie 80, utwórzmy kolejny odbiornik. Nazwijmy to http, podaj 80. port i że będzie niezabezpieczony:
Analogicznie do ustawienia https listener podepnijmy do niego naszego wirtualnego hosta.
Teraz LSWS będzie nasłuchiwał na porcie 80 i wysyłał z niego żądania do 443, przepisując adres URL.
Podsumowując, zalecam obniżenie poziomu logowania LSWS, który domyślnie jest ustawiony na Debugowanie. W tym trybie kłody mnożą się z prędkością błyskawicy! W większości przypadków poziom Ostrzeżenie jest wystarczający. Przejdź do Konfiguracja serwera > Dziennik:
To kończy konfigurację OpenLiteSpeed jako odwrotnego proxy. Jeszcze raz uruchom ponownie LSWS, skorzystaj z łącza i zobaczyć:
Aby Nextcloud nas wpuścił, musimy dodać domenę cloud.connect.link do listy zaufanych. Chodźmy edytować plik config.php. Zainstalowałem Nextcloud automatycznie podczas instalacji Ubuntu, a konfiguracja znajduje się tutaj: /var/snap/nextcloud/current/nextcloud/config.
Dodaj parametr „cloud.connect.link” do klucza trust_domains:
'zaufane_domeny' =>
tablica (
0 => „172.16.22.110”,
1 => 'cloud.connect.link',
),
Ponadto w tej samej konfiguracji musisz podać adres IP naszego serwera proxy. Zwracam uwagę, że należy podać adres widoczny dla serwera Nextcloud, tj. Adres IP lokalnego interfejsu LSWS. Bez tego kroku interfejs sieciowy Nextcloud działa, ale aplikacje nie są autoryzowane.
'zaufane_proxy' =>
tablica (
0 => „172.16.22.100”,
),
Świetnie, po tym możemy przejść do interfejsu autoryzacji:
Problem rozwiązany! Teraz każdy klient może bezpiecznie korzystać z „chmury plików” pod swoim osobistym adresem URL, serwer z plikami jest oddzielony od Internetu, przyszli klienci otrzymają wszystko tak samo i nie wpłynie to na ani jeden dodatkowy adres IP.
Dodatkowo można użyć odwrotnego proxy do dostarczania treści statycznych, ale w przypadku Nextcloud nie da to zauważalnego wzrostu prędkości. Jest to więc opcjonalne i opcjonalne.
Cieszę się, że mogę podzielić się tą historią, mam nadzieję, że komuś się przyda. Jeśli znasz bardziej eleganckie i wydajne metody rozwiązania problemu, będę wdzięczny za komentarze!
Źródło: www.habr.com