Come configurare OpenLiteSpeed per il reverse proxy in Nextcloud, situato in una rete interna?
È sorprendente, ma la ricerca su Habr per la query OpenLiteSpeed non restituisce nulla! Mi affretto a correggere questa ingiustizia, poiché LSWS è un web server di tutto rispetto. Lo amo per la sua velocità e per l'elegante interfaccia web di amministrazione:
Nonostante OpenLiteSpeed sia più conosciuto come "acceleratore" per WordPress, nel presente articolo mostrerò un'applicazione piuttosto specifica. Ovvero, il reverse proxy delle richieste. Direte che per questo è più consueto usare nginx? Sono d'accordo. Ma ci siamo affezionati tanto a LSWS!
Il proxy va bene, ma dove? In un servizio altrettanto notevole – Nextcloud. Utilizziamo Nextcloud per creare "cloud privati di file sharing". Per ogni cliente dedichiamo una VM separata con Nextcloud e non vogliamo esporle "all'esterno". Invece, inoltriamo le richieste attraverso un reverse proxy comune. Questa soluzione consente di:
1) rimuovere il server su cui sono memorizzati i dati del cliente da Internet e
2) risparmiare indirizzi IP.
Lo schema appare così:
È chiaro che lo schema è semplificato, dato che l'organizzazione dell'infrastruttura dei servizi web non è l'argomento di oggi.
In questo articolo tralascerò l'installazione e la configurazione di base di Nextcloud, poiché su Habr ci sono materiali dedicati a questo tema. Tuttavia, mostrerò assolutamente le impostazioni senza le quali Nextcloud non funzionerà dietro un proxy.
Dati:
Nextcloud è installato sull'host 1 e configurato per funzionare tramite http (senza SSL), ha solo un'interfaccia di rete locale e un indirizzo IP ‘grigio’ 172.16.22.110.
Configurando OpenLiteSpeed sull'host 2. Ha due interfacce, una esterna (che guarda verso Internet) e una interna con un indirizzo IP nella rete 172.16.22.0/24.
L'hostname DNS che punta all'indirizzo IP dell'interfaccia esterna dell'host 2 è cloud.connect.link.
Obiettivo:
Accedere da Internet tramite il link ‘‘ (SSL) su Nextcloud nella rete interna.
- Installiamo OpenLiteSpeed su Ubuntu 18.04.2.
Aggiungiamo il repository:
wget -O — |sudo bash
sudo apt-get update
installiamo e avviamo:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Configuriamo minimamente il firewall.
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 il tuo host di gestione a qualsiasi porta 7080
sudo ufw enable - Configuriamo OpenLiteSpeed come reverse proxy.
Creiamo le directory per il virtual host.cd /usr/local/lsws/
sudo mkdir cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Configuriamo il virtual host tramite l'interfaccia web di LSWS.
Apriamo la gestione URL
Credenziali di accesso predefinite: admin/123456
Aggiungiamo un virtual host (Virtual Hosts > Add).
Durante l'aggiunta, potrebbe comparire un messaggio di errore riguardo l'assenza di un file di configurazione. Questo è normale e si risolve cliccando su Click to create.
Nella scheda Generale indichiamo il Document Root (anche se non sarà necessario, senza di esso la configurazione non funzionerà). Il Nome di Dominio, se non indicato, verrà preso dal Nome del Virtual Host, che abbiamo chiamato con il nome del nostro dominio.
Ora è il momento di ricordare che non abbiamo solo un server web, ma un reverse proxy. Le seguenti impostazioni indicheranno a LSWS cosa e dove proseguire con il proxy.
Indichiamo nome e indirizzo. Il nome può essere scelto liberamente, ma è importante ricordarlo, servirà nei passaggi successivi. L'indirizzo è quello in cui vive Nextcloud nella rete interna:
Nelle stesse impostazioni del virtual host, apriamo la scheda Context e creiamo un nuovo contesto di tipo Proxy:
Indichiamo i parametri: URI = /, Web server = nextcloud_1 (nome dal passo precedente)
Riavviamo LSWS. Questo si fa con un clic dall'interfaccia web, che meraviglia! (sta parlando il mouse di famiglia)
- Installiamo il certificato e configuriamo https.
Presumiamo che ce l'abbiamo già e che si trovi insieme alla chiave nella directory /etc/letsencrypt/live/cloud.connect.link.
Creiamo un 'listener' (Listeners > Aggiungi), lo chiameremo 'https'. Indicheremo la porta 443 e segneremo che sarà sicuro:
Nella scheda SSL indichiamo il percorso della chiave e del certificato:
'Listener' creato, ora nella sezione Virtual Host Mappings aggiungiamo il nostro virtual host:
Se LSWS deve fare da proxy per un solo servizio, possiamo terminare la configurazione. Ma prevediamo di usarlo per inoltrare richieste a diverse 'istanze' a seconda del nome del dominio. E ogni dominio avrà i suoi certificati. Quindi dobbiamo andare nella configurazione del virtual host e indicare di nuovo nella scheda SSL la sua chiave e il certificato. In futuro, questo deve essere fatto per ogni nuovo virtual host.
Resta da configurare la riscrittura dell'URL in modo che le richieste http vengano indirizzate a https.
(A proposito, quando finisce già tutto questo? È ora che i browser e altri software vadano di default su https, e la trasmissione su no-SSL venga fatta manualmente solo se necessario).
Attiviamo Enable Rewrite e scriviamo le Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Non è possibile applicare le regole di riscrittura con un riavvio graduale a causa di un bizzarro malinteso. Pertanto, riavvieremo LSWS in modo brusco ed efficace:
sudo systemctl restart lsws.service
Per far sì che il server ascolti anche sulla porta 80, creiamo un ulteriore Listener. Lo chiameremo http, indicheremo la porta 80 e specificheremo che non sarà sicuro:
Analogamente alla configurazione del listener https, lo assegneremo al nostro virtual host.
Ora LSWS ascolterà sulla porta 80 e reindirizzerà le richieste su 443, riscrivendo l'url.
Infine, consiglio di abbassare il livello di registrazione di LSWS, che per impostazione predefinita è configurato su Debug. In questa modalità i registri si moltiplicano rapidamente! Nella maggior parte dei casi, un livello di Warning è sufficiente. Andiamo su Server Configuration > Log:
Con questo, la configurazione di OpenLiteSpeed come reverse proxy è completata. Riavviamo LSWS ancora una volta e seguiamo il link e vediamo:
Per permettere a Nextcloud di accettarci, è necessario aggiungere il dominio cloud.connect.link all'elenco di fiducia. Andiamo a modificare config.php. Ho installato Nextcloud automaticamente durante l'installazione di Ubuntu e la configurazione si trova qui: /var/snap/nextcloud/current/nextcloud/config.
Aggiungiamo il parametro 'cloud.connect.link' alla chiave trusted_domains:
'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Dopo, nello stesso file di configurazione, è necessario indicare l'indirizzo IP del nostro proxy. Vorrei sottolineare che deve essere specificato l'indirizzo che è visibile al server Nextcloud, ovvero l'IP dell'interfaccia locale di LSWS. Senza questo passaggio, l'interfaccia web di Nextcloud funziona, ma le applicazioni non si autorizzano.
‘trusted_proxies’ =>
array (
0 => ‘172.16.22.100’,
),
Ottimo, dopo questo possiamo accedere all'interfaccia di autorizzazione:
Problema risolto! Ora ogni cliente può utilizzare in modo sicuro il "cloud dei file" attraverso il proprio url personale, il server con i file è separato da Internet, i futuri clienti riceveranno la stessa cosa e nessun indirizzo IP aggiuntivo soffrirà.
Inoltre, si può utilizzare un reverse proxy per la consegna di contenuti statici, ma nel caso di Nextcloud questo non fornirà un aumento significativo della velocità. Quindi è facoltativo e a discrezione.
Sono felice di condividere questa storia, spero sia utile per qualcuno. Se conoscete metodi più eleganti ed efficaci per risolvere il problema proposto, vi sarei grato per i vostri commenti!
Fonte: habr.com
