Nextcloud inside and outside OpenLiteSpeed: set up reverse proxying

How to configure OpenLiteSpeed ​​for reverse proxying in Nextcloud located 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 trendy web administration interface:

Despite the fact that OpenLiteSpeed ​​is most famous as the “accelerator” of WordPress, in today's article I will show a rather specific application of it. Namely reverse proxying requests (reverse proxy). You will say that you are more accustomed to using nginx for this? I will agree. But it really hurts us to love LSWS!

Proxy ok, but where? At least a great service - Nextcloud. We use Nextcloud to create private file-sharing clouds. For each client, we allocate a separate VM with Nextcloud, and do not want to expose them "outside." Instead, we proxify requests through a common reverse proxy. This solution allows:

1. remove the server on which 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 The organization of web services infrastructure is not the topic of today's article.

Also in this article I will omit the installation and basic setting of the nexclock, especially since there are materials on this topic on Habré. But I will definitely show the settings, without which Nextcloud will not work for a proxy.

It is given: Nextcloud is installed on host 1 and configured to work over http (without SSL), it has only a local network interface and a “gray” IP address 172.16.22.110.

Configure OpenLiteSpeed ​​on host 2. It has two interfaces, an external one (looking at the Internet) and an internal one with an IP address on the network 172.16.22.0/24

The DNS-name of the cloud.connect.link is stored on the IP address of the host’s external interface

Task: to get from the Internet via the link ' https://cloud.connect.link ' (SSL) to Nextcloud in the internal network.

• Install OpenLiteSpeed ​​on Ubuntu 04/18/.2.

Add a repository:

wget -O - http://rpms.litespeedtech.com/debian/enable_lst_debain_repo.sh | sudo bash
sudo apt-get update

set, run:

sudo apt-get install openlitespeed
sudo / usr / local / lsws / bin / lswsctrl start

• Minimally configure the firewall.
  

  sudo ufw allow ssh
  sudo ufw default allow out out
  sudo ufw default deny incoming
  sudo ufw allow http
  sudo ufw allow https
  sudo ufw allow from your host management to any port 7080
  sudo ufw enable
  

• Configure OpenLiteSpeed ​​as a reverse proxy.
  Create directories for virtualhost.
  

  cd / usr / local / lsws /
  sudo mkdirc cloud.connect.link
  cd cloud.connect.link/
  sudo mkdir {conf, html, logs}
  sudo chown lsadm: lsadm ./conf/
  

Configure virtualhost from the LSWS web interface.
Open management url http://cloud.connect.link:7080
Default login / password: admin / 123456

Add virtualhost (Virtual Hosts> Add).

When adding, an error message appears - there is no configuration file. This is normal, is solved by clicking Click to create.

In the General tab, specify the Document Root (although it is not needed, without it, the config will not take off). Domain Name, if not specified, will be taken from the Virtual Host Name, which we called the name of our domain.

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. The name can be arbitrary, but it must be remembered, it will come in handy in the next steps. The address is where Nextcloud lives on the internal network:

In the same virtualhost 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, wonders! (he says in me hereditary little mouse)

• We put the certificate, set up https.
  We will omit the procedure for obtaining a certificate , agree that we already have it and it lies with the key in the /etc/letsencrypt/live/cloud.connect.link directory.

Create a “listener” (Listeners> Add), let's call it “https”. We 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 section Virtual Host Mappings we will add our virtualhost to it:

If LSWS proxies only to one service, the configuration can be terminated. 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 configuration and again specify its key and certificate in the SSL tab. In the future, this should be done for each new virtualhost.

It remains to configure the url rewrite so that http requests are sent to https.

(By the way, when will it end? It’s time for browsers and other software to go to https by default, and transfer to no-SSL manually if necessary).
Enable Enable Rewrite and write Rewrite Rules:

RewriteCond% {SERVER_PORT} 80
RewriteRule ^ (. *) $ Https: //% {SERVER_NAME}% {REQUEST_URI } [R = 301, L]

Apply Rewrite rules to the usual Graceful restart due to a strange misunderstanding. Therefore, restart LSWS not gracefully, but roughly and efficiently:

sudo systemctl restart lsws.service

To make the server listen to port 80, we will create another Listener. Let's call it http, specify the 80th port and the fact that it will be non-secure:

By analogy with the setting https listener, we attach our virtualhost to it.

Now LSWS will listen to port 80 and send requests from it to 443, rewriting the url.
In conclusion, I recommend reducing the logging level of LSWS, which is set by default as Debug. 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, we restart LSWS, follow the link https://cloud.connect.link and see:

In order for Nextcloud to let us in, you need to add the cloud.connect.link domain to the trusted list. Go to edit config.php. Nextcloud I put automatically when installing Ubuntu and the config is here: / var / snap / nextcloud / current / nextcloud / config.

To the key trusted_domains add the 'cloud.connect.link' parameter:

'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 the one that is visible to the Nextcloud server, i.e. The local interface LSWS IP. Without this step, the Nextcloud web interface works, but applications are not authorized.

'trusted_proxies' =>
array (
0 => '172.16.22.100',
),

Ok, after that we can get to the login interface:

Problem solved! Now each client can safely use the “file cloud” by his personal url, the server with the files is separated from the Internet, future clients will receive all the same and no additional IP address will suffer.
Additionally, you can use reverse proxy to deliver static content, but in the case of Nextcloud, this will not give a noticeable increase in speed. So this is optional and optional.

I am glad to share this story, I hope someone will be useful. If you know more elegant and effective methods for solving the problem, I will be grateful for the comments!