Come configurare OpenLiteSpeed per il reverse proxy in Nextcloud, che si trova 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 server web degno. Lo amo per la sua velocità e l'interfaccia web di amministrazione elegante:
Nonostante OpenLiteSpeed sia più famoso come "acceleratore" di WordPress, nell'articolo di oggi mostrerò un'applicazione piuttosto specifica. Ossia il reverse proxy delle richieste. Direte che è più comune usare nginx? Concordo. Ma ci siamo affezionati a LSWS!
Proxying 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. Al contrario, proxyiamo le richieste attraverso un reverse proxy comune. Questa soluzione consente di:
1) rimuovere il server che ospita i dati del cliente da Internet e
2) risparmiare indirizzi IP.
Lo schema appare così:
È chiaro che lo schema è semplificato, poiché l'organizzazione dell'infrastruttura dei servizi web non è l'argomento dell'articolo odierno.
In questo articolo tralascerò anche l'installazione e la configurazione di base di Nextcloud, soprattutto perché su Habr sono disponibili materiali dedicati a questo argomento. Ma mostrerò sicuramente le impostazioni senza cui Nextcloud non funzionerà dietro un proxy.
Dati:
Nextcloud è installato sull'host 1 e configurato per funzionare in http (senza SSL), ha solo un'interfaccia di rete locale e un indirizzo IP "grigio" 172.16.22.110.
Configuriamo OpenLiteSpeed sull'host 2. Dispone di due interfacce, una esterna (che guarda verso Internet) e una interna con indirizzo IP nella rete 172.16.22.0/24
Il nome DNS collegato all'indirizzo IP dell'interfaccia esterna dell'host 2 è cloud.connect.link
Obiettivo:
Accedere da Internet tramite il link ‘‘ (SSL) a Nextcloud nella rete interna.
- Installiamo OpenLiteSpeed su Ubuntu 18.04.2.
Aggiungiamo il repository:
wget -O — |sudo bash
sudo apt-get update
installiamo, 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 l'URL di gestione
Login/password predefiniti: admin/123456
Aggiungiamo un virtual host (Virtual Hosts > Aggiungi).
Durante l'aggiunta apparirà un messaggio di errore – mancanza del file di configurazione. Questo è normale e si risolve cliccando su Crea.
Nella scheda Generale indichiamo Document Root (anche se non ci servirà, senza di esso la configurazione non funzionerà). Il nome del dominio, se non specificato, sarà preso dal nome del Virtual Host, che abbiamo chiamato col 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 proxy e dove. Nelle impostazioni del virtual host apriamo la scheda App esterne e aggiungiamo una nuova applicazione di tipo Web server:
Indichiamo un nome e un indirizzo. Il nome può essere scelto liberamente, ma è necessario ricordarlo, sarà utile 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 del passaggio precedente)
Riavviamo LSWS. Questo si fa con un clic dall'interfaccia web, meraviglie! (in me parla un erede di mouse)
- Installiamo il certificato, configuriamo https.
e supponiamo che lo abbiamo già e si trova insieme alla chiave nella directory /etc/letsencrypt/live/cloud.connect.link.
Creiamo un «ascoltatore» (Listeners > Aggiungi), lo chiameremo «https». Gli indicheremo la porta 443 e segneremo che sarà Sicuro:
Nella scheda SSL indichiamo il percorso della chiave e del certificato:
«Ascoltatore» creato, ora nella sezione Mappature Virtual Host aggiungiamo il nostro virtual host a questo:
Se LSWS proxy sarà solo a un servizio, l'impostazione può considerarsi conclusa. Ma noi intendiamo usarlo per inoltrare le richieste a diverse «istanze» a seconda del nome di dominio. E tutti i domini avranno i propri certificati. Pertanto, dobbiamo andare nel file di configurazione del virtual host e indicare di nuovo nella scheda SSL la sua chiave e il certificato. In futuro, questo dovrà essere fatto per ogni nuovo virtual host.
Resta da configurare la riscrittura dell'URL, affinché le richieste http vengano indirizzate a https.
(Tra l'altro, quando finirà tutto questo? È ora che i browser e altri software vadano di default su https e che l'inoltro su no-SSL avvenga manualmente se necessario).
Attiviamo Enable Rewrite e scriviamo le Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Non è possibile applicare le Rewrite rules durante il riavvio elegante a causa di un bizzarro malinteso. Pertanto, riavvieremo LSWS in modo poco elegante, ma efficiente:
sudo systemctl restart lsws.service
Affinché il server ascolti anche sulla porta 80, creeremo un ulteriore Listener. Lo chiameremo http, indicheremo la porta 80 e che non sarà sicuro:
Analogamente alla configurazione dell’http listener, lo mapperemo al nostro virtual host.
Ora LSWS ascolterà sulla porta 80 e reindirizzerà le richieste su 443, riscrivendo l'URL.
Infine, consiglio di ridurre il livello di logging di LSWS, che per impostazione predefinita è impostato su Debug. In questa modalità, i log si moltiplicano rapidamente! Per la maggior parte dei casi, è sufficiente un livello di Warning. Andiamo su Server Configuration > Log:
Con questo, la configurazione di OpenLiteSpeed come reverse proxy è completata. Riavviamo ancora una volta LSWS e andiamo al link e vediamo:
Affinché Nextcloud ci permetta di accedere, è 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' al campo trusted_domains:
'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
In seguito, nello stesso file di configurazione è necessario specificare l'indirizzo IP del nostro proxy. Voglio sottolineare che l'indirizzo deve essere quello visibile al server Nextcloud, cioè 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 di file" con il proprio URL personale, il server dei file è separato da internet, i futuri clienti riceveranno tutto lo stesso e nessun altro indirizzo IP verrà compromesso.
In aggiunta, è possibile utilizzare un reverse proxy per la consegna di contenuti statici, ma nel caso di Nextcloud non darà un incremento significativo della velocità. Quindi è facoltativo e a discrezione.
Sono felice di condividere questa storia, spero sia utile a qualcuno. Se conosci metodi più eleganti ed efficaci per risolvere il compito – sarei grato per i commenti!
Fonte: habr.com
