Hur ställer jag in OpenLiteSpeed för att vända proxy till Nextcloud på det interna nätverket?
Överraskande nog ger en sökning på Habré efter OpenLiteSpeed ingenting! Jag skyndar mig att rätta till denna orättvisa, eftersom LSWS är en anständig webbserver. Jag älskar det för dess snabbhet och snygga webbadministrationsgränssnitt:
Även om OpenLiteSpeed är mest känd som en WordPress "accelerator", kommer jag i dagens artikel att visa en ganska specifik användning av den. Nämligen reverse proxying av begäranden (reverse proxy). Du säger att det är vanligare att använda nginx för detta? Jag håller med. Men det gör så ont att vi blev kära i LSWS!
Fullmakt är ok, men var? I inte mindre underbar tjänst - Nextcloud. Vi använder Nextcloud för att skapa privata "fildelningsmoln". För varje klient tilldelar vi en separat virtuell dator med Nextcloud, och vi vill inte exponera dem "utanför". Istället begär vi fullmakt via en gemensam omvänd proxy. Denna lösning tillåter:
1) ta bort servern som klientdata lagras på från Internet och
2) spara ip-adresser.
Diagrammet ser ut så här:
Det är tydligt att systemet är förenklat, eftersom organisation av webbtjänsters infrastruktur är inte ämnet för dagens artikel.
Även i den här artikeln kommer jag att utelämna installationen och den grundläggande konfigurationen av nextcloud, särskilt eftersom det finns material om detta ämne på Habré. Men jag kommer definitivt att visa inställningarna, utan vilka Nextcloud inte fungerar bakom en proxy.
Given:
Nextcloud är installerat på värd 1 och konfigurerat att fungera över http (utan SSL), har bara ett lokalt nätverksgränssnitt och en "grå" IP-adress 172.16.22.110.
Låt oss konfigurera OpenLiteSpeed på värd 2. Den har två gränssnitt, extern (ser ut mot Internet) och intern med en IP-adress på nätverket 172.16.22.0/24
Host 2:s externa gränssnitts IP-adress är DNS-namnet cloud.connect.link
Uppgift:
Få från Internet via länken '' (SSL) till Nextcloud på det interna nätverket.
- Installera OpenLiteSpeed på Ubuntu 18.04.2.
Låt oss lägga till ett arkiv:
wget -O |sudo bash
sudo apt-get update
installera, kör:
sudo apt-get installera openlitespeed
sudo /usr/local/lsws/bin/lswsctrl startar
- Minimal brandväggsinstallation.
sudo ufw tillåter ssh
sudo ufw standard tillåter utgående
sudo ufw standard neka inkommande
sudo ufw tillåter http
sudo ufw tillåterhttps
sudo ufw tillåta från din ledningsvärd till valfri port 7080
sudo ufw aktivera - Ställ in OpenLiteSpeed som en omvänd proxy.
Låt oss skapa kataloger under virtualhost.cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Låt oss konfigurera den virtuella värden från LSWS webbgränssnitt.
Öppna webbadresshantering
Standardinloggning/lösenord: admin/123456
Lägg till en virtuell värd (Virtuella värdar > Lägg till).
När du lägger till visas ett felmeddelande - konfigurationsfilen saknas. Detta är normalt, löses genom att klicka på Klicka för att skapa.
På fliken Allmänt anger du dokumentroten (även om den inte behövs, kommer konfigurationen inte att starta utan den). Domännamnet, om det inte anges, kommer att tas från det virtuella värdnamnet, som vi döpte till vårt domännamn.
Nu är det dags att komma ihåg att vi inte bara har en webbserver, utan en omvänd proxy. Följande inställningar talar om för LSWS vad som ska proxy och var. I virtualhost-inställningarna, öppna fliken Extern app och lägg till en ny applikation av webbservertypen:
Ange namn och adress. Du kan ange ett godtyckligt namn, men du måste komma ihåg det, det kommer att vara användbart i nästa steg. Adressen är den där Nextcloud bor i det interna nätverket:
I samma virtuella värdinställningar, öppna fliken Kontext och skapa en ny kontext av typen proxy:
Ange parametrarna: URI = /, webbserver = nextcloud_1 (namn från föregående steg)
Starta om LSWS. Detta görs med ett klick från webbgränssnittet, mirakel! (en ärftlig musbärare talar i mig)
- Vi lägger certifikatet, konfigurerar https.
vi kommer att utelämna det, acceptera att vi redan har det och ligga med nyckeln i katalogen /etc/letsencrypt/live/cloud.connect.link.
Låt oss skapa en "lyssnare" (Lyssnare > Lägg till), låt oss kalla det "https". Peka på port 443 och notera att den kommer att vara säker:
På fliken SSL anger du sökvägen till nyckeln och certifikatet:
"Lyssnaren" har skapats, nu kommer vi att lägga till vår virtuella värd i avsnittet Virtual Host Mappings:
Om LSWS endast ger proxy till en tjänst kan konfigurationen slutföras. Men vi planerar att använda den för att skicka förfrågningar till olika "instanser" beroende på domännamn. Och alla domäner kommer att ha sina egna certifikat. Därför måste du gå till virtualhost-konfigurationen och återigen ange dess nyckel och certifikat på SSL-fliken. I framtiden bör detta göras för varje ny virtuell värd.
Det återstår att konfigurera url-omskrivning så att http-förfrågningar adresseras till https.
(Förresten, när tar detta slut? Det är dags för webbläsare och annan mjukvara att gå till https som standard och vidarebefordra till no-SSL manuellt om det behövs).
Slå på Aktivera omskrivning och skriv omskrivningsregler:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
På grund av ett konstigt missförstånd är det omöjligt att tillämpa Rewrite-regler med den vanliga Graceful-omstarten. Därför kommer vi att starta om LSWS inte graciöst, utan oförskämt och effektivt:
sudo systemctl starta om lsws.service
För att få servern att lyssna på port 80, låt oss skapa en annan lyssnare. Låt oss kalla det http, ange den 80:e porten och att den kommer att vara osäker:
I analogi med https-lyssnarinställningen, låt oss koppla vår virtuella värd till den.
Nu kommer LSWS att lyssna på port 80 och skicka förfrågningar till 443 från den och skriva om webbadressen.
Sammanfattningsvis rekommenderar jag att sänka LSWS-loggningsnivån, som är inställd på Debug som standard. I det här läget förökas stockarna blixtsnabbt! I de flesta fall är varningsnivån tillräcklig. Gå till Serverkonfiguration > Logg:
Detta slutför konfigurationen av OpenLiteSpeed som en omvänd proxy. Återigen, starta om LSWS, följ länken och se:
För att Nextcloud ska släppa in oss måste vi lägga till domänen cloud.connect.link till den betrodda listan. Låt oss redigera config.php. Jag installerade Nextcloud automatiskt när jag installerade Ubuntu och konfigurationen finns här: /var/snap/nextcloud/current/nextcloud/config.
Lägg till parametern 'cloud.connect.link' till nyckeln trusted_domains:
'trusted_domains' =>
array(
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Vidare, i samma konfiguration måste du ange IP-adressen för vår proxy. Jag uppmärksammar er på att adressen måste anges den som är synlig för Nextcloud-servern, d.v.s. IP:n för det lokala LSWS-gränssnittet. Utan detta steg fungerar Nextcloud webbgränssnitt, men applikationer är inte auktoriserade.
'trusted_proxies' =>
array(
0 => '172.16.22.100',
),
Bra, efter det kan vi komma in i behörighetsgränssnittet:
Problemet löst! Nu kan varje klient säkert använda "filmolnet" på sin egen personliga url, servern med filer är separerad från Internet, framtida klienter kommer att få allt likadant och inte en enda ytterligare IP-adress kommer att påverkas.
Dessutom kan du använda en omvänd proxy för att leverera statiskt innehåll, men i fallet med Nextcloud kommer detta inte att ge någon märkbar ökning av hastigheten. Så det är valfritt och valfritt.
Jag är glad att dela den här historien, jag hoppas att den kommer att vara användbar för någon. Om du känner till mer eleganta och effektiva metoder för att lösa problemet kommer jag att vara tacksam för kommentarerna!
Källa: will.com