Hvordan sætter jeg OpenLiteSpeed op til at vende proxy til Nextcloud på det interne netværk?
Overraskende nok giver en søgning på Habré efter OpenLiteSpeed ikke noget! Jeg skynder mig at rette op på denne uretfærdighed, fordi LSWS er en anstændig webserver. Jeg elsker det for dets hastighed og smarte webadministrationsgrænseflade:
Selvom OpenLiteSpeed er mest kendt som en WordPress "accelerator", vil jeg i dagens artikel vise en ret specifik brug af den. Nemlig reverse proxying af anmodninger (reverse proxy). Du siger, at det er mere almindeligt at bruge nginx til dette? Jeg er enig. Men det gør så ondt, at vi forelskede os i LSWS!
Fuldmagt er ok, men hvor? I ikke mindre vidunderlig service - Nextcloud. Vi bruger Nextcloud til at skabe private "fildelingsskyer". For hver klient tildeler vi en separat VM med Nextcloud, og vi ønsker ikke at eksponere dem "udenfor". I stedet anmoder vi om proxy via en fælles omvendt proxy. Denne løsning tillader:
1) fjerne serveren, som klientdataene er gemt på, fra internettet og
2) gem ip-adresser.
Diagrammet ser sådan ud:
Det er klart, at ordningen er forenklet, pga organisering af webserviceinfrastruktur er ikke emnet for dagens artikel.
Også i denne artikel vil jeg udelade installationen og den grundlæggende konfiguration af nextcloud, især da Habré har materialer om dette emne. Men jeg vil helt sikkert vise indstillingerne, uden hvilke Nextcloud ikke fungerer bag en proxy.
Givet:
Nextcloud er installeret på vært 1 og konfigureret til at arbejde over 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 grænseflader, ekstern (ser ud til internettet) og intern med en IP-adresse på netværket 172.16.22.0/24
Host 2's eksterne interface IP-adresse er DNS-navnet cloud.connect.link
Formål:
Få fra internettet via linket '' (SSL) til Nextcloud på det interne netværk.
- Installation af OpenLiteSpeed på Ubuntu 18.04.2.
Lad os tilføje et lager:
wget -O |sudo bash
sudo apt-get update
installer, kør:
sudo apt-get installer openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Minimal firewall opsætning.
sudo ufw tillader ssh
sudo ufw standard tillader udgående
sudo ufw standard nægte indgående
sudo ufw tillader http
sudo ufw tilladehttps
sudo ufw tillade fra din ledelsesvært til enhver port 7080
sudo ufw aktivere - Konfigurer OpenLiteSpeed som en omvendt proxy.
Lad os oprette mapper under den virtuelle vært.cd /usr/local/lsws/
sudo mkdirc 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.
Åbn url-administration
Standard login/adgangskode: admin/123456
Tilføj en virtuel vært (Virtuelle værter > Tilføj).
Ved tilføjelse vises en fejlmeddelelse - konfigurationsfilen mangler. Dette er normalt, løst ved at klikke på Klik for at oprette.
På fanen Generelt skal du angive dokumentroden (selvom den ikke er nødvendig, vil konfigurationen ikke starte uden den). Domænenavnet, hvis det ikke er angivet, vil blive taget fra det virtuelle værtsnavn, som vi gav vores domænenavn.
Nu er det tid til at huske, at vi ikke kun har en webserver, men en omvendt proxy. Følgende indstillinger fortæller LSWS, hvad der skal proxy, og hvor. I virtualhost-indstillingerne skal du åbne fanen Ekstern app og tilføje en ny applikation af webservertypen:
Angiv navn og adresse. Du kan angive et vilkårligt navn, men du skal huske det, det vil være nyttigt i de næste trin. Adressen er den, hvor Nextcloud bor i det interne netværk:
I de samme virtuelle værtsindstillinger skal du åbne fanen Kontekst og oprette en ny kontekst af Proxy-typen:
Angiv parametrene: URI = /, Webserver = nextcloud_1 (navn fra forrige trin)
Genstart LSWS. Dette gøres med et enkelt klik fra webgrænsefladen, mirakler! (en arvelig musebærer taler i mig)
- Vi sætter certifikatet, konfigurer https.
vi vil udelade det, acceptere at vi allerede har det og ligge med nøglen i mappen /etc/letsencrypt/live/cloud.connect.link.
Lad os oprette en "lytter" (Lyttere > Tilføj), lad os kalde det "https". Peg den til port 443 og bemærk, at den vil være sikker:
På fanen SSL skal du angive stien til nøglen og certifikatet:
"Lytteren" er blevet oprettet, nu vil vi i afsnittet Virtual Host Mappings tilføje vores virtuelle vært til den:
Hvis LSWS kun vil proxy til én tjeneste, kan konfigurationen fuldføres. Men vi planlægger at bruge det til at sende anmodninger til forskellige "instanser" afhængigt af domænenavnet. Og alle domæner vil have deres egne certifikater. Derfor skal du gå til den virtuelle værtskonfiguration og igen angive dens nøgle og certifikat på fanen SSL. I fremtiden bør dette gøres for hver ny virtuel vært.
Det er tilbage at konfigurere url-omskrivning, så http-anmodninger adresseres til https.
(Hvornår ender det i øvrigt? Det er på tide, at browsere og anden software går til https som standard og videresender manuelt til no-SSL, hvis det er nødvendigt).
Slå Aktiver omskrivning til og skriv omskrivningsregler:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
På grund af en mærkelig misforståelse er det umuligt at anvende Rewrite-regler med den sædvanlige Graceful genstart. Derfor vil vi genstarte LSWS ikke yndefuldt, men uhøfligt og effektivt:
sudo systemctl genstart lsws.service
For at få serveren til at lytte til port 80, lad os oprette en anden lytter. Lad os kalde det http, angiv den 80. port, og at det vil være ikke-sikkert:
I analogi med https-lytterindstillingen, lad os knytte vores virtuelle vært til den.
Nu vil LSWS lytte på port 80 og sende anmodninger til 443 fra den og omskrive url'en.
Afslutningsvis anbefaler jeg at sænke LSWS-logningsniveauet, som er indstillet til Debug som standard. I denne tilstand formerer logfilerne sig med lynets hast! I de fleste tilfælde er advarselsniveauet tilstrækkeligt. Gå til Serverkonfiguration > Log:
Dette fuldender konfigurationen af OpenLiteSpeed som en omvendt proxy. Endnu en gang, genstart LSWS, følg linket og se:
For at Nextcloud kan lukke os ind, skal vi tilføje cloud.connect.link-domænet til listen over betroede. Lad os gå i gang med at redigere config.php. Jeg installerede Nextcloud automatisk, da jeg installerede Ubuntu, og konfigurationen er placeret her: /var/snap/nextcloud/current/nextcloud/config.
Tilføj parameteren 'cloud.connect.link' til nøglen Trusted_domains:
'trusted_domains' =>
array(
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Yderligere skal du i den samme konfiguration angive IP-adressen på vores proxy. Jeg gør opmærksom på, at adressen skal angives den, der er synlig for Nextcloud-serveren, dvs. IP-adressen for den lokale LSWS-grænseflade. Uden dette trin fungerer Nextcloud-webgrænsefladen, men applikationer er ikke godkendte.
'trusted_proxies' =>
array(
0 => '172.16.22.100',
),
Fantastisk, derefter kan vi komme ind i godkendelsesgrænsefladen:
Problem løst! Nu kan hver klient trygt bruge "filskyen" på sin egen personlige url, serveren med filer er adskilt fra internettet, fremtidige klienter vil modtage alt det samme, og ikke en eneste ekstra IP-adresse vil blive påvirket.
Derudover kan du bruge en omvendt proxy til at levere statisk indhold, men i Nextclouds tilfælde vil dette ikke give en mærkbar stigning i hastigheden. Så det er valgfrit og valgfrit.
Jeg er glad for at dele denne historie, jeg håber, den vil være nyttig for nogen. Hvis du kender mere elegante og effektive metoder til at løse problemet, vil jeg være taknemmelig for kommentarerne!
Kilde: www.habr.com