Mise en place d'un serveur de redirection sur Azure Cloud
Cet article de la base de connaissances explique comment installer et configurer redirection.io pour qu'il agisse comme un proxy inverse de redirection, qui peut être utilisé pour gérer les redirections sur votre domaine principal, ou pour gérer les redirections sur des domaines supplémentaires que vous possédez.
L'agent redirection.io peut agir comme un proxy inverse et, le plus important, c'est un binaire unique qui n'a aucune dépendance particulière. Cela signifie qu'il peut fonctionner dans presque tous les environnements d'hébergement, à condition que vous puissiez installer des logiciels supplémentaires. Cependant, ce n'est pas toujours le cas, et certains
La bonne nouvelle est qu'il existe encore des moyens d'utiliser redirection.io sur votre site web ! Voici les solutions possibles :
- essayez de contacter votre hébergeur pour lui demander la disponibilité de redirection.io : notre agent est plutôt facile à installer et à configurer, et nous serons utiles à votre fournisseur pour intégrer redirection.io à sa plateforme ;
- utilisez les Cloudflare Workers et notre intégration Cloudflare : cette option est adaptée si vous pouvez modifier les paramètres DNS de votre nom de domaine et accepter d'être lié par un nouveau contrat avec Cloudflare. La configuration est plutôt facile, et ne nécessitera que peu (voire aucune) de compétences techniques ;
- configurez un serveur proxy proche de votre infrastructure, afin de faire fonctionner redirection.io comme un proxy inverse devant votre site web. C'est ce dernier cas que nous détaillerons dans le reste de cet article.
Configuration globale
Imaginons le cas de Jean, qui héberge son site sur le Cloud, dans Microsoft Azure, et utilise l'offre d'hébergement fournie par un éditeur de logiciels, sans pouvoir installer d'autres logiciels sur sa plateforme d'hébergement.
Dans le cas de Jean, quelques étapes permettent d'ajouter le support de redirection.io :
- démarrer une machine virtuelle Linux sur Azure Cloud (par exemple, une image Debian par Credativ, ou une Ubuntu par Canonical, mais toute distribution Linux devrait fonctionner) ;
- installer le serveur web nginx, ainsi que l'agent redirection.io et le module nginx ;
- créer un VirtualHost nginx selon la configuration de vos domaines.
Voyons en détails toutes ces étapes avec Jean :-)
Démarrer une machine virtuelle Linux sur Azure Cloud
Tout d'abord, commencez par créer une machine virtuelle Linux dans le portail Azure, comme expliqué dans la documentation de Microsoft.
Choisissez la distribution Linux de votre choix :
Et vérifiez que les ports requis sur la machine seront accessibles. Bien sûr, vous aurez besoin des ports 80 et 443, car cette machine peut être accédée via http ou https :
Installer tous les composants
À cette étape, nous suivons les étapes détaillées dans notre guide TL;DR; :
# update the distribution
sudo apt update && sudo apt dist-upgrade
# install required packages
sudo apt-get install apt-transport-https gnupg2
# add redirection.io repository key
wget -q -O - https://packages.redirection.io/gpg.key | sudo apt-key add -
# add our Debian repository urls:
echo "deb https://packages.redirection.io/deb/stable/2 any main" | sudo tee -a /etc/apt/sources.list.d/packages_redirection_io_deb.list
echo "deb https://packages.redirection.io/deb/stable/2 bookworm main" | sudo tee -a /etc/apt/sources.list.d/packages_redirection_io_deb.list
# install the required packages
sudo apt update && sudo apt install redirectionio-agent libnginx-mod-redirectionio
Tous les composants requis sont maintenant installés, et nous ne sommes qu'à quelques pas du démarrage des redirections :-) Modifiez le VirtualHost par défaut de nginx pour activer redirection.io :
sudo nano /etc/nginx/sites-enabled/default
Dans la section server, ajoutez une directive redirectionio_project_key :
server {
listen 80 default_server;
listen [::]:80 default_server;
redirectionio_project_key SOME_PROJECT_KEY_HERE;
# leave other lines untouched
}Vous pouvez trouver la clé de projet dans l'écran "instances" du gestionnaire (cliquez sur le bouton "Configuration sur votre infrastructure").
Redémarrez nginx, et c'est parti !
sudo systemctl restart nginx
Maintenant, ouvrez votre navigateur web préféré, et rendez-vous sur http://<IP ADDRESS OF YOUR VIRTUAL MACHINE>. Attendez quelques secondes, et dans le gestionnaire redirection.io, rendez-vous dans l'onglet "Logs". Vous devriez voir des lignes de journal apparaître :
redirection.io est correctement installé et fonctionne comme un serveur HTTP "traditionnel" (c'est-à-dire que pour le moment, il ne proxifie pas les requêtes vers votre site web). Vous pouvez exécuter des redirections pour toutes les requêtes entrantes, mais vous ne pouvez pas servir de vraies pages de votre site web. C'est parfois pratique, cependant : si vous voulez juste rediriger des noms de domaine de parking sans servir de vraie page web, vous pouvez arrêter la configuration ici.
Proxifier le trafic vers votre site web réel
Afin de servir des pages réelles tout en pouvant utiliser le serveur de redirection nouvellement installé, nous devons créer un proxy inverse dans la configuration nginx. Il existe beaucoup de documentation disponible sur comment utiliser nginx comme proxy inverse, nous ne détaillerons donc pas cela ici.
Commencez par créer un nouveau VirtualHost nginx, dans /etc/nginx/sites-available/your-website.com :
sudo nano /etc/nginx/sites-available/your-website.com
Collez ce qui suit :
server {
listen 80;
listen [::]:80;
server_name your-website.com www.your-website.com;
# redirection.io project key
redirectionio_project_key SOME_PROJECT_KEY_HERE;
# logs
error_log /var/log/nginx/site-error.log;
access_log /var/log/nginx/site-access.log;
# reverse proxy configuration
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://YOUR REAL WEBSITE IP ADDRESS;
}
}Bien sûr, remplacez :
- le(s) nom(s) de domaine à écouter ;
- la clé de projet redirection.io, que vous pouvez trouver dans l'écran "instances" du gestionnaire ;
- l'adresse IP publique de la machine de votre site web réel (ou une adresse IP privée locale, si vous avez configuré un réseau de zone privée pour regrouper les machines virtuelles de votre infrastructure).
Activez ce VirtualHost en créant un lien symbolique :
sudo ln -s /etc/nginx/sites-available/your-website.com /etc/nginx/sites-enabled/your-website.com
Et rechargez nginx :
sudo systemctl reload nginx
À condition d'avoir modifié le champ A dans la zone
Le proxy inverse de redirection est maintenant configuré, vous pouvez apprendre à créer vos premières règles de redirection !
Dernière chose : j'ai besoin de https
https est aujourd'hui une exigence de facto. Bien sûr, comme vous avez modifié les adresses IP de votre domaine, et comme nginx est maintenant l'équipement http frontal de votre site web, la terminaison TLS doit être effectuée sur ce serveur proxy de redirections. Cela signifie simplement que la gestion des certificats SSL sera désormais effectuée sur votre nouveau serveur, et que vous devez configurer nginx pour écouter sur le port 443 en utilisant les certificats SSL de vos domaines. Voici généralement les modifications de VirtualHost nginx qui doivent être effectuées à cette étape :
server {
listen 80;
listen [::]:80;
server_name your-website.com www.your-website.com;
# redirection.io project key
redirectionio_project_key SOME_PROJECT_KEY_HERE;
# logs
error_log /var/log/nginx/redirect-error.log;
access_log /var/log/nginx/redirect-access.log;
# reverse proxy configuration
location / {
return 301 https://your-website.com$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name your-website.com www.your-website.com;
# Look for example at https://wiki.mozilla.org/Security/Server_Side_TLS
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384";
ssl_prefer_server_ciphers on;
# Diffie-Hellman parameter for DHE ciphersuites
ssl_dhparam /path/to/your/certificate/dhparam.pem;
# The certificate chain sent to the browser, as well as the private key.
# Make sure your private key is only accessible by the webserver during
# configuration loading (which by default is done with user root).
ssl_certificate /path/to/your/certificate/fullchain.pem;
ssl_certificate_key /path/to/your/certificate/privkey.pem;
ssl_trusted_certificate /path/to/your/certificate/chain.pem;
# For OCSP stapling, we need a DNS resolver. Here only Google DNS servers
# are specified; I would prepent them by your hoster's DNS servers.
# You can usually find their IPs in /etc/resolv.conf on your webserver.
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 10s;
# Enabling OCSP stapling. Nginx will take care of retrieving the OCSP data
# automatically. See https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling
# for details on OCSP stapling.
ssl_stapling on;
ssl_stapling_verify on;
# Enables a SSL session cache. Adjust the numbers depending on your site's usage.
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_session_tickets off;
# Set the buffer size to 1400 bytes (that way it fits into a single MTU).
ssl_buffer_size 1400;
# You should only use HSTS with proper certificates; the ones from Let's Encrypt
# are fine for this, self-signed ones are not. See MozillaWiki for more details:
# https://wiki.mozilla.org/Security/Server_Side_TLS#HSTS:_HTTP_Strict_Transport_Security
add_header Strict-Transport-Security "max-age=31536000;";
# redirection.io project key
redirectionio_project_key SOME_PROJECT_KEY_HERE;
# logs
error_log /var/log/nginx/site-error.log;
access_log /var/log/nginx/site-access.log;
# reverse proxy configuration
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://YOUR REAL WEBSITE IP ADDRESS;
}
}Sur votre serveur d'hébergement de site web réel, vous n'avez plus besoin de vous soucier de https, car la négociation SSL est maintenant gérée sur ce serveur proxy.