Si mund të konfiguroj OpenLiteSpeed për të kthyer proxy në Nextcloud në rrjetin e brendshëm?
Çuditërisht, një kërkim në Habré për OpenLiteSpeed nuk jep asgjë! Unë nxitoj ta korrigjoj këtë padrejtësi, sepse LSWS është një server i mirë në internet. Më pëlqen për shpejtësinë dhe ndërfaqen e zbukuruar të administrimit të uebit:
Edhe pse OpenLiteSpeed është më i famshëm si një "përshpejtues" i WordPress, në artikullin e sotëm do të tregoj një përdorim mjaft specifik të tij. Domethënë reverse proxying e kërkesave (reverse proxy). Ju thoni se është më e zakonshme të përdoret nginx për këtë? Unë do të pajtohem. Por dhemb aq shumë sa u dashuruam me LSWS!
Proxying është në rregull, por ku? Në shërbim jo më pak të mrekullueshëm - Nextcloud. Ne përdorim Nextcloud për të krijuar "retë e ndarjes së skedarëve" private. Për secilin klient, ne ndajmë një VM të veçantë me Nextcloud dhe nuk duam t'i ekspozojmë ato "jashtë". Në vend të kësaj, ne kërkojmë përfaqësues përmes një përfaqësuesi të përbashkët të kundërt. Kjo zgjidhje lejon:
1) hiqni serverin në të cilin ruhen të dhënat e klientit nga Interneti dhe
2) ruani adresat IP.
Skema duket kështu:
Është e qartë se skema është e thjeshtuar, sepse organizimi i infrastrukturës së shërbimeve të internetit nuk është tema e artikullit të sotëm.
Gjithashtu në këtë artikull do të heq instalimin dhe konfigurimin bazë të nextcloud, veçanërisht pasi ka materiale për këtë temë në Habré. Por unë patjetër do të tregoj cilësimet, pa të cilat Nextcloud nuk do të funksionojë pas një përfaqësuesi.
duke pasur parasysh:
Nextcloud është i instaluar në host 1 dhe i konfiguruar për të punuar mbi http (pa SSL), ka vetëm një ndërfaqe rrjeti lokal dhe një adresë IP "gri" 172.16.22.110.
Le të konfigurojmë OpenLiteSpeed në host 2. Ka dy ndërfaqe, të jashtme (duket në internet) dhe të brendshme me një adresë IP në rrjet 172.16.22.0/24
Adresa IP e ndërfaqes së jashtme të hostit 2 është emri DNS cloud.connect.link
Një detyrë:
Merr nga interneti përmes lidhjes '' (SSL) në Nextcloud në rrjetin e brendshëm.
- Instalimi i OpenLiteSpeed në Ubuntu 18.04.2.
Le të shtojmë një depo:
wget -O |sudo bash
sudo apt-get freskimin e
instaloni, ekzekutoni:
sudo apt-get instalo openlitespeed
nis sudo /usr/local/lsws/bin/lswsctrl
- Konfigurimi minimal i murit të zjarrit.
sudo ufw lejoni ssh
sudo ufw parazgjedhja lejon daljen
sudo ufw e paracaktuar mohon hyrjen
sudo ufw lejo http
sudo ufw lejonhttps
sudo ufw lejoj nga hosti juaj i menaxhimit në çdo port 7080
sudo ufw mundësohet - Konfiguro OpenLiteSpeed si një përfaqësues të kundërt.
Le të krijojmë drejtori nën virtualhost.cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Le të konfigurojmë hostin virtual nga ndërfaqja e internetit LSWS.
Hap menaxhimin e url-ve
Hyrja/fjalëkalimi i parazgjedhur: admin/123456
Shto një host virtual (Virtual Hosts > Shto).
Kur shtohet, do të shfaqet një mesazh gabimi - skedari i konfigurimit mungon. Kjo është normale, zgjidhet duke klikuar Kliko për të krijuar.
Në skedën e Përgjithshme, specifikoni rrënjën e dokumentit (edhe pse nuk është e nevojshme, konfigurimi nuk do të hiqet pa të). Emri i Domenit, nëse nuk specifikohet, do të merret nga Emri Virtual Host, të cilin ne e emërtuam emrin tonë të domenit.
Tani është koha të kujtojmë se ne nuk kemi vetëm një server në internet, por një përfaqësues të kundërt. Cilësimet e mëposhtme do t'i tregojnë LSWS se çfarë të proxy dhe ku. Në cilësimet e hostit virtual, hapni skedën "Aplikacioni i jashtëm" dhe shtoni një aplikacion të ri të llojit të serverit në internet:
Specifikoni emrin dhe adresën. Ju mund të specifikoni një emër arbitrar, por ju duhet ta mbani mend atë, ai do të jetë i dobishëm në hapat e ardhshëm. Adresa është ajo ku Nextcloud jeton në rrjetin e brendshëm:
Në të njëjtat cilësime të hostit virtual, hapni skedën Context dhe krijoni një kontekst të ri të llojit Proxy:
Specifikoni parametrat: URI = /, Web server = nextcloud_1 (emri nga hapi i mëparshëm)
Rinisni LSWS. Kjo bëhet me një klik nga ndërfaqja e internetit, mrekulli! (në mua flet një bartës i trashëguar i miut)
- Ne vendosim certifikatën, konfigurojmë https.
ne do ta heqim atë, do të pranojmë që tashmë e kemi atë dhe do të shtrihemi me çelësin në drejtorinë /etc/letsencrypt/live/cloud.connect.link.
Le të krijojmë një "dëgjues" (Dëgjuesit > Shto), le ta quajmë "https". Drejtojeni atë në portin 443 dhe vini re se do të jetë i sigurt:
Në skedën SSL, specifikoni rrugën drejt çelësit dhe certifikatës:
"Dëgjuesi" është krijuar, tani në seksionin Virtual Host Mappings ne do të shtojmë hostin tonë virtual në të:
Nëse LSWS do të proksojë vetëm një shërbim, konfigurimi mund të përfundojë. Por ne planifikojmë ta përdorim atë për të dërguar kërkesa në "instanca" të ndryshme në varësi të emrit të domenit. Dhe të gjitha domenet do të kenë certifikatat e tyre. Prandaj, duhet të shkoni te konfigurimi virtualhost dhe të specifikoni përsëri çelësin dhe certifikatën e tij në skedën SSL. Në të ardhmen, kjo duhet të bëhet për çdo host të ri virtual.
Mbetet për të konfiguruar rishkrimin e url-së në mënyrë që kërkesat http t'i adresohen https.
(Meqë ra fjala, kur do të përfundojë kjo? Është koha që shfletuesit dhe softuerët e tjerë të shkojnë në https si parazgjedhje dhe t'i përcjellin manualisht në no-SSL nëse është e nevojshme).
Aktivizoni Aktivizo Rishkrimin dhe shkruani Rregullat e Rishkrimit:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Për shkak të një keqkuptimi të çuditshëm, është e pamundur të zbatohen rregullat e Rewrite me rinisjen e zakonshme Graceful. Prandaj, ne do të rifillojmë LSWS-në jo me hijeshi, por me vrazhdësi dhe efikasitet:
sudo systemctl rinis lsws.service
Për ta bërë serverin të dëgjojë portin 80, le të krijojmë një Dëgjues tjetër. Le ta quajmë http, specifikojmë portin e 80-të dhe se do të jetë jo i sigurt:
Për analogji me cilësimin e dëgjuesit https, le t'i bashkojmë hostin tonë virtual.
Tani LSWS do të dëgjojë në portin 80 dhe do të dërgojë kërkesa në 443 prej saj, duke rishkruar url-në.
Si përfundim, unë rekomandoj uljen e nivelit të regjistrimit LSWS, i cili është vendosur në Debug si parazgjedhje. Në këtë mënyrë, shkrimet shumohen me shpejtësi rrufeje! Për shumicën e rasteve, niveli i paralajmërimit është i mjaftueshëm. Shkoni te Konfigurimi i Serverit > Regjistri:
Kjo përfundon konfigurimin e OpenLiteSpeed si një përfaqësues i kundërt. Edhe një herë, rinisni LSWS, ndiqni lidhjen dhe shiko:
Në mënyrë që Nextcloud të na lejojë të hyjmë, duhet të shtojmë domenin cloud.connect.link në listën e besuar. Le të shkojmë të modifikojmë config.php. Kam instaluar Nextcloud automatikisht kur instaloj Ubuntu dhe konfigurimi ndodhet këtu: /var/snap/nextcloud/current/nextcloud/config.
Shtoni parametrin "cloud.connect.link" te çelësi i trusted_domains:
'domains_të besuar' =>
grup (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Më tej, në të njëjtën konfigurim, duhet të specifikoni adresën IP të përfaqësuesit tonë. Unë tërheq vëmendjen tuaj për faktin se adresa duhet të specifikohet ajo që është e dukshme për serverin Nextcloud, d.m.th. IP e ndërfaqes lokale LSWS. Pa këtë hap, ndërfaqja në internet Nextcloud funksionon, por aplikacionet nuk autorizohen.
'proxies_i besuar' =>
grup (
0 => '172.16.22.100',
),
E shkëlqyeshme, pas kësaj ne mund të futemi në ndërfaqen e autorizimit:
Problemi u zgjidh! Tani çdo klient mund të përdorë në mënyrë të sigurt "renë e skedarit" në url-në e tij personale, serveri me skedarë është i ndarë nga Interneti, klientët e ardhshëm do të marrin gjithçka njësoj dhe asnjë adresë e vetme IP shtesë nuk do të ndikohet.
Për më tepër, mund të përdorni një përfaqësues të kundërt për të ofruar përmbajtje statike, por në rastin e Nextcloud, kjo nuk do të japë një rritje të dukshme të shpejtësisë. Pra, është fakultative dhe fakultative.
Më vjen mirë të ndaj këtë histori, shpresoj se do të jetë e dobishme për dikë. Nëse dini metoda më elegante dhe efikase për zgjidhjen e problemit, do t'ju jem mirënjohës për komentet!
Burimi: www.habr.com