Comment configurer OpenLiteSpeed pour le proxy inverse dans Nextcloud, situé dans un réseau interne ?
C'est incroyable, mais la recherche sur Habr avec la requête OpenLiteSpeed ne donne rien ! Je suis pressé de corriger cette injustice, car LSWS est un serveur web digne de ce nom. Je l'apprécie pour sa vitesse et son interface web d'administration moderne :
Bien que OpenLiteSpeed soit surtout connu comme un « accélérateur » de WordPress, dans cet article, je vais montrer une utilisation plutôt spécifique de celui-ci. À savoir le proxy inverse des requêtes. Vous pourriez dire qu'il est plus habituel d'utiliser nginx pour cela ? Je suis d'accord. Mais nous sommes vraiment devenus friands de LSWS !
Le proxy, d'accord, mais vers où ? Vers un service tout aussi remarquable – Nextcloud. Nous utilisons Nextcloud pour créer des « nuages de fichiers » privés. Pour chaque client, nous attribuons une VM distincte avec Nextcloud, et nous ne voulons pas les exposer « à l'extérieur ». Au lieu de cela, nous proxyons les requêtes via un proxy inverse commun. Cette solution permet :
1) de retirer le serveur contenant les données du client d'Internet et
2) d'économiser des adresses IP.
Le schéma est le suivant :
Il est évident que le schéma est simplifié, car l'organisation de l'infrastructure des services web n'est pas le sujet de cet article.
De plus, dans cet article, je vais omettre l'installation et la configuration de base de Nextcloud, d'autant plus qu'il existe des documents consacrés à ce sujet sur Habr. Mais je montrerai certainement les paramètres sans lesquels Nextcloud ne fonctionnera pas derrière le proxy.
Étant donné :
Nextcloud est installé sur l'hôte 1 et configuré pour fonctionner via http (sans SSL), il n'a qu'une interface réseau locale et une adresse IP « grise » 172.16.22.110.
Configurons OpenLiteSpeed sur l'hôte 2. Il dispose de deux interfaces, une externe (se dirigeant vers Internet) et une interne avec une adresse IP dans le réseau 172.16.22.0/24
Le nom DNS cloud.connect.link pointe vers l'adresse IP de l'interface externe de l'hôte 2
Problème :
Accéder depuis Internet via le lien ‘‘ (SSL) vers Nextcloud dans le réseau interne.
- Installons OpenLiteSpeed sur Ubuntu 18.04.2.
Ajoutons le dépôt :
wget -O — |sudo bash
sudo apt-get update
installons, démarrons :
sudo apt-get install openlitespeed
sudo /usr/local/lsws/bin/lswsctrl start
- Configurons minimalement le pare-feu.
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 votre hôte de gestion to any port 7080
sudo ufw enable - Configurons OpenLiteSpeed comme un proxy inverse.
Créons des répertoires pour le 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/
Configurons le virtual host depuis l'interface web de LSWS.
Ouvrons l'URL de gestion
Identifiant/mot de passe par défaut : admin/123456
Ajoutons un hôte virtuel (Virtual Hosts > Add).
Lors de l'ajout, un message d'erreur apparaîtra – absence de fichier de configuration. C'est normal, cela se résout en cliquant sur Click to create.
Dans l'onglet Général, indiquons le Document Root (bien qu'il ne soit pas nécessaire, sans lui la configuration ne fonctionnera pas). Le Nom de Domaine, s'il n'est pas spécifié, sera pris du Nom de l'Hôte Virtuel, que nous avons nommé d'après notre domaine.
Il est maintenant temps de se souvenir que nous avons non seulement un serveur web, mais un reverse proxy. Les paramètres suivants indiqueront à LSWS quoi proxifier et où. Dans les paramètres de l'hôte virtuel, ouvrons l'onglet Application Externe et ajoutons une nouvelle application de type Serveur Web :
Indiquons un nom et une adresse. Le nom peut être quelconque, mais il doit être noté, il sera utile aux prochaines étapes. L'adresse – celle où se trouve Nextcloud dans le réseau interne :
Dans les mêmes paramètres de l'hôte virtuel, ouvrons l'onglet Contexte et créons un nouveau contexte de type Proxy :
Indiquons les paramètres : URI = \, Serveur Web = nextcloud_1 (nom de l'étape précédente)
Redémarrons LSWS. Cela se fait d'un clic depuis l'interface web, quelle magie ! (c'est le descendant d'un expert en réseaux qui parle en moi)
- Installons le certificat, configurons https.
Nous supposerons qu'il est déjà en notre possession et se trouve avec la clé dans le répertoire /etc/letsencrypt/live/cloud.connect.link.
Créons un « auditeur » (Listeners > Add), appelons-le « https ». Indiquons-lui le port 443 et marquons qu'il sera Sécurisé :
Dans l'onglet SSL, indiquons le chemin vers la clé et le certificat :
L'auditeur créé, ajoutons notre hôte virtuel à la section Mappages d'Hôtes Virtuels :
Si LSWS ne doit proxifier qu'un seul service, la configuration peut s'arrêter ici. Mais nous prévoyons de l'utiliser pour transmettre des requêtes à différentes « instances » en fonction du nom de domaine. Et chaque domaine aura son propre certificat. Il est donc nécessaire d'accéder à la configuration de l'hôte virtuel et de spécifier à nouveau dans l'onglet SSL sa clé et son certificat. À l'avenir, cela doit être fait pour chaque nouvel hôte virtuel.
Il reste à configurer la réécriture d'url pour que les requêtes http soient redirigées vers https.
(Au fait, quand cela va-t-il se terminer ? Il est grand temps que les navigateurs et autres logiciels aillent par défaut sur https, et que la redirection vers no-SSL se fasse manuellement si nécessaire).
Activer Enable Rewrite et écrire les Règles de Réécriture :
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ } [R=301,L]
Il n'est pas possible d'appliquer les règles de réécriture avec un redémarrage en douceur en raison d'un étrange malentendu. Nous allons donc redémarrer LSWS de manière brute mais efficace :
sudo systemctl restart lsws.service
Pour que le serveur écoute également le port 80, créons un autre Listener. Appelons-le http, spécifions le port 80 et indiquons qu'il sera non-sécurisé :
De la même manière que pour le réglage du listener https, associons-le à notre vhost.
Désormais, LSWS écoutera le port 80 et redirigera les requêtes vers le 443, en réécrivant l'URL.
Pour finir, je recommande de réduire le niveau de journalisation de LSWS, qui est par défaut configuré en mode Debug. Dans ce mode, les journaux se multiplient à une vitesse fulgurante ! Pour la plupart des cas, un niveau Warning suffit. Allons dans Configuration du serveur > Journal :
Ainsi, la configuration d'OpenLiteSpeed en tant que proxy inverse est terminée. Nous redémarrons encore une fois LSWS et allons sur le lien et voyons :
Pour que Nextcloud nous accepte, il est nécessaire d'ajouter le domaine cloud.connect.link à la liste des domaines de confiance. Modifions le config.php. J'ai installé Nextcloud automatiquement lors de l'installation d'Ubuntu et la configuration se trouve ici : /var/snap/nextcloud/current/nextcloud/config.
Ajoutons le paramètre 'cloud.connect.link' à la clé trusted_domains :
'trusted_domains' =>
array (
0 => '172.16.22.110',
1 => 'cloud.connect.link',
),
Ensuite, dans la même configuration, nous devons indiquer l'adresse IP de notre proxy. Je souligne que l'adresse doit être celle qui est visible pour le serveur Nextcloud, c'est-à-dire l'IP de l'interface locale de LSWS. Sans ce pas, l'interface web de Nextcloud fonctionnera, mais les applications ne seront pas authentifiées.
'trusted_proxies' =>
array (
0 => '172.16.22.100',
),
Super, après cela, nous pouvons accéder à l'interface d'authentification :
La tâche est résolue ! Maintenant, chaque client peut utiliser en toute sécurité le « cloud de fichiers » via son URL personnelle, le serveur de fichiers étant séparé d'Internet, les futurs clients obtiendront la même chose et aucun IP supplémentaire ne sera affecté.
En outre, un proxy inverse peut être utilisé pour livrer du contenu statique, mais dans le cas de Nextcloud, cela n'apportera pas d'augmentation significative de la vitesse. Donc c'est optionnel et selon le désir.
Je suis heureux de partager cette histoire, j'espère qu'elle sera utile à quelqu'un. Si vous connaissez des méthodes plus élégantes et efficaces pour résoudre le problème posé – je serais reconnaissant pour vos commentaires !
Source : habr.com
