Nextcloud inuti, och utanför OpenLiteSpeed: vi konfigurerar för omvänd proxy

Hur man konfigurerar OpenLiteSpeed för omvänd proxy i Nextcloud som finns i det interna nätverket?

Förvånande nog ger sökningen på Habr för OpenLiteSpeed ingenting! Jag skyndar mig att rätta till denna orättvisa, eftersom LSWS är en värdig webbserver. Jag älskar den för sin hastighet och stiliga webbgränssnitt för administration:

Trots att OpenLiteSpeed mest är känt som en "accelerator" för WordPress, kommer jag i dagens artikel att visa en ganska specifik tillämpning av den. Nämligen omvänd proxy av förfrågningar. Du kanske säger att det är mer vanligt att använda nginx för detta? Jag håller med. Men vi har blivit så förtjusta i LSWS!

Proxyering är okej, men vart? Till en lika fantastisk tjänst – Nextcloud. Vi använder Nextcloud för att skapa privata "fildelande moln". För varje kund tilldelar vi en separat VM med Nextcloud och vill inte exponera dem "ute". Istället proxyar vi förfrågningarna genom en gemensam omvänd proxy. Den lösningen gör det möjligt att:
1) ta bort servern som lagrar kundens data från internet och
2) spara IP-adresser.

Skissen ser ut så här:

Det är uppenbart att skissen är förenklad, eftersom organisationen av infrastruktur för webbtjänster inte är ämnet för dagens artikel.

I denna artikel kommer jag också att hoppa över installation och grundläggande konfiguration av Nextcloud, särskilt eftersom det finns material på Habr som är dedikerade till detta ämne. Men jag kommer definitivt att visa inställningar utan vilka Nextcloud inte kommer att fungera bakom en proxy.

Givet:
Nextcloud är installerat på host 1 och konfigurerat att arbeta via http (utan SSL), har bara ett lokalt nätverksgränssnitt och "grå" IP-adress 172.16.22.110.
Vi konfigurerar OpenLiteSpeed på host 2. Den har två gränssnitt, en extern (som ser ut mot internet) och en intern med IP-adress i nätverket 172.16.22.0/24
DNS-namnet cloud.connect.link pekar på IP-adressen för det externa gränssnittet på host 2

Uppgift:
Att nå Nextcloud i det interna nätverket från internet via länken ‘https://cloud.connect.link‘ (SSL).

• Installera OpenLiteSpeed på Ubuntu 18.04.2.

Lägg till förrådet:

wget -O — http://rpms.litespeedtech.com/debian/enable_lst_debain_repo.sh |sudo bash
sudo apt-get update

installerar, startar:

sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start

• Minimal konfigurera brandväggen.
  

  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 din administrationsvärd till valfri port 7080
  sudo ufw enable

• Vi konfigurerar OpenLiteSpeed som en omvänd proxy.
  Skapa kataloger för virtuella värdar.

  cd /usr/local/lsws/
  sudo mkdir cloud.connect.link
  cd cloud.connect.link/
  sudo mkdir {conf,html,logs}
  sudo chown lsadm:lsadm ./conf/

Vi konfigurerar den virtuella värden via LSWS webbgränssnitt.
Öppna hanterings-URL http://cloud.connect.link:7080
Standard inloggning/lösenord: admin/123456

Lägg till virtuell värd (Virtual Hosts > Lägg till).
Vid tillägg kommer ett felmeddelande att visas – att konfigurationsfilen saknas. Det är normalt, löses genom att trycka på Click to create.

I fliken Allmänt anger vi Document Root (även om det inte behövs, utan det startar inte konfigurationen). Domännamn, om det inte anges, kommer att tas från Virtual Host Name, som vi kallade efter vårt domännamn.

Nu är det dags att komma ihåg att vi inte bara har en webbserver, utan en reverse proxy. Följande inställningar kommer att visa LSWS vad som ska proxas och vart. I inställningarna för den virtuella värden öppnar vi fliken External App och lägger till en ny applikation av typ Webbserver:

Ange namn och adress. Namnet kan vara valfritt, men du måste komma ihåg det, det kommer att vara användbart senare. Adressen är där Nextcloud finns i det interna nätverket:

I de samma inställningarna för den virtuella värden öppnar vi fliken Context och skapar en ny kontext av typ Proxy:

Ange parametrar: URI = /, Webbserver = nextcloud_1 (namn från föregående steg)

Starta om LSWS. Detta görs med ett enda klick från webbgränssnittet, underverk! (detta säger min härstamning av mus-flyttare)

• Installera certifikat, ställ in https.
  Vi hoppar över proceduren för att få certifikatet och enas om att vi redan har det och att det ligger tillsammans med nyckeln i katalogen /etc/letsencrypt/live/cloud.connect.link.

Skapa en 'listener' (Listeners > Lägg till), kalla den 'https'. Ange den för port 443 och markera att den ska vara Säker:

I fliken SSL anger vi sökvägen till nyckeln och certifikatet:

Listener har skapats, nu i avsnittet Virtual Host Mappings lägger vi till vår virtuella värd:

Om LSWS bara kommer att proxas till en tjänst kan inställningen slutföras. Men vi planerar att använda den för att vidarebefordra förfrågningar till olika 'instanser' beroende på domännamnet. Och alla domäner kommer att ha sina egna certifikat. Därför måste vi gå till konfigurationen av den virtuella värden och återigen ange i fliken SSL dess nyckel och certifikat. I framtiden måste detta göras för varje ny virtuell värd.

Det återstår att ställa in URL-omskrivning så att http-förfrågningar adresseras till https.
(Förresten, när slutar detta? Det är dags för webbläsare och annan programvara att som standard använda https, och att skicka till no-SSL manuellt vid behov).
Vi aktiverar Enable Rewrite och skriver Rewrite Rules:

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

Det går tyvärr inte att använda Rewrite-regler med Graceful restart av en bisarr anledning. Därför kommer vi att starta om LSWS på ett brutalt och effektivt sätt:

sudo systemctl restart lsws.service

För att servern ska lyssna på port 80 skapar vi ytterligare en Listener. Vi kallar den http, anger port 80 och att den inte är säker:

På samma sätt som med https listener, kopplar vi den till vår virtuella värd.

Nu kommer LSWS att lyssna på port 80 och dirigera förfrågningar från den till 443, genom att skriva om url:en.
Till sist rekommenderar jag att minska loggnivån för LSWS, som som standard är inställd på Debug. I det läget växer loggarna snabbt! För de flesta fall är loggnivån Warning tillräcklig. Vi går till Server Configuration > Log:

Med detta är konfigurationen av OpenLiteSpeed som en omvänd proxy avslutad. Vi startar om LSWS igen och går till länken https://cloud.connect.link och ser:

För att Nextcloud ska släppa in oss behöver vi lägga till domen cloud.connect.link i listan över betrodda. Vi går och redigerar config.php. Nextcloud installerade jag automatiskt vid installationen av Ubuntu och konfigurationen finns här: /var/snap/nextcloud/current/nextcloud/config.
Till trusted_domains lägger vi till parametrarna 'cloud.connect.link':

'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),

Därefter måste vi i samma konfiguration ange IP-adressen för vår proxy. Jag påpekar att adressen måste vara den som är synlig för Nextcloud-servern, dvs. IP-adressen för LSWS:s lokala gränssnitt. Utan detta steg fungerar webbläsargränssnittet för Nextcloud, men appar kan inte autentisera sig.

'trusted_proxies' =>
array (
0 => '172.16.22.100',
),

Utmärkt, efter detta kan vi komma in i autentiseringens gränssnitt:

Problemet är löst! Nu kan varje klient tryggt använda "filmolnet" via sin personliga url, servern med filer är separerad från internet, framtida klienter kommer att få samma sak och ingen extra IP-adress kommer att påverkas.
Dessutom kan man använda omvänd proxy för att leverera statiskt innehåll, men i fallet med Nextcloud ger det ingen märkbar hastighetsökning. Så det är valfritt.

Jag är glad att få dela denna berättelse, 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 den givna uppgiften - jag skulle uppskatta kommentarer!

Källa: habr.com