How do I set up OpenLiteSpeed to reverse proxy to Nextcloud on the internal network?
Surprisingly, a search on Habré for OpenLiteSpeed does not give anything! I hasten to correct this injustice, because LSWS is a decent web server. I love it for its speed and fancy web administration interface:
Even though OpenLiteSpeed is most famous as a WordPress "accelerator", in today's article I will show a rather specific use of it. Namely reverse proxying of requests (reverse proxy). You say that it is more common to use nginx for this? I will agree. But it hurts so much we fell in love with LSWS!
Proxying is ok, but where? In no less wonderful service - Nextcloud. We use Nextcloud to create private "file-sharing clouds". For each client, we allocate a separate VM with Nextcloud, and we don’t want to expose them “outside”. Instead, we proxy requests through a common reverse proxy. This solution allows:
1) remove the server on which the client data is stored from the Internet and
2) save ip-addresses.
The scheme looks like this:
It is clear that the scheme is simplified, because organization of web services infrastructure is not the topic of today's article.
Also in this article I will omit the installation and basic configuration of the nextcloud, especially since Habré has materials on this topic. But I will definitely show the settings, without which Nextcloud will not work behind a proxy.
Given:
Nextcloud is installed on host 1 and configured to work over http (without SSL), has only a local network interface and a "gray" IP address 172.16.22.110.
Let's configure OpenLiteSpeed on host 2. It has two interfaces, external (looks to the Internet) and internal with an IP address on the network 172.16.22.0/24
Host 2's external interface IP address is DNS name cloud.connect.link
Problem:
Get from the Internet via the link '' (SSL) to Nextcloud on the internal network.
- Installing OpenLiteSpeed on Ubuntu 18.04.2.
Let's add a repository:
wget -O |sudo bash
sudo apt-get update
install, run:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Minimal firewall setup.
sudo ufw allow ssh
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw allow http
sudo ufw allowhttps
sudo ufw allow from your management host to any port 7080
sudo ufw enable - Set up OpenLiteSpeed as a reverse proxy.
Let's create directories under the virtualhost.cd /usr/local/lsws/
sudo mkdirc cloud.connect.link
cd cloud.connect.link/
sudo mkdir {conf,html,logs}
sudo chown lsadm:lsadm ./conf/
Let's configure the virtual host from the LSWS web interface.
Open url management
Default login/password: admin/123456
Add a virtual host (Virtual Hosts > Add).
When adding, an error message will appear - the configuration file is missing. This is normal, solved by clicking Click to create.
In the General tab, specify the Document Root (although it is not needed, the config will not take off without it). The Domain Name, if not specified, will be taken from the Virtual Host Name, which we named our domain name.
Now it's time to remember that we have not just a web server, but a reverse proxy. The following settings will tell LSWS what to proxy and where. In the virtualhost settings, open the External App tab and add a new application of the Web server type:
Specify the name and address. You can specify an arbitrary name, but you need to remember it, it will come in handy in the next steps. The address is the one where Nextcloud lives in the internal network:
In the same virtual host settings, open the Context tab and create a new context of the Proxy type:
Specify the parameters: URI = /, Web server = nextcloud_1 (name from the previous step)
Restart LSWS. This is done with one click from the web interface, miracles! (a hereditary mouse carrier speaks in me)
- We put the certificate, configure https.
we will omit it, agree that we already have it and lie with the key in the /etc/letsencrypt/live/cloud.connect.link directory.
Let's create a "listener" (Listeners > Add), let's call it "https". Point it to port 443 and note that it will be Secure:
In the SSL tab, specify the path to the key and certificate:
The “listener” has been created, now in the Virtual Host Mappings section we will add our virtual host to it:
If LSWS will only proxy to one service, the configuration can be completed. But we plan to use it to send requests to different "instances" depending on the domain name. And all domains will have their own certificates. Therefore, you need to go to the virtualhost config and again specify its key and certificate in the SSL tab. In the future, this should be done for each new virtual host.
It remains to configure url rewriting so that http requests are addressed to https.
(By the way, when will this end? It's time for browsers and other software to go to https by default, and forward to no-SSL manually if necessary).
Turn on Enable Rewrite and write Rewrite Rules:
RewriteCond% {SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Due to a strange misunderstanding, it is impossible to apply Rewrite rules with the usual Graceful restart. Therefore, we will restart LSWS not gracefully, but rudely and efficiently:
sudo systemctl restart lsws.service
To make the server listen to port 80, let's create another Listener. Let's call it http, specify the 80th port and that it will be non-Secure:
By analogy with the https listener setting, let's attach our virtual host to it.
Now LSWS will listen on port 80 and send requests to 443 from it, rewriting the url.
In conclusion, I recommend lowering the LSWS logging level, which is set to Debug by default. In this mode, the logs multiply at lightning speed! For most cases, the Warning level is sufficient. Go to Server Configuration > Log:
This completes the configuration of OpenLiteSpeed as a reverse proxy. Once again, restart LSWS, follow the link and see:
In order for Nextcloud to let us in, we need to add the cloud.connect.link domain to the trusted list. Let's go edit config.php. I installed Nextcloud automatically when installing Ubuntu and the config is located here: /var/snap/nextcloud/current/nextcloud/config.
Add the 'cloud.connect.link' parameter to the trusted_domains key:
'trusted_domains' =>
array(
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Further, in the same config, you must specify the IP address of our proxy. I draw your attention to the fact that the address must be specified the one that is visible to the Nextcloud server, i.e. The IP of the local LSWS interface. Without this step, the Nextcloud web interface works, but applications are not authorized.
'trusted_proxies' =>
array(
0 => '172.16.22.100',
),
Great, after that we can get into the authorization interface:
Problem solved! Now each client can safely use the “file cloud” at his own personal url, the server with files is separated from the Internet, future clients will receive everything the same and not a single additional IP address will be affected.
Additionally, you can use a reverse proxy to deliver static content, but in the case of Nextcloud, this will not give a noticeable increase in speed. So it's optional and optional.
I am glad to share this story, I hope it will be useful to someone. If you know more elegant and efficient methods for solving the problem, I will be grateful for the comments!
Source: habr.com