Hvordan opsætter man OpenLiteSpeed til reverse proxy i Nextcloud, der er i et internt netværk?
Overraskende nok giver en søgning på Habr efter OpenLiteSpeed ingenting! Jeg skynder mig at rette denne uretfærdighed, for LSWS er en værdig webserver. Jeg elsker den for sin hastighed og stilfulde webadministrationsgrænseflade:
Selvom OpenLiteSpeed er mest berømt som en "accelerator" for WordPress, vil jeg i dag vise en ret specifik anvendelse. Nemlig reverse proxy af forespørgsler. Du vil sige, at det er mere normalt at bruge nginx til dette? Jeg er enig. Men vi er simpelthen blevet så glade for LSWS!
Proxying er fint, men hvorhen? Til en lige så bemærkelsesværdig service - Nextcloud. Vi bruger Nextcloud til at oprette private "filudvekslingsskyer". For hver klient tildeler vi en separat VM med Nextcloud og ønsker ikke at eksponere dem "udefra". I stedet proxyser vi forespørgsler gennem en fælles reverse proxy. Denne løsning giver:
1) At fjerne serveren, hvor klientens data opbevares, fra internettet og
2) Spare på IP-adresser.
Diagrammet ser således ud:
Det er klart, at diagrammet er forenklet, da infrastrukturen for webtjenester ikke er temaet for denne artikel.
Jeg vil også i denne artikel udelade installation og grundlæggende opsætning af Nextcloud, især fordi der er materialer dedikeret til dette emne på Habr. Men jeg vil helt klart vise indstillingerne, uden hvilke Nextcloud ikke vil fungere bag en proxy.
Givet:
Nextcloud er installeret på vært 1 og er konfigureret til at køre via http (uden SSL), har kun et lokalt netværksinterface og en "grå" IP-adresse 172.16.22.110.
Lad os konfigurere OpenLiteSpeed på vært 2. Den har to interfaces, et eksternt (mod internettet) og et internt med IP-adressen i netværket 172.16.22.0/24.
På den eksterne interfaces IP-adresse på vært 2 fører DNS-navnet cloud.connect.link.
Opgave:
At få adgang til internettet via linket ‘‘ (SSL) til Nextcloud i det interne netværk.
- Installerer OpenLiteSpeed på Ubuntu 18.04.2.
Lad os tilføje et repository:
wget -O — |sudo bash
sudo apt-get update
installerer, starter:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Lad os minimalt konfigurere firewallen.
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 administrerende vært til enhver port 7080
sudo ufw enable - Lad os konfigurere OpenLiteSpeed som en reverse proxy.
Lad os oprette mapper til virtuel vært.cd /usr/local/lsws/
sudo mkdir cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Lad os konfigurere den virtuelle vært fra LSWS webgrænsefladen.
Åbner management URL
Standard login/password: admin/123456
Tilføjelse af virtuel vært (Virtual Hosts > Add).
Når du tilføjer, vises en fejlmeddelelse – manglen på en konfigurationsfil. Det er normalt og løses ved at klikke på Click to create.
Under fanen General angiver vi Document Root (selvom det ikke vil være nødvendigt, vil konfigurationen ikke fungere uden det). Domain Name vil blive taget fra Virtual Host Name, som vi kaldte navnet på vores domæne.
Nu er det tid til at huske, at vi ikke bare har en webserver, men en reverse proxy. De næste indstillinger vil fortælle LSWS, hvad der skal proxier og hvorhen. I indstillingerne for den virtuelle vært åbner vi fanen External App og tilføjer en ny applikation af typen Web server:
Vi angiver navn og adresse. Navnet kan være vilkårligt, men det er nødvendigt at huske, da det vil blive brugt i de næste trin. Adressen er den, hvor Nextcloud bor i det interne netværk:
I de samme indstillinger for den virtuelle vært åbner vi fanen Context og opretter en ny kontekst af typen Proxy:
Vi angiver parametre: URI = /, Web server = nextcloud_1 (navnet fra det forrige trin)
Vi genstarter LSWS. Dette gøres med et enkelt klik fra webgrænsefladen, mirakuløst! (Det er som en arv fra mine forfædre, der har arbejdet med computere)
- Vi installerer certifikatet og konfigurerer https.
springer vi over, lad os sige, at vi allerede har det og det ligger sammen med nøglen i mappen /etc/letsencrypt/live/cloud.connect.link.
Lad os oprette en 'lytter' (Listeners > Add), navngive den 'https'. Vi angiver den på port 443 og bemærker, at den vil være Secure:
Under fanen SSL angiver vi stien til nøglen og certifikatet:
'Listener'en er oprettet, nu i sektionen Virtual Host Mappings tilføjer vi vores virtuelle vært til den:
Hvis LSWS kun vil proxie til en service, kan indstillingen afsluttes. Men vi planlægger at bruge den til at viderebringe anmodninger til forskellige 'instanser' afhængigt af domænenavnet. Og alle domæner vil have deres egne certifikater. Derfor skal vi gå ind i konfigurationen af den virtuelle vært og igen angive dens nøgle og certifikat under fanen SSL. I fremtiden skal dette gøres for hver ny virtuel vært.
Det er tilbage at konfigurere URL-omskrivning, så http-anmodninger adresseres til https.
(Forresten, hvornår ender dette? Det er på tide, at browsere og andet software som standard går til https, og at omdirigering til no-SSL gøres manuelt ved behov).
Vi aktiverer Enable Rewrite og skriver Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Det er ikke muligt at anvende Rewrite rules ved en Graceful restart af en underlig grund. Derfor genstarter vi LSWS ikke elegant, men brutalt og effektivt:
sudo systemctl restart lsws.service
For at serveren kan lytte til port 80, opretter vi endnu en Listener. Vi kalder den http, angiver port 80, og at den ikke vil være sikker:
På samme måde som ved opsætning af https listener, knytter vi vores virtuelle host til den.
Nu vil LSWS lytte til port 80 og videresende anmodninger fra den til 443, ved at omskrive url'en.
Som afslutning anbefaler jeg at sænke niveauet for LSWS logging, som som standard er sat til Debug. I denne tilstand bliver loggene hurtigt enorme! For de fleste tilfælde er det tilstrækkeligt med niveauet Warning. Gå til Server Configuration > Log:
Så er konfigurationen af OpenLiteSpeed som en reverse proxy afsluttet. Igen genstarter vi LSWS, og går til linket og ser:
For at Nextcloud skal tillade os, er det nødvendigt at tilføje domænet cloud.connect.link til listen over betroede. Vi redigerer config.php. Jeg har installeret Nextcloud automatisk ved installation af Ubuntu, og konfigurationsfilen findes her: /var/snap/nextcloud/current/nextcloud/config.
Til parameteren trusted_domains tilføjer vi 'cloud.connect.link':
'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Dernæst skal vi i samme konfiguration angive IP-adressen på vores proxy. Jeg vil gerne påpege, at adressen skal være den, der er synlig for Nextcloud-serveren, dvs. IP-adressen for LSWS's lokale interface. Uden dette trin vil webgrænsefladen af Nextcloud fungere, men applikationer vil ikke kunne logge ind.
'trusted_proxies' =>
array (
0 => '172.16.22.100',
),
Fremragende, efter dette kan vi få adgang til login-grænsefladen:
Opgaven er løst! Nu kan hver kunde sikkert bruge 'filtjenesten' via deres personlige url, serveren med filerne er adskilt fra internettet, og fremtidige kunder vil få det samme, uden at nogen ekstra IP-adresser vil blive påvirket.
Derudover kan man bruge reverse proxy til at levere statisk indhold, men i tilfælde af Nextcloud vil det ikke give en mærkbar hastighedsforøgelse. Så det er valgfrit og efter behov.
Jeg er glad for at dele denne historie, og håber, den vil være nyttig for nogen. Hvis du kender mere elegante og effektive metoder til at løse den stillede opgave – ville jeg være taknemmelig for kommentarer!
Kilde: habr.com
