Nextcloud binne en buite OpenLiteSpeed: stel omgekeerde proxying op
Hoe stel ek OpenLiteSpeed op om proxy om te keer na Nextcloud op die interne netwerk?
Verbasend genoeg gee 'n soektog op Habré vir OpenLiteSpeed niks nie! Ek haas my om hierdie onreg reg te stel, want LSWS is 'n ordentlike webbediener. Ek is mal daaroor vir sy spoed en fancy webadministrasie-koppelvlak:
Alhoewel OpenLiteSpeed die bekendste is as 'n WordPress "versneller", sal ek in vandag se artikel 'n taamlik spesifieke gebruik daarvan wys. Naamlik reverse proxying van versoeke (reverse proxy). Jy sê dat dit meer algemeen is om nginx hiervoor te gebruik? Ek sal saamstem. Maar dit maak so seer dat ons op LSWS verlief geraak het!
Volmag is ok, maar waar? In nie minder wonderlike diens nie - Nextcloud. Ons gebruik Nextcloud om private "file sharing wolke" te skep. Vir elke kliënt ken ons 'n aparte VM met Nextcloud toe, en ons wil hulle nie "buite" blootstel nie. In plaas daarvan vra ons volmagversoeke deur 'n algemene omgekeerde instaanbediener. Hierdie oplossing laat toe:
1) verwyder die bediener waarop die kliëntdata gestoor word van die internet af en
2) stoor ip-adresse.
Die skema lyk so:
Dit is duidelik dat die skema vereenvoudig is, want organisasie van webdienste-infrastruktuur is nie die onderwerp van vandag se artikel nie.
Ek sal ook in hierdie artikel die installasie en basiese konfigurasie van die nextcloud weglaat, veral aangesien daar materiaal oor hierdie onderwerp op Habré is. Maar ek sal beslis die instellings wys, waarsonder Nextcloud nie agter 'n instaanbediener sal werk nie.
Gegee:
Nextcloud is op gasheer 1 geïnstalleer en gekonfigureer om oor http te werk (sonder SSL), het slegs 'n plaaslike netwerkkoppelvlak en 'n "grys" IP-adres 172.16.22.110.
Kom ons konfigureer OpenLiteSpeed op gasheer 2. Dit het twee koppelvlakke, ekstern (kyk na die internet) en intern met 'n IP-adres op die netwerk 172.16.22.0/24
Gasheer 2 se eksterne koppelvlak-IP-adres is DNS-naam cloud.connect.link
'N Taak:
Kry van die internet af via die skakel 'https://cloud.connect.link' (SSL) na Nextcloud op die interne netwerk.
sudo apt-get installeer openlitespeed
sudo /usr/local/lsws/bin/lswsctrl begin
Minimale firewall-opstelling.
sudo ufw laat ssh toe
sudo ufw verstek laat uitgaande toe
sudo ufw verstek weier inkomende
sudo ufw laat http toe
sudo ufw toelaathttps
sudo ufw toelaat van jou bestuursgasheer na enige poort 7080
sudo ufw aktiveer
Stel OpenLiteSpeed op as 'n omgekeerde instaanbediener.
Kom ons skep gidse onder die virtuele gasheer.
cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Kom ons stel die virtuele gasheer op vanaf die LSWS-webkoppelvlak.
Maak URL-bestuur oop http://cloud.connect.link:7080
Verstek login/wagwoord: admin/123456
Voeg 'n virtuele gasheer by (Virtuele gashere > Voeg by).
Wanneer jy byvoeg, sal 'n foutboodskap verskyn - die konfigurasielêer ontbreek. Dit is normaal, opgelos deur te klik Klik om te skep.
In die Algemeen-oortjie, spesifiseer die dokumentwortel (alhoewel dit nie nodig is nie, sal die konfigurasie nie daarsonder begin nie). Die domeinnaam, indien nie gespesifiseer nie, sal geneem word van die virtuele gasheernaam, wat ons ons domeinnaam genoem het.
Nou is dit tyd om te onthou dat ons nie net 'n webbediener het nie, maar 'n omgekeerde instaanbediener. Die volgende instellings sal vir LSWS sê wat om te proxy en waar. In die virtualhost-instellings, maak die Eksterne toepassing-oortjie oop en voeg 'n nuwe toepassing van die tipe webbediener by:
Spesifiseer die naam en adres. Jy kan 'n arbitrêre naam spesifiseer, maar jy moet dit onthou, dit sal handig te pas kom in die volgende stappe. Die adres is die een waar Nextcloud in die interne netwerk woon:
In dieselfde virtuele gasheerinstellings, maak die Konteks-oortjie oop en skep 'n nuwe konteks van die Proxy-tipe:
Spesifiseer die parameters: URI = /, Webbediener = nextcloud_1 (naam van die vorige stap)
Herbegin LSWS. Dit word gedoen met een klik vanaf die webkoppelvlak, wonderwerke! ('n oorerflike muisdraer praat in my)
Ons sit die sertifikaat, stel https in. Die prosedure vir die verkryging van 'n sertifikaat ons sal dit weglaat, instem dat ons dit reeds het en met die sleutel in die /etc/letsencrypt/live/cloud.connect.link gids lê.
Kom ons skep 'n "luisteraar" (Luisteraars > Voeg by), kom ons noem dit "https". Wys dit na poort 443 en let daarop dat dit Veilig sal wees:
In die SSL-oortjie, spesifiseer die pad na die sleutel en sertifikaat:
Die "luisteraar" is geskep, nou sal ons in die Virtuele Gasheer Mappings-afdeling ons virtuele gasheer daarby voeg:
As LSWS slegs een diens sal instaan, kan die konfigurasie voltooi word. Maar ons beplan om dit te gebruik om versoeke na verskillende "gevalle" te stuur, afhangende van die domeinnaam. En alle domeine sal hul eie sertifikate hê. Daarom moet jy na die virtualhost-konfigurasie gaan en weer sy sleutel en sertifikaat in die SSL-oortjie spesifiseer. In die toekoms moet dit vir elke nuwe virtuele gasheer gedoen word.
Dit bly om url-herskrywing op te stel sodat http-versoeke aan https gerig word. (Terloops, wanneer sal dit eindig? Dit is tyd dat blaaiers en ander sagteware by verstek na https gaan, en indien nodig handmatig aanstuur na geen-SSL).
Skakel Aktiveer Herskryf aan en skryf Herskryfreëls:
Weens 'n vreemde misverstand is dit onmoontlik om Herskryf-reëls met die gewone Graceful-herbegin toe te pas. Daarom sal ons LSWS nie grasieus nie, maar onbeskof en doeltreffend herbegin:
sudo systemctl herbegin lsws.service
Om die bediener na poort 80 te laat luister, kom ons skep nog 'n luisteraar. Kom ons noem dit http, spesifiseer die 80ste poort en dat dit nie-veilig sal wees:
In analogie met die https-luisteraarinstelling, kom ons heg ons virtuele gasheer daaraan.
Nou sal LSWS op poort 80 luister en versoeke na 443 daaruit stuur, en die url herskryf.
Ten slotte beveel ek aan om die LSWS-aantekenvlak te verlaag, wat by verstek op Ontfouting gestel is. In hierdie modus vermeerder die stompe blitsvinnig! Vir die meeste gevalle is die Waarskuwingsvlak voldoende. Gaan na Bedienerkonfigurasie > Logboek:
Dit voltooi die konfigurasie van OpenLiteSpeed as 'n omgekeerde instaanbediener. Weereens, herbegin LSWS, volg die skakel https://cloud.connect.link En kyk:
Om Nextcloud ons in te laat, moet ons die cloud.connect.link-domein by die vertroude lys voeg. Kom ons gaan wysig config.php. Ek het Nextcloud outomaties geïnstalleer toe ek Ubuntu installeer en die config is hier geleë: /var/snap/nextcloud/current/nextcloud/config.
Voeg die 'cloud.connect.link'-parameter by die trusted_domains-sleutel:
Verder, in dieselfde konfigurasie, moet u die IP-adres van ons instaanbediener spesifiseer. Ek vestig u aandag daarop dat die adres gespesifiseer moet word die een wat vir die Nextcloud-bediener sigbaar is, m.a.w. Die IP van die plaaslike LSWS-koppelvlak. Sonder hierdie stap werk die Nextcloud-webkoppelvlak, maar toepassings word nie gemagtig nie.
Wonderlik, daarna kan ons in die magtigingskoppelvlak kom:
Probleem opgelos! Nou kan elke kliënt veilig die "lêerwolk" op sy eie persoonlike url gebruik, die bediener met lêers word van die internet geskei, toekomstige kliënte sal alles dieselfde ontvang en nie 'n enkele bykomende IP-adres sal geraak word nie.
Boonop kan u 'n omgekeerde instaanbediener gebruik om statiese inhoud te lewer, maar in die geval van Nextcloud sal dit nie 'n merkbare toename in spoed gee nie. Dit is dus opsioneel en opsioneel.
Ek is bly om hierdie storie te deel, ek hoop dit sal nuttig wees vir iemand. As jy meer elegante en doeltreffende metodes ken om die probleem op te los, sal ek dankbaar wees vir die kommentaar!