ProHoster > Блог > Administrado > Nextcloud ene kaj ekster OpenLiteSpeed: agordi inversan prokuradon
Nextcloud ene kaj ekster OpenLiteSpeed: agordi inversan prokuradon
Kiel mi agordas OpenLiteSpeed por inversigi prokurilon al Nextcloud en la interna reto?
Mirinde, serĉo ĉe Habré pri OpenLiteSpeed ne donas nenion! Mi rapidas korekti ĉi tiun maljustaĵon, ĉar LSWS estas deca retservilo. Mi amas ĝin pro ĝia rapideco kaj ŝika interfaco pri administrado de retejo:
Kvankam OpenLiteSpeed estas plej fama kiel WordPress "akcelilo", en la hodiaŭa artikolo mi montros sufiĉe specifan uzon de ĝi. Nome inversa prokurado de petoj (inversa prokurilo). Ĉu vi diras, ke estas pli ofta uzi nginx por ĉi tio? Mi konsentos. Sed doloras tiom, ke ni enamiĝis al LSWS!
Prokurado estas en ordo, sed kie? En ne malpli mirinda servo - Nextcloud. Ni uzas Nextcloud por krei privatajn "dosier-kundividajn nubojn". Por ĉiu kliento, ni asignas apartan VM kun Nextcloud, kaj ni ne volas elmontri ilin "ekstere". Anstataŭe, ni prokuraj petoj per komuna inversa prokurilo. Ĉi tiu solvo permesas:
1) forigi la servilon sur kiu la klientdatenoj estas stokitaj de la Interreto kaj
2) konservu ip-adresojn.
La diagramo aspektas tiel:
Estas klare, ke la skemo estas simpligita, ĉar organizo de retserva infrastrukturo ne estas la temo de la hodiaŭa artikolo.
Ankaŭ en ĉi tiu artikolo mi preterlasos la instaladon kaj bazan agordon de la sekva nubo, precipe ĉar Habré havas materialojn pri ĉi tiu temo. Sed mi certe montros la agordojn, sen kiuj Nextcloud ne funkcios malantaŭ prokurilo.
Donita:
Nextcloud estas instalita sur gastiganto 1 kaj agordita por funkcii per http (sen SSL), havas nur lokan retan interfacon kaj "grizan" IP-adreson 172.16.22.110.
Ni agordu OpenLiteSpeed sur la gastiganto 2. Ĝi havas du interfacojn, eksterajn (rigardas al Interreto) kaj internan kun IP-adreso en la reto 172.16.22.0/24.
La IP-adreso de ekstera interfaco de gastiganto 2 estas DNS-nomo cloud.connect.link
Tasko:
Akiru de la Interreto per la ligilo 'https://cloud.connect.link' (SSL) al Nextcloud en la interna reto.
sudo ufw permesas ssh
sudo ufw defaŭlta permesi eksiĝintan
sudo ufw default deny incoming
sudo ufw permesas http
sudo ufw allowhttps
sudo ufw allow from via mastruma gastiganto al iu ajn haveno 7080
sudo ufw ebligi
Agordu OpenLiteSpeed kiel inversan prokurilon.
Ni kreu dosierujojn sub la virtualhost.
cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {konf,html, protokoloj}
sudo chown lsadm:lsadm ./conf/
Ni agordu la virtualan gastiganton de la TTT-interfaco de LSWS.
Malfermu url-administradon http://cloud.connect.link:7080
Defaŭlta ensaluto/pasvorto: admin/123456
Aldonu virtualan gastiganton (Virtualaj Gastigantoj > Aldoni).
Aldonante, aperos erarmesaĝo - la agorda dosiero mankas. Ĉi tio estas normala, solvita alklakante Klaku por krei.
En la Ĝenerala langeto, specifu la Dokumentradikon (kvankam ĝi ne estas bezonata, la agordo ne ekflugos sen ĝi). La Domajna Nomo, se ne specifita, estos prenita de la Virtuala Gastiganto, kiun ni nomis nian domajnan nomon.
Nun estas tempo memori, ke ni havas ne nur retservilon, sed inversan prokurilon. La sekvaj agordoj diros al LSWS kion prokurigi kaj kie. En la agordoj de virtualhost, malfermu la langeton Eksteran Apon kaj aldonu novan aplikaĵon de la tipo de retservilo:
Indiku la nomon kaj adreson. Vi povas specifi arbitran nomon, sed vi devas memori ĝin, ĝi utilos en la sekvaj paŝoj. La adreso estas tiu, kie Nextcloud loĝas en la interna reto:
En la samaj agordoj de virtuala gastiganto, malfermu la langeton Kunteksto kaj kreu novan kuntekston de la tipo Proxy:
Indiku la parametrojn: URI = /, TTT-servilo = nextcloud_1 (nomo de la antaŭa paŝo)
Rekomencu LSWS. Ĉi tio estas farita per unu klako de la retinterfaco, mirakloj! (hereda musportisto parolas en mi)
Ni metas la atestilon, agordu https. La proceduro por akiri atestilon ni ellasos ĝin, konsentos, ke ni jam havas ĝin kaj kuŝas kun la ŝlosilo en la dosierujo /etc/letsencrypt/live/cloud.connect.link.
Ni kreu "aŭskultanton" (Aŭskultantoj > Aldoni), ni nomu ĝin "https". Montru ĝin al haveno 443 kaj notu, ke ĝi estos Sekura:
En la langeto SSL, specifu la vojon al la ŝlosilo kaj atestilo:
La "aŭskultanto" estis kreita, nun en la sekcio de Virtualaj Gastigantoj ni aldonos nian virtualan gastiganton al ĝi:
Se LSWS nur prokuros al unu servo, la agordo povas esti kompletigita. Sed ni planas uzi ĝin por sendi petojn al malsamaj "instancoj" depende de la domajna nomo. Kaj ĉiuj domajnoj havos siajn proprajn atestojn. Tial vi devas iri al la agordo de virtualhost kaj denove specifi ĝian ŝlosilon kaj atestilon en la langeto SSL. Estontece, ĉi tio devus esti farita por ĉiu nova virtuala gastiganto.
Restas agordi url-reskribon por ke http-petoj estu adresitaj al https. (Cetere, kiam ĉi tio finiĝos? Estas tempo por retumiloj kaj aliaj programaroj iri al https defaŭlte, kaj plusendi al ne-SSL permane se necese).
Ŝaltu Ebligu Reskribi kaj skribu Reskribi Regulojn:
Pro stranga miskompreno, estas neeble apliki Reskribi regulojn kun la kutima Graceful rekomenco. Tial ni rekomencos LSWS ne gracie, sed malĝentile kaj efike:
sudo systemctl rekomencu lsws.service
Por ke la servilo aŭskultu la havenon 80, ni kreu alian Aŭskultilon. Ni nomu ĝin http, specifu la 80-an havenon kaj ke ĝi estos ne-Sekura:
Analogie kun la agordo de https-aŭskultanto, ni aligu nian virtualan gastiganton al ĝi.
Nun LSWS aŭskultos sur la haveno 80 kaj sendos petojn al 443 de ĝi, reverkante la url.
Konklude, mi rekomendas malaltigi la nivelon de protokolado LSWS, kiu defaŭlte estas agordita al Sencimigi. En ĉi tiu reĝimo, la ŝtipoj multiĝas je fulmo! Plejofte, la Averta nivelo sufiĉas. Iru al Servilo-Agordo > Protokolo:
Ĉi tio kompletigas la agordon de OpenLiteSpeed kiel inversa prokurilo. Denove, rekomencu LSWS, sekvu la ligilon https://cloud.connect.link kaj vidu:
Por ke Nextcloud enlasu nin, ni devas aldoni la domajnon cloud.connect.link al la fidinda listo. Ni iru redakti config.php. Mi instalis Nextcloud aŭtomate kiam instalis Ubuntu kaj la agordo troviĝas ĉi tie: /var/snap/nextcloud/current/nextcloud/config.
Aldonu la parametron 'cloud.connect.link' al la ŝlosilo trusted_domains:
Plue, en la sama agordo, vi devas specifi la IP-adreson de nia prokurilo. Mi atentigas vin pri tio, ke la adreso devas esti specifita tiu, kiu estas videbla al la Nextcloud-servilo, t.e. La IP de la loka LSWS-interfaco. Sen ĉi tiu paŝo, la retejo de Nextcloud funkcias, sed aplikaĵoj ne estas rajtigitaj.
Bonege, post tio ni povas eniri la rajtigan interfacon:
Problemo solvita! Nun ĉiu kliento povas sekure uzi la "dosiernubon" ĉe sia propra persona url, la servilo kun dosieroj estas apartigita de la Interreto, estontaj klientoj ricevos ĉion same kaj eĉ ne unu kroma IP-adreso estos tuŝita.
Aldone, vi povas uzi inversan prokurilon por liveri senmovan enhavon, sed en la kazo de Nextcloud, ĉi tio ne donos rimarkindan pliiĝon de rapideco. Do ĝi estas laŭvola kaj laŭvola.
Mi ĝojas konigi ĉi tiun rakonton, mi esperas, ke ĝi estos utila al iu. Se vi konas pli elegantajn kaj efikajn metodojn por solvi la problemon, mi dankos la komentojn!