Difference between revisions of "SME-101.08 Serveur mandataire inversé"
Michelandre (talk | contribs) m (Commentaire sur l'authentification par clé publique SSH non-nécessaire pour récupérer le certificat Let's Encrypt.) |
Michelandre (talk | contribs) m (Michelandre moved page Mandataire inversé to SME-101.08 Serveur mandataire inversé: Pour être intégré dans le Cours SME-10) |
Revision as of 22:17, 30 October 2018
Description générale
Cette marche à suivre décrit les étapes pour l'installation d'un service de mandataire inversé sur un Serveur SME principal connecté à l'Internet afin qu'un autre Serveur SME, sur le réseau LOCAL, devienne accessible depuis l'Internet. Le serveur principal devient transparent pour le serveur WEB local et ce dernier semble directement branché à l'Internet.
Le serveur local peut être physique ou virtuel.
Mandataire inversé
Serveur directement relié à l'Internet
Normalement, notre Serveur SME est directement relié à l'Internet à travers un modem ADSL/VDSL tel qu'illustré ci-dessous.
Si nous voulons accéder à notre installation Web depuis l'Internet, il faut avoir un nom de domaine FQDN et celui-ci doit pointer vers une i-bay.
Server-Manager > Configuration > Domaines > Modifier.
Notre nom de domaine est: micronator.org et notre installation Web est située dans l'i-bay Primary (site primaire). Il faut donc que ce domaine pointe vers cette i-bay.
Serveurs DNS du domaine
Pour l'i-bay Primary, toujours utiliser: Serveur DNS de l'Internet.
Pour les autres i-bays, toujours utiliser: Résolu localement.
Serveur local sur un intranet
Référence: https://wiki.contribs.org/SME_Server:Documentation:ProxyPass.
Notre Serveur SME secondaire est sur le réseau LOCAL (192.168.1.0/24) de notre serveur principal. On parle alors d'un serveur intranet. Habituellement, ce genre de serveur n'a pas d'adresse IP publique pour son réseau externe mais, une adresse privée (192.168.1.11).
| Serveur intranet physique. | Serveur intranet virtuel. |
 |
 |
Serveur mandataire inversé
Référence: https://fr.wikipedia.org/wiki/Proxy_inverse.
Un mandataire inversé (reverse proxy) est un type de serveur, habituellement placé en frontal des serveurs Web. Contrairement au serveur mandataire qui permet à un utilisateur d'accéder au réseau Internet, le mandataire inversé permet à un utilisateur d'Internet d'accéder à des serveurs internes (situés sur le réseau LOCAL du serveur principal/passerelle).
Préparation du serveur de destination
Installation d'un Serveur SME
Voir le Cahier-2: Installation d'un Serveur SME: https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/.
Pour un serveur de test, prendre un minimum de 8 GB pour le disque principal.
Lors de la configuration initiale, prendre les valeurs ci-dessous.
| Mode de fonctionnement
Serveur uniquement |
Interface de liaison de canaux
Désactivé |
Configuration du serveur DHCP
Désactivé |
 |
 |
 |
Mise à jour du Serveur
Avant de commencer quoi que ce soit, il est toujours préférable de mettre à jour le Serveur SME.
Voir le chapitre: "Mise à jour" dans le Cahier-2: Installation d'un Serveur SME - https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/.
Serveur DNS du domaine
On ajuste le pointeur des Serveurs DNS du domaine pour qu'il pointe vers les Serveurs DNS de l'Internet.
Ceci est une exception à la règle car, habituellement, un serveur local a toujours la propriété Serveurs DNS du domaine pointant sur Résolu localement. Cette exception est dûe au fait de l'utilisation d'un serveur mandataire inversé.
Il faut donc, exceptionnellement, changer la propriété Serveurs DNS du domaine de notre serveur local.
| Server Manager > Domaines > Modifier. | Serveur DNS du domaine > dérouler et choisir Serveurs DNS de l'Internet > Modifier.
|
On s'assure du succès de l'opération. |
 |
 |
 |
Fichier /etc/hosts
On s'assure que le fichier /etc/hosts du serveur local soit correctement configuré.
# cat /etc/hosts #------------------------------------------------------------ # !!DO NOT MODIFY THIS FILE!! # # Manual changes will be lost when this file is regenerated. # # Please read the developer's guide, which is available # at http://www.contribs.org/development/ # # Copyright (C) 1999-2006 Mitel Networks Corporation #------------------------------------------------------------ 127.0.0.1 localhost 192.168.1.11 sme-92.micronator-101.org sme-92
Passerelle par défaut
On s'assure que la passerelle par défaut soit bien notre serveur principal dorgee.micronator.org (192.168.1.1).
Serveur physique
# route Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth1
Serveur virtuel
À la console du serveur.
# route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
pc-00001.micron * 255.255.255.255 UH 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
default pc-00001.micron 0.0.0.0 UG 0 0 0 eth1
Le Serveur SME-9.2 virtuel passe par la carte réseau du poste de travail (pc-00001.micron).
À la console du poste de travail, dans un écran de commandes, on lance la commande ipconfig.
> ipconfig Configuration IP de Windows ... Carte Ethernet Ethernet : Suffixe DNS propre à la connexion. . . : Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.81 Masque de sous-réseau. . . . . . . . . : 255.255.255.0 Passerelle par défaut. . . . . . . . . : 192.168.1.1 ...
On vérifie l'adresse IP du serveur. (Nous sommes en mode Serveur uniquement.)
# ifconfig eth1 Link encap:Ethernet HWaddr 08:00:27:06:AE:18 inet adr:192.168.1.11 Bcast:192.168.1.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1890 errors:0 dropped:0 overruns:0 frame:0 TX packets:1210 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:211092 (206.1 KiB) TX bytes:198261 (193.6 KiB) lo Link encap:Boucle locale inet adr:127.0.0.1 Masque:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1227 errors:0 dropped:0 overruns:0 frame:0 TX packets:1227 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:0 RX bytes:415992 (406.2 KiB) TX bytes:415992 (406.2 KiB)
L'adresse externe i.e. eth1 192.168.1.11, servira plus tard comme pointeur de destination pour le serveur mandataire inversé.
Préparation du Serveur principal
Vérification des domaines
Si auparavant on avait fait quelques tests, on vérifierait que le domaine micronator-101.org n'existe plus sur le serveur principal..
Comme on le voit, il n'existe aucune référence à micronator-101.org. Si oui, on doit supprimer ce domaine du serveur principal.
Le FQDN du serveur principal est: micronator.org.
Transformation du serveur principal en mandataire inversé
La prochaine étape est de modifier le serveur principal, dorgee.micronator.org, pour qu'il devienne un serveur mandataire inversé de notre serveur Web local sme-92.micronator-101.org.
À l'aide de PuTTY, on se logue sur le serveur principal.
login as: root root@192.168.1.1's password: Mot-de-passe
On vérifie qu'on est bien sur le serveur principal.
# hostname
dorgee
On vérifie l'adresse IP de son réseau LOCAL.
# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:50:8B:AE:88:89 inet adr:192.168.1.1 Bcast:192.168.1.255 Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8106669 errors:0 dropped:0 overruns:0 frame:0 TX packets:14527260 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 lg file transmission:1000 RX bytes:910237336 (868.0 MiB) TX bytes:17641271800 (16.4 GiB)
Configuration du serveur principal
On crée le domaine virtuel micronator-101.org sur le serveur principal.
# db domains set micronator-101.org domain
On indique que le serveur de noms pour ce domaine virtuel est sur l'internet.
# db domains setprop micronator-101.org Nameservers internet
On indique l'adresse de la cible i.e. le Serveur SME local hébergeant le domaine micronator-101.org.
# db domains setprop micronator-101.org ProxyPassTarget http://192.168.1.11/
On indique le chemin d'un gabarit pour ce nouveau domaine virtuel.
# db domains setprop micronator-101.org TemplatePath ProxyPassVirtualHosts
On signale les changements de configuration au serveur principal afin qu'il crée le nouveau domaine virtuel.
# signal-event domain-create micronator-101.org
On s'assure que le nouveau domaine virtuel a bien été créé.
db domains show ... micronator-101.org=domain Nameservers=internet ProxyPassTarget=http://192.168.1.11/ TemplatePath=ProxyPassVirtualHosts ...
Dans le gestionnaire Server Manager, sur le serveur principal qui est devenu un mandataire inversé, un nouveau domaine a été créé pour micronator-101.org.
Résultat final
| Serveur local physique |
Serveur local virtuel |
 |
 |
Vérification
On lance deux ping à la console du serveur principal.
# ping -c 2 micronator-101.org PING micronator-101.ddns.net (206.248.138.152) 56(84) bytes of data. 64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=1 ttl=64 time=0.028 ms 64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=2 ttl=64 time=0.041 ms --- micronator-101.ddns.net ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms
L'adresse IP 206.248.138.152 est celle du serveur principal et c'est lui qui répond car, un mandataire inversé ne transmet seulement que les requêtes Web.
On lance le navigateur TOR et on se rend à http://www.micronator-101.org.
Si nous avons recours à un service de DNS dynamique, il ne faut pas utiliser www avec un tel domaine.
Désinstallation du "service" mandataire inversé
Si on veut désinstaller ce service, pour quelque raison que ce soit, on exécute les commandes suivantes.
Sur le serveur principal
On supprime le domaine virtuel.
# db domains delete micronator-101.org
On signale les changements de configuration au serveur principal afin qu'il supprime le domaine virtuel.
# signal-event domain-modify
On vérifie avec grep que le domaine micronator-101.org n'existe plus sur le serveur principal.
# db domains show | grep micronator-101.org
Aucune information n'est retournée car, le serveur virtuel n'existe plus sur le serveur principal.
Sur le serveur local
Sur le serveur local, il faut remettre le pointeur Serveurs DNS du domaine vers Résolu localement.
Remarques importantes
Mise en garde
La sécurité est à surveiller car, le Serveur SME local est maintenant accessible depuis l'Internet.
Certificat
Lorsqu'un internaute accède le serveur local avec une requête https:
- Son navigateur se connecte au serveur principal et une négociation SSL débute.
- Le navigateur et le serveur principal échange leur clé publique et la communication chiffrée débute.
- Le navigateur envoie sa requête (nom d'hôte + URL).
- Sur le serveur principal, le démon Apache débute son rôle de mandataire inversé:
- il crée une connexion avec le serveur local,
- il lui envoie la requête du navigateur de l'internaute
- et termine en retournant la réponse au navigateur de l'internaute.
C'est le certificat du serveur mandataire inversé qui est utilisé pour chiffrer la communication avec le navigateur de l'internaute. Il n'y a aucune possibilité que le certificat du serveur local puisse être présenté au navigateur de l'internaute et qu'il soit utilisé pour le chiffrage.
Courriel
Un mandataire inversé est utilisé pour servir d'intermédiaire seulement pour les requêtes Web.
Si le serveur qui sert de mandataire reçoit un courriel, c'est qmail qui s'en occupe et non pas le démon Apache.
À toute fin pratique, le domaine local existe dans le gestionnaire Server Manager du serveur principal. Ainsi, si le récepteur du courriel n'existe pas en tant qu'utilisateur sur le serveur principal, le courriel est pris en charge par le paramètre Courriels destinés à des utilisateurs inconnus du gestionnaire Server Manager du serveur principal.
Toutefois, on peut accéder à Webmail du serveur local depuis l'Internet car, l'accès à Webmail est une requête Web: https://www.micronator-101.org/webmail.
WordPress
Si WordPress, sur le serveur local, envoie un courriel à un usager existant sur le serveur local, cet usager recevra ce courriel car, le domaine existe sur le serveur local et le courriel y sera envoyé sans passer par l'Internet. Si l'usager n'existe pas sur le serveur local, le courriel sera envoyé dans l'Internet via le serveur principal qui sert de passerelle pour le serveur local.
Mot de la fin
On peut utiliser cette marche à suivre afin de faire une demande de certificat Let's Encrypt pour un serveur intranet. Vous n'aurez pas à configurer l'authentification par clé publique SSH, pour que root puisse commnuniquer avec le serveur passerelle, afin de récupérer le certificat émis par Let's Encrypt. Le certificat sera directement déposé dans le répertoire /etc/dehydrated/certs/FQDN-de-votre-domaine du serveur local.
Victoire totale, hissons la bannière de la victoire.
