Outils pour utilisateurs

Outils du site


nethserver_101_cahier_10_mandataire_inverse

NethServer-101, Cahier-10: Mandataire Inversé

Description générale

Introduction

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.

But final de ce Cahier

Serveur virtuel

Serveur physique

Cours NethServer-101

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

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

Logiciels

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.

But final

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.

Particularités de ce document

Notes au lecteur

* 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.

Conventions

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.

[[email protected] ~]# 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
[[email protected] ~]#
Commande à exécuter si ce n'est déjà fait.
Commande indiquée à titre d'information seulement.


Mandataire inversé

Description

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.

Onglet Hôtes virtuels

CRÉER NOUVEAU

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

♦ Le chemin d'accès à l'URL correspond à une URL telle que:
un-domaine.com/chemin….

♦ Le nom de l'hôte virtuel correspond à une URL telle que:
nom-hote-virtuel.com (le nom FQDN du domaine de l'hôte).

Les requêtes correspondantes sont transférées à l'URL cible.

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

Accéder depuis les réseaux CIDR2)
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.

Alternative

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>

Veuillez vous reporter à la documentation officielle d'Apache pour plus d'informations:
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html


Serveur principal directement branché à l'Internet

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.


Serveur LOCAL

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

Serveur virtuel

Serveur physique


Serveur mandataire inversé

Vérification des domaines sur le serveur NethServer principal

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.

Installation du module Proxy inverse

- 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.


Configuration en mandataire inversé

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.


Résultat final

Serveur virtuel LOCAL


Serveur physique LOCAL

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.


Vérification

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.

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 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.

Vérification

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

[[email protected] ~]# 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
[[email protected] ~]#

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].

Remarques importantes

Mise en garde

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

Courriel

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.

WordPress

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.

Le mandataire inversé fonctionne correctement.



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


Crédits

© 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

Historique des modifications

VersionDateCommentaireAuteur
0.0.12018-09-05Début.Michel-André
1.0.02018-11-06Mise à jour complète.Michel-André
1.0.12018-11-09Ajout du paragraphe But final de ce cahier.Michel-André
2.0.02019-03-09Adaptation pour NethServer-7.6.1810.Michel-André
2.0.12019-04-23Corrections mineures.Michel-André
2.1.02019-06-25Mise à jour et corrections mineures.Michel-André
2.2.02019-07-27Ajustements pour DokuWikiMichel-André
12345678901 12345678901


AVIS DE NON-RESPONSABILITÉ

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.

Avertissement

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.

1)
FQDN: Dans le DNS, un Fully Qualified Domain Name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final. Référence: https://fr.wikipedia.org/wiki/Fully_qualified_domain_name.
2)
CIDR - Classless Inter-Domain Routing - Le routage interdomaine sans classe est une méthode d’allocation d’adresses IP et de routage IP. L'Internet Engineering Task Force a introduit le CIDR en 1993 en remplacement de la précédente architecture d'adressage classful. Son objectif était de ralentir la croissance des tables de routage sur les routeurs de l'Internet et d'aider à ralentir l'épuisement rapide des adresses IPv4. Référence:https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing.
nethserver_101_cahier_10_mandataire_inverse.txt · Dernière modification: 2019-08-06 16:01 par michelandre