Utiliser un proxy est un moyen efficace pour autoriser l'accès à un site web interne depuis une connexion depuis le WAN. Cela permet de masquer des ressources tout en les rendant disponibles de manière sécurisée.
Dans les lignes qui suivent, nous mettons en place une solution basée sur NGinx lui-même installé sur une distribution Ubuntu Serveur.
On commence par installer NGinx
sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
ufw allow 80/tcp
ufw allow 443/tcp
server {
listen 80 default;
server_name _;
server_name_in_redirect off;
resolver 127.0.0.1;
location / {
root /;
access_log off;
set $memcached_key "$uri?$args";
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @fallback;
proxy_pass http://NOM-DE-VOTRE-SERVEUR-WEB:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
log_not_found off;
expires 360d;
set $memcached_key "$uri?$args";
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @fallback;
proxy_pass http://NOM-DE-VOTRE-SERVEUR-WEB:80;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
En remplaçant bien sûr NOM-DE-VOTRE-SERVEUR-WEB par le nom ou l'IP de votre serveur que vous voulez
cacher derrière votre proxy.
Installer la partie Proxy sous Windows est presque simple :
Installer le module URL Rewrite pour permettre la manipulation des URLS https://www.microsoft.com/en-us/download/details.aspx?id=47337
Installer le module Application Request Routing pour le mode proxy https://www.iis.net/downloads/microsoft/application-request-routing ATTENTION : bien prendre au moins la version 3.0 sinon ce ne sera pas installable correctement sous Windows 2016
Sur le serveur IIS qui va servir de proxy, dans la section IIS > URL Rewrite, faire Add Rules... Choisir les règles Reverse Proxy, valider l'activation du Application Request Routing et saisir l'IP ou le nom du serveur vers lequel rediriger la requête.
IIS ARR est en fait un plugin installé sur les serveurs IIS devant partager un équilibrage de charge. Il permet notamment :
Depuis la console IIS, lancer Web Platform Installer. Dans la zone de recherche entrer ARR et faire Entrée au clavier Sélectionner Routage des demandes d'applications 3.0 Bêta et appuyer sur Ajouter. Cliquer sur Installer Cliquer sur Accepter Patienter pendant l'installation. En fin de traitement, fermer et ouvrir à nouveau la console IIS pour trouver les composants d'administration de ARR. Ils sont accessibles via les éléments IIS, en cliquant sur le nom de votre serveur physique, sous le nom Application Request Routing Cache.
L'objectif est de mettre en place un routage simple du protocole HTTP en faisant transiter les requêtes arrivant sur l'ARR à destination du serveur Web qui hébergle les sites. Déroulez l'option Server Farms > Create Server Farm… Entrer le nom de la ferme de serveurs. Par défaut il est d'usage de saisir le nom DNS, cocher la case Online et Suivant. Entrer le nom ou l'IP des serveurs qui hébergent les sites et cliquer sur Add. Lorsque tous les serveurs participant à la ferme sont saisis, valider par Terminer. Cliquer sur Oui pour confirmer la création automatique de règle de réécriture (routage). Les règles automatiques s'appuient sur le nom de la ferme pour la réécriture. Il est possible de modifier cette règle ultérieurement. La première ferme est disponible dans la liste. Cliquer sur la ferme créée pour afficher les actions possibles. Pour créer ces règles de réécriture, cliquer sur Routing Rules. Dans le menu Actions, cliquer sur Url Rewrite… La règle de transfert automatiquement générée apparaît. Double cliquer dessus pour voir les détails de cette règle. Dans le cas où un seul serveur IIS héberge les sites sur des sites distincts sur IIS, il est possible de garder la règle par défaut car le trafic est généré en conservant l'entête de l'hôte. Par défaut la règle va consister à transférer le trafic et non le réécrire. En cliquant sur Conditions nous allons ouvrir une fenêtre qui va nous permettre de gérer cette réécriture. Dans l'exemple nous ne prendrons qu'un seul serveur Web dont le DNS est srv.web.local Cliquer sur le bouton Ajouter… Dans la fenêtre qui vient de s'ouvrir, entrer la variable serveur que l'on va tester. Ici nous prenons {HTTP_HOST}. Dans le champ Modèle saisi le (sous-)domaine à traiter et cliquer sur OK pour enregistrer la condition. Cliquer ensuite sur Appliquer pour valider cette condition. Il est possible de refaire la même chose avec tous les sites Web hébergés, à condition que chacun d'eux ait un champs DNS A qui pointe dessus. Ping site.web1.local → 192.168.1.10 Ping site.web2.local → 192.168.1.10 … Dans ce cas de figure, tous les enregistrements DNS pointent vers notre serveur ARR (192.168.1.10) Pour valider le fait que l'ARR est fonctionnel il est possible de regarder dans les logs de IIS dans C:\inetpub\logs\LogFiles\W3SVC1 par défaut. Le passage à travers l'ARR peut également être observé au niveau du monitoring disponible depuis la console IIS, sur la partie de la ferme Web, dans l'option Monitoring and Management.
Le but de cette décharge SSL est de rendre disponible le serveur ARR en HTTPS et de faire communiquer l'ARR et les sites en HTTP. Cela permet donc de réduire l'impact du travail de traduction du HTTPS pour l'accès aux sites et au chiffrement. Pour utiliser le SSL Offloading, il faut au préalable que votre serveur ARR dispose d'un certificat SSL. En production il faudrait prendre un certificat de type SAN pour couvrir plusieurs domaines et parce que l'application ARR s'appuie sur le default web site de IIS. Se placer à la racine de la console IIS du ARR et ouvrir Certificats de serveurs. Cliquer sur Importer dans le menu Actions. Sélectionner le certificat au format pfx, entrer la clé privée, choisir le magasin de stockage (Hébergement Web) et faire OK. Le certificat devrait être affiché comme Importé. Afficher la liste des sites disponibles sur le serveur en cliquant sur le dossier Sites et sélectionner le site par défaut. Faire un clic droit et cliquer sur Liaisons… Cliquer sur le bouton Ajouter… Choisir le type de liaison en HTTPS, sélectionner votre certificat et faire OK. L'accès en HTTPS est maintenant normalement possible. Fermez cette fenêtre de dialogue. Paramétrage du routage Aller sur la page de gestion des règles de réécriture. Ajouter une nouvelle règle depuis le menu Actions en cliquant sur Ajouter des règles et choisir la Règle vide puis OK. Nommer la règle comme vous le souhaitez, cliquer sur Conditions pour développer l'option et ajouter les deux règles suivantes : La première vérifie si l'appel est fait en HTTPS : {HTTPS} Correspond au modèle On La seconde limite l'appel au domaine : {HTTP_HOST} Corresond au modèle lab.domaine.local Dans la partie Action, le schéma doit être HTTP, choisir la batterie de serveurs puis Appliquer. Retourner sur la liste des règles pour la voir apparaître. Il ne reste qu'à lancer le navigateur et pointer vers votre site en HTTPS. Activation du cache L'activation du cache sur l'ARR va permettre d'économiser des requêtes sur le serveur Web derrière l'ARR. Sur le serveur ARR IIS, faire un double clic sur l'icône de l'Application Request Routing Cache pour créer un dossier qui va recevoir la cache. Cliquer sur l'option Drive Management > Add drive… Valider la feuille de dialogue en saisissant éventuellement une taille limite d'utilisation du dossier ainsi que son emplacement. Valider par OK. Aller ensuite sur un des sites déclarés dans la ferme de serveurs et cliquer sur Caching. Si ce n'est pas le cas, activer le cache en cochant la case Enable disk cache puis Appliquer. Actualiser le site où le cache est activé. Si vous ouvrez le dossier où le cache est déclaré, des fichiers devraient se trouver dans ce dossier.