¿Cómo configurar OpenLiteSpeed para el proxy inverso en Nextcloud, que se encuentra en una red interna?
Es increíble, pero buscar en Habr con la consulta OpenLiteSpeed no da nada. Me apresuro a corregir esta injusticia, ya que LSWS es un digno servidor web. Me encanta por su velocidad y su moderno interfaz web de administración:
A pesar de que OpenLiteSpeed es más conocido como un «acelerador» para WordPress, en el artículo de hoy mostraré un uso bastante específico. En concreto, el proxy inverso de solicitudes. ¿Dirías que es más habitual usar nginx para esto? Estoy de acuerdo. ¡Pero nos hemos encariñado tanto con LSWS!
El proxy está bien, pero ¿a dónde? A un servicio igualmente maravilloso: Nextcloud. Usamos Nextcloud para crear «nubes de intercambio de archivos» privadas. Para cada cliente, asignamos una VM separada con Nextcloud y no queremos exponerlas «al exterior». En su lugar, proxyamos las solicitudes a través de un proxy inverso común. Esta solución permite:
1) sacarle el servidor donde se almacenan los datos del cliente de Internet y
2) ahorrar direcciones IP.
El esquema es el siguiente:
Es evidente que el esquema está simplificado, ya que la organización de la infraestructura de servicios web no es el tema de este artículo.
También en este artículo omitiré la instalación y configuración básica de Nextcloud, especialmente porque hay materiales dedicados a este tema en Habr. Pero definitivamente mostraré las configuraciones sin las cuales Nextcloud no funcionará detrás del proxy.
Dado:
Nextcloud está instalado en el host 1 y configurado para trabajar por http (sin SSL), tiene solo una interfaz de red local y una dirección IP «gris» 172.16.22.110.
Configuraremos OpenLiteSpeed en el host 2. Este tiene dos interfaces, una externa (que mira hacia Internet) y otra interna con una dirección IP en la red 172.16.22.0/24
El nombre DNS cloud.connect.link apunta a la dirección IP de la interfaz externa del host 2.
Tarea:
Acceder desde Internet a través del enlace ‘‘ (SSL) a Nextcloud en la red interna.
- Instalamos OpenLiteSpeed en Ubuntu 18.04.2.
Agregamos el repositorio:
wget -O — |sudo bash
sudo apt-get update
instalamos, iniciamos:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Configuraremos mínimamente el 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 tu host de gestión to any port 7080
sudo ufw enable - Configuraremos OpenLiteSpeed como un proxy inverso.
Crearemos directorios para el 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/
Configuraremos el virtual host desde la interfaz web de LSWS.
Abrimos la URL de gestión.
Inicio de sesión/contraseña predeterminados: admin/123456
Agregamos un virtualhost (Virtual Hosts > Agregar).
Al agregar, aparecerá un mensaje de error sobre la falta de un archivo de configuración. Es normal, se resuelve haciendo clic en Crear.
En la pestaña General indicaremos Document Root (aunque no lo necesitaremos, sin él la configuración no funcionará). Domain Name, si no se indica, se tomará del nombre del Virtual Host, que hemos llamado el nombre de nuestro dominio.
Ahora es momento de recordar que no solo tenemos un servidor web, sino un reverse proxy. Las siguientes configuraciones indicarán a LSWS qué debe proxy y hacia dónde. En la configuración del virtualhost abrimos la pestaña External App y agregamos una nueva aplicación del tipo servidor web:
Indicamos un nombre y una dirección. El nombre puede ser arbitrario, pero hay que recordarlo, será útil en los siguientes pasos. La dirección es donde se encuentra Nextcloud en la red interna:
En la misma configuración del virtualhost abrimos la pestaña Context y creamos un nuevo contexto de tipo Proxy:
Indicamos los parámetros: URI = /, Web server = nextcloud_1 (nombre del paso anterior)
Reiniciamos LSWS. Se hace con un clic desde la interfaz web, ¡milagros! (habla un hijo de un transportador de ratones)
- Instalamos el certificado, configuramos https.
la omitiremos, asumiremos que ya lo tenemos y que está junto con la clave en el directorio /etc/letsencrypt/live/cloud.connect.link.
Crearemos un 'listener' (Listeners > Agregar), lo llamaremos 'https'. Le asignaremos el puerto 443 y marcaremos que será Seguro:
En la pestaña SSL indicaremos la ruta a la clave y al certificado:
El 'listener' ha sido creado, ahora en la sección Mapeo de Virtual Hosts agregaremos nuestro virtualhost a él:
Si LSWS solo va a proxy hasta un servicio, podemos finalizar la configuración. Pero planeamos usarlo para redirigir solicitudes a diferentes 'instancias' dependiendo del nombre de dominio. Y cada dominio tendrá su propio certificado. Por lo tanto, debemos ir a la configuración del virtualhost y volver a indicar en la pestaña SSL su clave y certificado. En el futuro, esto debe hacerse para cada nuevo virtualhost.
Solo queda configurar la reescritura de URL para que las solicitudes http se dirijan a https.
(Por cierto, ¿cuándo terminará esto? Ya es hora de que los navegadores y otro software vayan por defecto a https, y la redirección a no-SSL se haga manualmente cuando sea necesario).
Activamos Enable Rewrite y escribimos las Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
No se pueden aplicar las reglas de reescritura de la manera habitual con un reinicio elegante. Así que reiniciaremos LSWS de manera brusca pero efectiva:
sudo systemctl restart lsws.service
Para que el servidor escuche también el puerto 80, crearemos otro Listener. Lo llamaremos http, especificaremos el puerto 80 y que será no seguro:
De manera similar a la configuración del https listener, lo asignamos a nuestro virtual host.
Ahora LSWS escuchará en el puerto 80 y redirigirá las solicitudes al puerto 443, reescribiendo la URL.
Finalmente, recomiendo reducir el nivel de registro de LSWS, que por defecto está configurado como Debug. ¡En este modo, los registros se multiplican rápidamente! Para la mayoría de los casos, es suficiente con el nivel Warning. Vamos a Server Configuration > Log:
Con esto, la configuración de OpenLiteSpeed como proxy inverso está completa. Reiniciamos LSWS nuevamente y seguimos el enlace y vemos:
Para que Nextcloud nos permita el acceso, es necesario agregar el dominio cloud.connect.link a la lista de dominios de confianza. Vamos a editar config.php. Instalé Nextcloud automáticamente al instalar Ubuntu y la configuración se encuentra aquí: /var/snap/nextcloud/current/nextcloud/config.
En la clave trusted_domains agregamos el parámetro ‘cloud.connect.link’:
‘trusted_domains’ =>
array (
0 => ‘172.16.22.110’,
1 => ‘cloud.connect.link’,
),
A continuación, en la misma configuración, es necesario especificar la dirección IP de nuestro proxy. Cabe señalar que se debe indicar la dirección que es visible para el servidor Nextcloud, es decir, la dirección IP de la interfaz local de LSWS. Sin este paso, la interfaz web de Nextcloud funciona, pero las aplicaciones no se autentican.
‘trusted_proxies’ =>
array (
0 => ‘172.16.22.100’,
),
Perfecto, después de esto podemos acceder a la interfaz de autenticación:
¡El problema está resuelto! Ahora cada cliente puede usar de manera segura el ‘almacenamiento en la nube’ a través de su URL personal, el servidor de archivos está separado de Internet, y futuros clientes obtendrán lo mismo sin que ninguna dirección IP adicional se vea afectada.
Además, se puede usar un proxy inverso para entregar contenido estático, pero en el caso de Nextcloud, esto no proporcionará un aumento notable de velocidad. Así que es opcional y a elección.
Me alegra compartir esta historia, espero que le sea útil a alguien. Si conoces métodos más elegantes y efectivos para resolver el problema planteado, ¡agradeceré los comentarios!
Fuente: habr.com
