Como configurar o OpenLiteSpeed para proxy reverso no Nextcloud que está em uma rede interna?
Incrível, mas a busca no Habr por OpenLiteSpeed não retorna nada! Estou apressado para corrigir essa injustiça, já que o LSWS é um servidor web digno. Eu o adoro pela sua velocidade e pela interface web de administração moderna:
Apesar de o OpenLiteSpeed ser mais famoso como um "acelerador" para o WordPress, no artigo de hoje, vou mostrar uma aplicação bastante específica dele. Ou seja, proxy reverso. Você pode dizer que é mais comum usar nginx para isso? Eu concordo. Mas nós realmente gostamos do LSWS!
Proxy é ótimo, mas para onde? Para um serviço não menos maravilhoso – Nextcloud. Usamos o Nextcloud para criar "nuvens de compartilhamento de arquivos" privadas. Para cada cliente, alocamos uma VM separada com Nextcloud e não queremos expô-las "externamente". Em vez disso, fazemos proxy das requisições através de um proxy reverso compartilhado. Essa solução permite:
1) retirar o servidor que armazena os dados do cliente da internet e
2) economizar endereços IP.
O esquema é assim:
É claro que o esquema é simplificado, pois a organização da infraestrutura de serviços web não é o tema do artigo de hoje.
Além disso, neste artigo, vou omitir a instalação e configuração básica do Nextcloud, especialmente porque há materiais dedicados a esse assunto no Habr. Mas vou mostrar as configurações essenciais, sem as quais o Nextcloud não funcionará atrás do proxy.
Dado:
O Nextcloud está instalado no host 1 e configurado para funcionar em http (sem SSL), possui apenas uma interface de rede local e um IP "cinza" 172.16.22.110.
Vamos configurar o OpenLiteSpeed no host 2. Ele possui duas interfaces, uma externa (voltada para a internet) e uma interna com um endereço IP na rede 172.16.22.0/24.
O nome DNS cloud.connect.link aponta para o endereço IP da interface externa do host 2.
Problema:
Acessar pela internet através do link ‘‘ (SSL) para o Nextcloud na rede interna.
- Instalamos o OpenLiteSpeed no Ubuntu 18.04.2.
Adicionamos o repositório:
wget -O — |sudo bash
sudo apt-get update
instalamos, iniciamos:
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Vamos configurar minimamente o 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 seu host de gerenciamento para qualquer porta 7080
sudo ufw enable - Vamos configurar o OpenLiteSpeed como um proxy reverso.
Vamos criar diretórios para o 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/
Vamos configurar o virtual host a partir da interface web do LSWS.
Abrimos a url de gerenciamento
Login/senha padrão: admin/123456
Adicionando um virtual host (Virtual Hosts > Add).
Ao adicionar, aparecerá uma mensagem de erro - ausência de arquivo de configuração. Isso é normal, é resolvido clicando em Click to create.
Na aba General, vamos indicar o Document Root (mesmo que não precise, sem ele a configuração não funcionará). O Domain Name, se não for especificado, será retirado do Virtual Host Name, que nomeamos como o nosso domínio.
Agora é hora de lembrar que não temos apenas um servidor web, mas um reverse proxy. As próximas configurações indicarão ao LSWS o que proxyar e para onde. Nas configurações do virtual host, abrimos a aba External App e adicionamos um novo aplicativo do tipo Servidor web:
Indicamos o nome e o endereço. O nome pode ser escolhido livremente, mas deve ser lembrado, será útil nas etapas seguintes. O endereço é onde o Nextcloud reside na rede interna:
Nas mesmas configurações do virtual host, abrimos a aba Context e criamos um novo contexto do tipo Proxy:
Indicamos os parâmetros: URI = /, Servidor web = nextcloud_1 (nome da etapa anterior)
Reiniciamos o LSWS. Isso é feito com um clique na interface web, maravilhas! (dentro de mim fala um ancestral controlador de ratos)
- Colocamos o certificado, configuramos https.
e vamos supor que já o temos e ele está junto com a chave no diretório /etc/letsencrypt/live/cloud.connect.link.
Vamos criar um ‘listener’ (Listeners > Add), vamos chamá-lo de ‘https’. Vamos informar que ele utilizará a porta 443 e marcar que será Secure:
Na aba SSL, indicamos o caminho para a chave e o certificado:
O ‘listener’ foi criado, agora na seção Mappings de Virtual Host, vamos adicionar nosso virtual host a ele:
Se o LSWS for proxyar apenas para um serviço, a configuração pode ser finalizada. Mas planejamos usá-lo para encaminhar pedidos para diferentes ‘instâncias’ dependendo do nome do domínio. E todos os domínios terão seus próprios certificados. Portanto, devemos ir para a configuração do virtual host e novamente indicar na aba SSL sua chave e certificado. No futuro, isso deve ser feito para cada novo virtual host.
Agora só falta configurar a reescrita de URL para que os pedidos http sejam direcionados para https.
(Aliás, quando isso vai acabar? Já está na hora dos navegadores e outros softwares, por padrão, utilizarem https, e a transferência para no-SSL ser feita manualmente, se necessário).
Ativamos Enable Rewrite e escrevemos Rewrite Rules:
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Não é possível aplicar as regras de reescrita de maneira convencional com o Graceful restart devido a um estranho mal-entendido. Por isso, vamos reiniciar o LSWS de maneira direta, mas efetiva:
sudo systemctl restart lsws.service
Para que o servidor escute também a porta 80, criamos mais um Listener. Chamaremos de http, informaremos a porta 80 e que ele será não seguro:
Seguindo a configuração do listener https, vamos associar nosso virtualhost a ele.
Agora o LSWS vai escutar a porta 80 e redirecionar as requisições para a 443, reescrevendo a URL.
Por fim, recomendo reduzir o nível de log do LSWS, que por padrão está configurado como Debug. Nesse modo, os logs se multiplicam rapidamente! Para a maioria dos casos, o nível Warning é suficiente. Vamos em Configuração do Servidor > Log:
Com isso, a configuração do OpenLiteSpeed como um proxy reverso está concluída. Reiniciamos o LSWS novamente e acessamos o link e vemos:
Para que o Nextcloud nos permita acessar, é necessário adicionar o domínio cloud.connect.link à lista de domínios confiáveis. Vamos editar o config.php. Instalei o Nextcloud automaticamente ao configurar o Ubuntu e a configuração está aqui: /var/snap/nextcloud/current/nextcloud/config.
Adicionamos ao parâmetro trusted_domains o valor ‘cloud.connect.link’:
‘trusted_domains’ =>
array (
0 => ‘172.16.22.110’,
1 => ‘cloud.connect.link’,
),
Em seguida, no mesmo arquivo de configuração, precisamos especificar o endereço IP do nosso proxy. Ressalto que o endereço deve ser aquele que é visível para o servidor Nextcloud, ou seja, o IP da interface local do LSWS. Sem essa etapa, a interface web do Nextcloud funcionará, mas os aplicativos não se autenticarão.
‘trusted_proxies’ =>
array (
0 => ‘172.16.22.100’,
),
Ótimo, agora podemos acessar a interface de login:
Problema resolvido! Agora cada cliente pode usar o "cloud de arquivos" com sua URL pessoal, o servidor de arquivos está isolado da internet, futuros clientes terão a mesma experiência e nenhum endereço IP extra será danificado.
Adicionalmente, pode-se usar um proxy reverso para entregar conteúdo estático, mas no caso do Nextcloud isso não proporcionará um aumento significativo na velocidade. Portanto, isso é opcional e a critério do usuário.
Fico feliz em compartilhar essa história, espero que seja útil para alguém. Se você conhece métodos mais elegantes e eficientes para resolver a tarefa proposta, ficarei grato pelos comentários!
Fonte: habr.com
