Le Cahier-10 du cours NethServer-101 décrit les étapes à suivre pour l'installation d'un service de Mandataire inversé sur un Serveur NethServer principal connecté à l'Internet afin qu'un autre Serveur NethServer 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.

Le Cours NethServer-101, se voulant une base solide pour la création d'un site de Commerce en ligne, comprend plusieurs cahiers:

1. Cahier-01: → Les bases de Linux.
2. Cahier-02: → Installation et configuration des logiciels prérequis sur le poste de travail.
3. Cahier-03: → Création d'un Serveur NethServer virtuel.
4. Cahier-04: → Serveur NethServer LOCAL & Let's Encrypt.
5. Cahier-05: → FAI, modem VDSL, domaine FQDN¹⁾ et Serveur NethServer physique.
6. Cahier-06: → Installation de WordPress.
7. Cahier-07: → Installation de l'extension de sécurité Wordfence.
8. Cahier-08: → WooCommerce, comptes chez Stripe et PayPal pour les paiements en ligne.
9. Cahier-09: → Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator.
10. Cahier-10: → Serveur mandataire inversé.
11. Cahier-11: → Sauvegarde/restauration avec BackupPC.

Le Cours NethServer-201 décrit l'installation et la configuration d'applications sur un serveur NethServer.

1. Cahier-201-01: → Dolibarr.
2. Cahier-201-02: → Odoo-12.
3. Cahier-201-03: → MediaWiki.
4. Cahier-201-04: → DokuWiki.
5. Cahier-201-05: → Moodle.
6. Cahier-201-06: → Proxmox.
7. Cahier-201-07: → Flectra.

Tous les logiciels nécessaires sont du domaine public ou LIBRE sous licence GPL; ils ne coûtent pas un sou. Le seul achat nécessaire est l'obtention d'un nom de domaine au prix initial de $15 CAD et son renouvellement annuel d'environ $30 CAD.

Après avoir suivi le Cours NethServer-101, vous posséderez un site de Commerce en ligne fiable et hautement sécuritaire. De plus, vous pourrez utiliser un clone de votre site, sur un Serveur NethServer virtuel roulant sur votre poste de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de votre site en ligne.

* Les captures d'écrans ne sont que des références.
** Les informations écrites ont préséance sur celles retrouvées dans les captures d'écrans. Veillez vous référer aux différents tableaux lorsque ceux-ci sont présents.
*** Une capture d'écran avec une accentuation en magenta indique qu'il faut remplacer cette distinction par vos propres paramètres ou implique un choix laissé à votre appréciation.

Manipulation, truc ou ruse pour se tirer d'embarras.
Une recommandation ou astuce.
Une note.
Une étape, note ou procédure à surveiller.
Paragraphe non complété ou non vérifié.
Danger pour la sécurité du système.

Toutes les commandes à la console ou à travers PuTTY sont précédées d'une invite qui est toujours présente.

[root@dorgee ~]# ping 10.10.10.75 -c1

PING 10.10.10.75 (10.10.10.75) 56(84) bytes of data.
64 bytes from 10.10.10.75: icmp_seq=1 ttl=64 time=1.63 ms

--- 10.10.10.75 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.639/1.639/1.639/0.000 ms
[root@dorgee ~]#

Commande à exécuter si ce n'est déjà fait.

Commande indiquée à titre d'information seulement.

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 à un 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).

Référence: http://docs.nethserver.org/en/v7/ui/ProxyPass.html.
La page Passerelle → Proxy inverse configure certains chemins et noms d'hôtes virtuels sous Apache, afin de transmettre la requête Web d'origine vers une autre URL.

● Nom
Le chemin d'accès à l'URL ou le nom de l'hôte virtuel.

● Description
Description de cette entrée telle que: Vers l'hôte toto.

● Accéder depuis les réseaux CIDR²⁾
Seuls les clients de certains réseaux peuvent être autorisés à se connecter en spécifiant une liste de réseaux CIDR séparés par des virgules.

☐ Nécessite une connexion SSL chiffrée
Si activé, le chemin de l'URL ou le nom d'hôte virtuel est accessible uniquement avec une connexion SSL/TLS.

● URL visée
L'URL vers laquelle la demande d'origine est transmise. Une URL se présente sous la forme .

☐ Accepter le certificat SSL non valide de la cible
Si l'URL cible utilise le protocole https, accepter son certificat même s'il n'est pas valide.

☐ Transférer l'en-tête HTTP “Host” vers la cible
Lorsqu'elle est activée, cette option transmet la ligne d'en-tête HTTP “Host” de la demande entrante à l'hôte mandaté, au lieu du “hostname” spécifié dans le champ URL cible.

● ▼ Actions supplémentaires
Créez un enregistrement sur la page DNS → alias de serveur pour le nom de l'hôte virtuel.

Référence: http://docs.nethserver.org/en/v7/proxy_pass.html.
Si la page de Proxy inverse ne suffit pas, vous pouvez toujours configurer manuellement Apache en créant un nouveau fichier dans le répertoire /etc/httpd/conf.d/.

Exemple: Créer le fichier /etc/httpd/conf.d/mon-mandataire.conf avec ce contenu:

<VirtualHost *: 443>
    SSLEngine On
    SSLProxyEngine On
    ProxyPass /  https://mon-domaine.org/
    ProxyPassReverse /https://mon-domaine.org/
</ VirtualHost>

<VirtualHost *: 80>
    NomServeur www.mon-domaine.org
    ProxyPreserveHost On
    ProxyPass / http://192.168.1.75/
    ProxyPassReverse / http://192.168.1.75/
</ VirtualHost>

Notre Serveur NethServer principal est directement branché à 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.

Tableau de bord du serveur principal → Configuration → DNS → onglet Hôtes.

● Pour notre serveur principal passerelle/DHCP, notre nom FQDN est micronator-101.org.

Sécurité → Service réseau.

● Le service HTTP de notre serveur principal est fonctionnel et accepte les requêtes de l'Internet et du réseau LOCAL (green, red).

Le site Web micronator-101.org de notre serveur principal passerelle/DHCP est accessible depuis l'Internet.

Référence: http://docs.nethserver.org/en/v7/ui/ProxyPass.html.
Notre Serveur NethServer 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 LOCAL ne possède pas d'adresse IP publique pour son réseau externe, mais une adresse privée (192.168.1.75 pour notre serveur intranet virtuel et 192.168.1.11 pour notre serveur intranet physique).

Si auparavant, on a fait quelques tests, on vérifie que le domaine micronator-dev.org n'existe plus sur le serveur principal.

Tableau de bord du serveur principal, on se rend à la page:

Configuration → DNS → onglet Hôtes.

Le FQDN du serveur principal est: micronator-101.org.

Configuration → DNS → onglet Alias du serveur

Comme on le voit, sur le serveur principal il n'existe aucune référence à micronator-dev.org. Si oui, on doit supprimer ce domaine du serveur principal.

- Tableau de bord du serveur principal → Administration → Gestionnaire des logiciels → onglet Disponible.

- Cocher Proxy inverse → AJOUTER.

APPLIQUER LES CHAN­GE­MENTS.

Recharger la page.

Le nouveau menu Proxy inverse est disponible.

On configure le Serveur NethServer principal micronator-101.org en mandataire inversé pour le Serveur NethServer LOCAL micronator-dev.org.

Tableau de bord du serveur principal → Passerelle → Proxy inverse → onglet Hôtes virtuels.

On entre les informations demandées pour micronator-dev.org.

SOUMETTRE.

Tableau de bord du serveur principal → Passerelle → Proxy inverse → onglet Hôtes virtuels.

On entre les informations demandées pour www.micronator-dev.org.

Si nous avons recours à un service de DNS dynamique, il ne faut pas utiliser www avec un tel domaine.

SOUMETTRE.

- Tableau de bord du serveur principal → Configuration → DNS → onglet Hôtes virtuels.

- Le Serveur NethServer principal est prêt à servir de mandataire inversé pour notre domaine LOCAL micronator-dev.org.

Si vous avec coché Créez un enregistrement sur la page DNS → alias de serveur pour le nom de l'hôte virtuel,

des entrées sont créées sur la page du serveur principal.

Configuration → DNS → onglet Alias du serveur.

Si notre Serveur NethServer LOCAL est physique, au paragraphe Configuration en mandataire inversé, il faut ajuster le paramètre Nom pour micronator-101.com et www.micronator-101.com.

On utilise le navigateur TOR pour accéder à notre site micronator-dev.org depuis l'Internet.
Si nous avons recours à un service de DNS dynamique, il ne faut pas utiliser www avec un tel domaine.

Lorsqu'un internaute accède le serveur LOCAL avec une requête https:

1. Son navigateur se connecte au serveur principal et une négociation SSL débute.

1. Le navigateur et le serveur principal échange leur clé publique et la communication chiffrée débute.

1. Le navigateur envoie sa requête (nom d'hôte + URL).

1. 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 envoie la requête du navigateur de l'internaute au serveur LOCAL, reçoit la réponse et
   - il termine en relayant la réponse au navigateur de l'internaute.

C'est le certificat du serveur roulant le module Proxy inverse qui est utilisé pour chiffrer la communication avec le navigateur de l'internaute et non pas le certificat du serveur LOCAL .

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.

À la console du serveur principal, on lance deux ping.

[root@dorgee ~]# ping -c 2 micronator-dev.org

PING micronator-dev.org (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.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.028/0.034/0.041/0.008 ms
[root@dorgee ~]#

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 http[s].

La sécurité est à surveiller, car le Serveur NethServer LOCAL est maintenant accessible depuis l'Internet.

Un mandataire inversé est utilisé pour servir d'intermédiaire seulement pour les requêtes Web http[s]. 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.

Ainsi, si le récipiendaire 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 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-dev.org/webmail.

Si WordPress du 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.

Victoire totale, hissons la bannière de la victoire.

© 2018-2019 RF-232
Auteur: Michel-André CLP.
Remerciement: Tous les contributeurs GNU/GPL.
Intégré par: Michel-André Robillard CLP.
Contact: michelandre at micronator.org

Répertoire de ce document: E:\000_DocPourRF232_general\RF-232_NethServer\RF-232_Cours_NethServer-101_Cahier-10_Mandataire_Inverse_2019-08-06_15h53.odt

<html><hr style=“width:50%; margin: 0 auto;”></html>

Ce document est uniquement destiné à informer. Les informations, ainsi que les contenus et fonctionnalités de ce do­cument sont fournis sans engagement et peuvent être modifiés à tout moment. RF‑232 n'offre aucune garantie quant à l'actualité, la conformité, l'exhaustivité, la qualité et la durabilité des informations, contenus et fonctionnalités de ce document. L'accès et l'utilisation de ce document se font sous la seule responsabilité du lecteur ou de l'utilisateur.

RF‑232 ne peut être tenu pour responsable de dommages de quelque nature que ce soit, y compris des dommages di­rects ou indirects, ainsi que des dommages consécutifs résultant de l'accès ou de l'utilisation de ce document ou de son contenu.

Chaque internaute doit prendre toutes les mesures appropriées (mettre à jour régulièrement son logiciel antivirus, ne pas ouvrir des documents suspects de source douteuse ou non connue) de façon à protéger le contenu de son ordina­teur de la contamination d'éventuels virus circulant sur la Toile.

Toute reproduction interdite Vous reconnaissez et acceptez que tout le contenu de ce document, incluant mais sans s’y limiter, le texte et les images, sont protégés par le droit d’auteur, les marques de commerce, les marques de service, les brevets, les secrets industriels et les autres droits de propriété intellectuelle. Sauf autorisation expresse de RF-232, vous acceptez de ne pas vendre, délivrer une licence, louer, modifier, distribuer, copier, reproduire, transmettre, afficher publiquement, exécuter en public, publier, adapter, éditer ou créer d’oeuvres dérivées de ce document et de son contenu.

Bien que nous utilisions ici un vocabulaire issu des techniques informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.