Ce guide vous guidera tout au long de l'installation et de la configuration de NGINX pour permettre l'exécution de plusieurs serveurs physiques, machines virtuelles ou une combinaison des deux derrière une seule adresse IP publique. Vous pouvez choisir d'exécuter un certain nombre de serveurs Web sur des machines virtuelles et de les administrer localement ou vous devrez peut-être utiliser des outils d'accès à distance tels que SSH pour chacun des hôtes. Par exemple, si l'accès local n'est pas disponible en dehors des heures normales de bureau. Ce guide peut faciliter les deux scénarios.
Les configurations présentées ici conviendraient mieux à un laboratoire domestique ou à un réseau de petite entreprise dont les adresses IP publiques disponibles sont limitées. Il y aurait peu de raisons, voire aucune, d'exécuter une configuration comme celle-ci, lorsque vous avez plusieurs serveurs ou machines virtuelles loués auprès d'un service d'hébergement, une adresse IP publique vous sera de toute façon attribuée pour chaque serveur ou hôte.
Je vais vous montrer comment installer NGINX et faire des configurations qui permettront au serveur d'agir comme un proxy inverse pour HTTP(S), SSH, FTP et MySQL/MariaDB. Je suppose que pour le serveur hôte NGINX vous avez :un accès local, une nouvelle installation d'Ubuntu 18.04 et que vous avez choisi d'installer le serveur SSH lors des étapes d'installation du serveur Ubuntu.
Cette configuration fonctionne bien pour moi, mais veuillez comprendre que je ne peux garantir que cela fonctionnera pour vous. Bien sûr, si vous trouvez quelque chose qui ne va pas, faites-le moi savoir afin que cela puisse être corrigé. Assurez-vous de lire l'intégralité du guide avant de commencer, il y a une partie (flux) où je montre deux façons de le gérer.
Mise en route
Dans ce guide, j'utiliserai les noms d'hôte et adresses IP suivants.
rproxy.example.com 192.168.1.1 web1.example.com 192.168.1.2 db1.exmple.com 192.168.1.3
Vous devez avoir un compte d'utilisateur non root sur le serveur pour une installation de serveur Ubuntu 18.04 standard que vous avez créée lors de l'installation. Commencez par vous connecter au serveur sur lequel vous installerez NGINX avec cet utilisateur. Comme il s'agit très probablement d'un serveur local, vous devrez peut-être vous connecter directement au serveur la première fois pour configurer le serveur SSH. Vous aurez bien sûr besoin d'un clavier et d'un moniteur connectés au serveur pour ce faire.
Remarque :Si, comme moi, vous utilisez un logiciel de virtualisation tel que VMWare qui inclut une interface de navigateur, vous devez disposer d'une console dans ce système et pouvez effectuer cette étape sans accès "direct". Vous pouvez essayer d'effectuer toute cette configuration dans cette console, cependant, j'ai constaté que certaines fonctionnalités telles que le copier-coller ne fonctionnaient pas dans la console basée sur le navigateur, bien que cela puisse être spécifique au navigateur, il peut donc être utile d'essayer de voir si vous pouvez.
Préparation du serveur hôte
Dans le shell de votre console (navigateur ou directement connecté)
sudo nano /etc/ssh/sshd_config
Décommentez les lignes :Port changez le numéro de port en quelque chose comme 23456, ListenAddress et changez-le en 0.0.0.0. Pour ceux qui ne connaissent pas nano, appuyez sur CTRL + X, tapez y, puis appuyez sur Entrée. Cela enregistrera et fermera un fichier, si aucune modification n'a été apportée au fichier, CTRL + x fermera le fichier sans demander d'enregistrer. Vous serez renvoyé à l'invite de commande.
Je n'approfondirai pas le reste des paramètres de ce fichier car il s'agit déjà d'un guide considérablement long et il existe de nombreux guides qui vous montreront quels paramètres vous devez modifier pour un certain nombre de choses, telles que l'utilisation de clés SSH et l'autorisation de root SSH connexion. Vous pouvez également trouver ces guides ici même sur le site Web HowtoForge.
Une fois les modifications terminées, vous devrez redémarrer le serveur ssh pour que les modifications prennent effet. Votre connexion actuelle n'est pas affectée par ce redémarrage.
systemctl restart ssh
Vérifiez que vous pouvez vous connecter en utilisant SSH à partir d'un terminal sur un autre ordinateur de votre réseau local.
ssh [email protected] -p23456
Gardez ce terminal ouvert après une connexion réussie à l'aide de SSH et déconnectez-vous de la console/du serveur. Vous n'avez plus besoin de l'utiliser pour le reste de ce guide.
À partir de ce moment, vous exécuterez des commandes de niveau racine à partir de votre terminal. La commande suivante éliminera le besoin de précéder les commandes suivantes avec sudo.
sudo -s
Mettez à jour la base de données des packages Apt et mettez à niveau Ubuntu pour vous assurer que les packages les plus récents sont installés.
apt update && apt -y upgrade
Si vous voyez quelque chose pendant la mise à niveau qui signale l'installation de nouveaux noyaux, vous devez redémarrer une fois qu'apt a terminé la mise à niveau pour vous assurer que vous travaillez sur un système entièrement mis à jour.
Définition du nom d'hôte du serveur proxy inverse.
hostnamectl set-hostname rproxy.example.com
Si vous exécutez un serveur virtuel, vous pouvez avoir un fichier nommé cloud.cfg qui doit être modifié pour conserver le nom d'hôte défini ici. La commande suivante affichera soit un fichier avec du contenu, soit une page vide. Si vous voyez une page vide, vous pouvez simplement CTRL + x et ignorer cette étape car vous n'avez rien à faire.
nano /etc/cloud/cloud.cfg
Remplacez la ligne preserve hostname par true et fermez/enregistrez le fichier.
If your system is currently local only you will need to show this server where your other servers/virtual hosts are.
nano /etc/hosts
Le fichier hosts ressemblera à ceci après avoir apporté les modifications, les adresses IP et les hôtes doivent correspondre à votre propre infrastructure.
127.0.0.1 localhost 127.0.1.1 rproxy.example.com 192.168.1.2 web1.example.com 192.168.1.3 db1.example.com # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Installation de NGINX
apt install -y nginx
Après l'installation, vous devez vérifier votre version de NGINX, il est primordial que vous disposiez d'une version 1.9 ou supérieure pour vous permettre d'inverser le proxy pour SSH et MySQL/MariaDB.
nginx -v
Comme vous pouvez le voir, j'ai installé NGINX version 1.14 qui est la valeur par défaut dans Ubuntu 18.04 (10 octobre 2019)
nginx version: nginx/1.14.0 (Ubuntu)
Préparation de NGINX pour fonctionner comme un proxy inverse
Avec cette configuration, vous n'allez pas servir de sites Web directement à partir du serveur hôte du proxy inverse. Vous allez créer une nouvelle structure de répertoires sous /etc/nginx/. Cela préservera les configurations NGINX par défaut si vous souhaitez annuler ces modifications ultérieurement ou si vous décidez que vous souhaitez également servir des sites Web directement à partir de cet hôte. Il est possible d'exécuter la configuration par défaut avec ces configurations de proxy inverse. Toutefois, si Apache2 se trouve sur le même serveur, il aura besoin d'autres ports pour écouter et vous devrez toujours utiliser le proxy inverse pour les sites Web desservis par cette instance d'Apache2.
Créer la structure du répertoire du proxy inverse
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled
Maintenant que la structure est en place, vous pouvez procéder à la création des fichiers de configuration. J'utilise nano mais vous pouvez utiliser l'éditeur avec lequel vous vous sentez à l'aise. Nano créera/mettra à jour les fichiers lors de la sauvegarde.
Before you proceed, open an empty document on your computer or get a pen and paper to note down the ports you configure.
Configuration des proxys inverses de serveur Web (http)
Créez le(s) fichier(s) de configuration http pour le(s) site(s) Web en ajustant en conséquence
nano http/available/example.com.conf
Copiez le bloc serveur dans la page ouverte dans le terminal avec nano ajustement en conséquence.
# Note down ports 80 and 443
server {
server_name example.com www.example.com;
listen 80;
set $upstream 192.168.1.2;
location / {
proxy_pass_header Authorization;
proxy_pass http://$upstream;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 10000s;
proxy_redirect off;
}
} Configuration des proxys inverses SSH, MySQL/MariaDB (flux)
Avant de continuer, décidez lequel vous souhaitez utiliser, par hôte ou par service. Par hôte, vous allez créer une configuration pour chaque hôte qui pourrait être utile pour modifier rapidement les paramètres d'un seul hôte. Par service, vous aurez les ports de service pour tous les serveurs dans un fichier pour chacun, SSH, MySQL/MariaDB et FTP.
Utilisation des configurations par service
Ajoutez les configurations SSH.
nano stream/available/ssh.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.2:22;
}
server {
listen 22002;
proxy_pass web1-ssh;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
# Add as many upstream and server block pairs as you will need for your remote accessed SSH servers.
Ajoutez les configurations MySQL/MariaDB.
nano stream/available/db.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
# Add as many upstream/server block pairs as you will need for your remote accessed MySQL/MariaDB servers to this file.
Créez maintenant les configurations du proxy inverse FTP.
nano stream/available/ftp.conf
upstream web1-ftp {
server 192.168.1.3:21
}
server {
listen 21002;
proxy_pass web1-ftp;
}
# Add as many upstream/server block pairs as you will need for your remote accessed FTP servers.
Utilisation des fichiers de configuration par hôte
nano /etc/nginx/rproxy/stream/available/web1.example.com.conf
# Note down the listen ports
upstream web1-ssh {
server 192.168.1.3:22;
}
server {
listen 22002;
proxy_pass web-ssh;
}
Création du fichier hôte pour db1.example.com
nano /etc/nginx/rproxy/stream/available/db1.example.com.conf
# Note down the listen ports
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
Comme vous pouvez le voir, c'est un peu peu orthodoxe. Vous utilisez des ports publics de manière non standard, en choisissant les ports dont vous avez besoin, puis en les faisant pointer vers NGINX. Ce serait normal, sauf que vous utilisez maintenant un port différent pour chaque service sur chaque serveur auquel vous souhaitez accéder à distance. Cela signifie, en utilisant SSH comme exemple, un numéro de port différent pour chaque hôte compatible SSH 22 222 2222 22222, par exemple, pointerait vers le port 22 sur quatre serveurs ou machines virtuelles différents.
Ce n'est pas le cas pour NGINX vers le proxy inverse pour les sites Web, tant que NGINX a une configuration de serveur définie pour un site Web, il fonctionnera correctement avec seulement les ports 80 et 443 qui lui seront transmis.
À ce stade, vous avez probablement réalisé que vous pouviez simplement utiliser les étapes HTTP et ignorer les étapes de flux, et à la place transférer plusieurs ports pour les multiples services vers le serveur/l'adresse IP approprié(e). En effet, cela peut être fait. Cependant, cela ajouterait une autre couche de complexité et deviendrait difficile à maintenir à mesure que le nombre de serveurs augmente, car vous devrez peut-être modifier les ports par défaut sur chaque serveur pour ssh, mysql et ftp. Cette configuration est déjà complexe, mais cela pourrait être fait si vous le vouliez.
L'utilisation d'un proxy inverse pour ces services de la manière que je vous ai montrée réduit considérablement la complexité en fournissant un emplacement unique pour effectuer ces modifications de configuration et vous n'auriez pas besoin de modifier les ports de l'ensemble de votre infrastructure.
En prime à cette configuration, les autres serveurs de votre infrastructure n'ont besoin d'écouter que sur les interfaces locales et les ports par défaut si c'est ce que vous préférez. Si vous gérez localement, vous pouvez utiliser les adresses IP locales et les ports de service par défaut pour accéder aux services requis afin que vous n'ayez pas besoin de référencer vos notes pour vous souvenir des ports corrects, il vous suffit de connaître l'adresse IP et les identifiants de connexion.
Rassembler le tout
Pour commencer à utiliser les configurations de proxy inverse NGINX, vous devrez apporter quelques modifications au fichier de configuration principal. Commentez la ligne d'inclusion actuelle dans le bloc http (si vous ne servez pas non plus de sites Web directement à partir de NGINX).
cd /etc/nginx && nano nginx.conf
Notez les parties en surbrillance ci-dessous pour déterminer ce qu'il faut changer.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
# Reverse proxy http configuration files.
include /etc/nginx/rproxy/http/enabled/*.conf;
}
stream {
# Reverse proxy stream configuration files.
include /etc/nginx/rproxy/streams/enabled/*.conf;
}
#mail {
# # See sample authentication script at:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
Activer les configurations de proxy inverse.
Tout d'abord, activez toutes les configurations http
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled
Activer toutes les configurations de flux
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabled
Effectuez un test pour vérifier que la configuration de NGINX en tant que proxy inverse est correcte.
nginx -T
Dans la sortie, vous devriez voir un message de réussite avec toutes les configurations personnalisées que vous avez faites précédemment.
Redémarrez NGINX pour activer les configurations de proxy inverse.
systemctl restart nginx
Vérifiez que NGINX écoute sur tous les ports configurés. vérifiez par rapport à vos notes que tous les ports sont affichés dans les résultats.
netstat -tulpn | grep nginx
La sortie devrait ressembler à ceci
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22002 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22003 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33062 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33063 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4964/nginx: master
Ouverture du serveur pour le trafic
Maintenant que NGINX est à l'écoute et prêt à agir en tant que proxy inverse pour toutes les connexions que nous voulons autoriser au trafic, désactivez temporairement UFW lors des étapes suivantes. Cela facilitera le dépannage si les choses ne fonctionnent pas correctement.
ufw disable
Ports de transfert
Malheureusement, je ne suis pas en mesure de vous donner des conseils ici. Vous devrez consulter le manuel de votre routeur ou rechercher votre routeur en ligne pour savoir comment procéder. En résumé, cependant, vous souhaitez transférer chacun des ports sur lesquels NGINX écoute vers la machine hôte NGINX. Dans mon routeur spécifique, je peux configurer des "applications" personnalisées.
Cela me permet d'attribuer un nombre quelconque de ports ou de plages de ports non attribués à l'application personnalisée qui sera ensuite attribuée soit à une adresse IP LAN, soit à un périphérique connecté spécifique identifié par son nom d'hôte. Dans tous les cas, cela signifie que je peux basculer tous les ports affectés à cette application personnalisée vers n'importe quel hôte de mon réseau sans avoir à supprimer tous les ports et à les réaffecter. C'est une excellente option à avoir et je vous recommande fortement de choisir un routeur qui le prend en charge.
Cette fonctionnalité petite mais incroyablement utile dans le pare-feu de mes routeurs m'a incité à installer un deuxième proxy inverse reflétant les configurations de mon proxy inverse actif. Je l'ai éteint et je peux démarrer et faire basculer les ports en moins de 3 minutes de découverte. J'imagine qu'il existe des sociétés d'hébergement professionnelles qui auraient du mal à respecter ce délai d'exécution pour la reprise après sinistre et tout cela est dû au désir d'exécuter plusieurs serveurs sur un réseau domestique.
SSL Letsencrypt gratuit pour le serveur proxy inverse
Installez le plug-in Certbot et Certbot NGINX. Cette étape est effectuée ici car vous ne pouvez pas créer de certificat tant que vous n'avez pas de DNS fonctionnel pour tous les noms de (sous-)domaine répertoriés dans un certificat et que vous n'êtes pas en mesure d'établir une connexion au domaine via HTTP. En effectuant cette opération après avoir transféré les ports au proxy inverse, cela agit également comme un test supplémentaire pour vos configurations. Si le certificat échoue parce que le domaine est inaccessible, vous verrez un avis d'erreur significatif dans la sortie.
Pour vous assurer que vous obtenez la dernière version de certbot, ajoutez le référentiel certbot avant l'installation. Les référentiels Ubuntu sont souvent une version ou plus derrière une version de logiciel et vous voulez vraiment les dernières versions de base de tous vos logiciels si vous pouvez les obtenir.
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-plugin
Avec certbot et le plugin certbot nginx installés, vous pouvez maintenant créer les certificats pour NGINX.
Cette commande doit être répétée pour tous les domaines et sous-domaines pour lesquels vous souhaitez fournir SSL. Si c'est la première fois que vous exécutez certbot, vous devrez accepter les termes et conditions.
certbot --nginx -d example.com -d www.example.com
Notez que si vous avez une configuration de serveur de travail avec SSL sur l'hôte en amont, vous devrez vous assurer que les options sélectionnées ici correspondent à celles sur le serveur hôte, en particulier, si vous redirigez vers https sur le serveur en amont, vous devez faire en sorte qu'ici aussi .
Pour plus de clarté, example.com existe sur un autre serveur, et j'ai choisi de rediriger http vers https dans ISPConfig, donc pour cette raison, je choisis de le faire ici. Le fichier de configuration sera mis à jour et je vois maintenant que Certbot a ajouté ses propres configurations.
Vérifier que les choses fonctionnent.
Maintenant que vous avez un trafic capable de circuler vers votre proxy inverse, vous devez vérifier que tout fonctionne comme prévu. Vérifiez que les sites Web fonctionnent correctement, effectuez des connexions et des tâches SSH, FTP et MySQL/MariaDB. Une fois que vous êtes satisfait que tout fonctionne comme il se doit, vous activez UFW et ajoutez des règles pour autoriser chacun des ports.
Sécuriser le serveur proxy inverse
ufw enable
Vous voudrez permettre, 80 et 443 de n'importe où. et restreindre probablement SSH, FTP et MySQL/MariaDB à une adresse IP ou un nom d'hôte. Vous pouvez commenter les règles pour identifier rapidement à quel service/serveur vous avez attribué le port.
ufw allow 80
ufw allow 443
ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'
ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'
ufw reload
ufw status numbered
Mettre à jour Apache2
Lorsqu'ils s'exécutent derrière un proxy inverse, les fichiers journaux Apache2 enregistrent l'adresse IP du serveur proxy inverse au lieu de l'adresse IP du visiteur du site Web. Pour rétablir la journalisation normale des adresses IP sur Apache2, un module est disponible pour corriger ce comportement.
Effectuez les étapes suivantes sur chaque serveur Web avec une instance Apache2 installée.
sudo apt install -y libapache2-mod-rpaf
Pour vous assurer qu'Apache2 va maintenant enregistrer les adresses IP correctes, apportez une petite modification au fichier rpaf.conf. Ubuntu 18.04 a déjà créé le fichier pour nous, il nous suffit de le modifier en remplaçant l'adresse IP en surbrillance par celle de l'hôte proxy inverse NGINX.
nano /etc/apache2/mods-available/rpaf.conf
<ifmodule rpaf_module="">
RPAFenable On
# When enabled, take the incoming X-Host header and
# update the virtualhost settings accordingly:
RPAFsethostname On
# Define which IP's are your frontend proxies that sends
# the correct X-Forwarded-For headers:
RPAFproxy_ips 127.0.0.1 ::1
# Change the header name to parse from the default
# X-Forwarded-For to something of your choice:
# RPAFheader X-Real-IP
</ifmodule> Remarques finales
NGINX et Apache2 sur le même hôte
Deux services ne peuvent pas écouter sur le même port au sein d'un serveur ou d'une machine virtuelle. Si NGINX est installé sur le même serveur ou la même machine virtuelle qu'un serveur Web Apache2, vous devrez modifier le port sur lequel Apache2 écoute. NGINX nécessite les ports 80 et 443 pour exécuter ses fonctions HTTP(S) car ce sont les ports par défaut pour HTTP et HTTPS.
Reportez-vous à la section http de ce guide et ajoutez des configurations de proxy inverse pour les sites Web servis par cette instance Apache2 de la même manière que celle des autres serveurs du réseau.
Modification du port d'écoute Apache2
Si vous avez installé un système de gestion de serveur tel que ISPConfig, ce système gère les fichiers vhost Apache2, vous devez donc rechercher comment modifier les ports sur lesquels Apache2 écoute. Recherchez les forums ISPConfig, puis effectuez les ajustements nécessaires. Sinon, vous devriez consulter les forums Ubuntu ou le site Web Apache2 pour savoir comment effectuer ces modifications.
Note: Apache2 ports do not need to be altered when it is the only web server installed on server or virtual machine.