Ou : routage entre serveurs par nom de domaine

Et oui, c'est ce dont on va parler ici. Comme ce n'est peut être pas très clair pour tout le monde, je vais me permettre une toute petite digression pour expliquer ce qu'est le routage, et plus précisément ce que j'appelle le routage par noms de domaine.

Merci pour cette digression.

Mais de rien.

Qu'est ce que le routage ? Ca consiste à se servir d'une unique machine (comunément appelée "le routeur") pour diriger des flux réseau vers différents autres matériels.

Ca sert le plus simplement du monde sur Internet, pour router les différents sous réseaux. Vous voulez joindre truc.truc.truc.truc, mais vous avez comme IP machin.machin.machin.machin, alors un routeur va pouvoir vous dire :

"Pour aller vers truc, c'est à gauche, mais si c'est pour aller vers bidule, c'est à droite. Quand à toi machin, tu es au milieu".

Ok, c'est résumé très vite pour les puristes, mais l'idée est là :-)

Il existe différents autres types de routage. On utilise ce terme parce que l'idée de donner des routes (ou des chemins) pour diriger des flux reste la même.

Une machine (routeur, PC, serveur, ...) reçoit un flux, et à partir de différents critères choisit de rediriger ce flux vers un autre matériel du réseau, l'objectif final étant bien sûr que ce flux arrive à destination de manière sûre.

Ca suffit oui ?

On y arrive. ;-)

EDIT décembre 2015 : j'ai écris un nouvel article pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.

Or donc, si vous avez plusieurs serveurs web mais une seule connexion Internet, alors vous avez sans doute déjà eu cette problématique.

Comment joindre plusieurs sites web sur différents serveurs depuis les Internet ?

La solution qui s'impose directement, c'est du routage de port.

Ce routage particulier consiste à router différents flux reçus depuis Internet vers des machines à l'intérieur de votre réseau local en se basant sur les ports réseaux utilisés. Ce n'est pas le lieu pour décrire un port réseau. Voyez ça comme une porte. Vous rentrez dans la même maison, mais selon que vous utilisiez la porte d'entrée ou la véranda, vous êtes "redirigés" vers une pièce différente de la maison.

 

Ce type de routage présente un inconvénient certain : chacun de vos utilisateurs doit spécifier la porte qu'il veut utiliser pour joindre le bon serveur.

En général, ça consiste à taper nomdedomaine.tld:port dans votre navigateur, ce qui n'est pas très pratique, et difficile à expliquer à vos clients. (Et oubliez de suite expliquer ça à Google and co)

C'est là qu'intervient ce super outil, le reverse proxy, ou mandataire inverse. Nous allons voir ici comment l'utiliser avec Apache, un serveur web populaire. Il est sans doute possible de le faire également avec NGinX ou lightHTTPD, mais ce n'est pas le sujet :-D

Le mandataire inverse va regarder le site que vous voulez joindre, et vous rediriger vers le bon serveur directement. Il servira ensuite d'intermédiaire sur le réseau entre vous et le serveur.

On veut du concret !

Voila voila !

Pré-requis matériel

Pour commencer, il va falloir définir un serveur mandataire. C'est sur ce serveur que nous allons configurer le mandataire inverse.

Il peut héberger lui-même des sites Internet, ou vous pouvez l'utiliser uniquement comme mandataire, ça n'a pas d'importance. Si vous utilisez cette solution à des vues industrielles, mieux vaut prévoir un serveur robuste, puisqu'il supportera toutes les requêtes vers tous vos sites web.

Ensuite, il vous faut configurer votre routeur/machinbox© pour rediriger tout le flux web (port 80) vers le serveur mandataire. Ceci se fait grâce à un routage de port classique. Toutes les requêtes web arriveront maintenant sur ce serveur, qui va décider quoi en faire.

En théorie on devrait pouvoir faire la même chose pour l'HTTPS, mais vu qu'il y a quand même des contraintes de certificats et que je n'ai pas testé, je préfère ne pas dire de bêtises ici.

Prérequis logiciel

Là, c'est simple. Il vous faut un serveur Apache installé et fonctionnel sur votre serveur mandataire. C'est tout. Un système de pare-feu ne serait également pas de trop (ce serveur est l'unique point d'entrée d'Internet, rappelons le :-) )

Il vous faut également (bien evidemment ?) une connexion ssh vers votre serveur, ou à défaut un écran-clavier-souris.

Plongeons dans le cambouis

Activation du module proxy Apache

Connectez vous sur votre serveur (mandataire), puis tapez :

$ sudo a2enmod proxy

$ sudo a2enmod proxy_http

 

Redémarrez ensuite Apache un petit coup

$sudo /etc/init.d/apache restart

 

Voila, c'est fait !

Configuration du routage

Ici, tout va se faire grâce au système d'hôte virtuel Apache.

Editez un fichier dans /etc/apache2/site-available/

$ sudo nano /etc/apache2/sites-available/monsite

 

Puis configurez votre hôte comme suit :

<VirtualHost *:80>
#
ServerName nomdedomaine.tld #
ProxyPreserveHost On
ProxyRequests off
ProxyPass / http://IPSERVEURWEBINTERNE/
ProxyPassReverse / http://IPSERVEURWEBINTERNE/
#
</VirtualHost>

 

Cela va permettre de rediriger toutes les requêtes sur nomdedomaine.tld en http vers le serveur IPSERVEURWEBINTERNE

 

C'est simple et efficace. Vous pouvez créer toutes vos autres redirections dans ce fichier, ou créer un fichier par redirection (plus propre mais plus contraignant). A vous de voir.

Une fois ces fichier créés, il vous faut activer les hôtes virtuels.

Faites

$ sudo a2ensite monsite

pour chaque fichier que vous avez créé.

 

Ensuite, rechargez la configuration Apache (pas besoin de redémarrer)

$ sudo /etc/init.d/apache2 reload

 

Tadam !

Il ne vous reste plus qu'à tester. De l'exterieur, essayez de joindre nomdedomaine.tld, tout doit fonctionner :-)

Et voila, vous avez économisé plein d'adresses IP publiques ! Mais pourquoi utiliser plusieurs serveurs Web derrière une seule IP petits coquinous ? Ça, ça vous regarde...

Si jamais j'ai la problématique un jour, je configurerai ça pour de l'HTTPS (mais honnêtement j'espère jamais :-D )

 

Et dans ce cas je rajouterai ça sur le blog, promis !  Voir juste au dessous !

Edit : Comme promis, la version https

Et oui, car finalement j'ai du m'y mettre :)

Tout d'abord, les limitations. Je n'ai réussit jusqu'alors qu'à configurer une connexion HTTPS entre le client et le reverse proxy.

Je n'ai pas réussit à avoir ensuite de l'HTTPS entre le reverse proxy et le vrai serveur web, ce qui veut dire que, au moins sur le réseau local, les données transitent en clair.

De mon point de vue ce n'est qu'un problème conceptuel, étant donné que le "réseau local" est en fait une liaison directe entre machines virtuelles sur le même hyperviseur, donc bon. Mais quand même, ce n'est pas très propre. Si jamais quelqu'un a une suggestion à ce sujet, qu'il me fasse signe :)

 

L'idée donc du reverse proxy en HTTPS, c'est que c'est le proxy qui va contenir les certificats https. Celui-ci va alors répondre à la place du serveur web, avec la bonne URL puique c'est un proxy, et transmettre ensuite les requêtes vers le serveur.

On a donc un schéma dans cette idée :

<Client>====https====<Proxy>----http----<serveur web>

Et en plus, c'est assez simple en fait.

On considérera ici que vous avez déja généré des certificats propres pour votre site (éventuellement auto-signés).

Il vous faudra activer le SSL sur votre reverse proxy : 

$ sudo a2enmod ssl
$ sudo /etc/init.d/apache2 restart

Ensuite, placez vos certificats (clef publique, clef privée) dans le dossier /etc/apache2/ssl/.

$ sudo cp moncertificat.* /etc/apache2/ssl/

Créez l'hôte virtuel qui servira pour votre redirection :

sudo nano /etc/apache2/site-available/monproxySSL

Et remplissez le avec ceci :

    <VirtualHost *:443>

    # Décommentez cette ligne et indiquez-y l'adresse courriel de l'administrateur du site
    #ServerAdmin webmaster@my-domain.com

    # Classique, votre nom de domaine
    ServerName monsite.tld

    # Si jamais vous avez d'autres domaines renvoyant sur ce site, utilisez la dircetive ServerAlias
    # Vous pouvez utiliser le joker * pour prendre en compte tout les sous-domaines
    #ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com

    # L'emplacement des logs.
    ErrorLog /var/log/apache2/monsite.tld-error.log
    LogLevel warn
    CustomLog /var/log/apache2/monsite.tld-access.log combined

    # SSL magic
    #
    # Il est nécessaire d'activer SSL, sinon c'est http qui sera utilisé
    SSLEngine On

    # On autorise uniquement les clefs de cryptage longue (high) et moyenne (medium)
    # SSLCipherSuite HIGH:MEDIUM

    # On autorise SSLV3 et TLSv1, on rejette le vieux SSLv2
    # SSLProtocol all -SSLv2

    # La clef publique du serveur :
    SSLCertificateFile /etc/apache2/ssl/moncertificat-cert.pem

    # La clef privée du serveur:
    # SSLCertificateKeyFile /etc/apache2/ssl/moncertificat-key.pem

    # Theses lines only apply of the rewrite module is enabled.
    # This is a security enhancement recommanded by the nessus tool.
    <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    </IfModule>
    <IfModule mod_rewrite.c>
    <IfModule mod_proxy.c>

    #Ne commentez jamais cette ligne, elle évite que votre serveur soit utilisé comme proxy par des gens mal-intentionnés.
    ProxyRequests Off

    # Cetet option passe les nom d'hôte au serveur, ce qui vous permet d'utiliser également des hôtes virtuels sur le serveur principal.
    ProxyPreserveHost On

    # Les lignes classiques de proxy. Comme dit au dessus, on passe le flux en http.
    ProxyPassReverse / http://IPSERVEURWEB/
    RewriteRule ^/(.*) http://IPSERVERUWEB/$1 [P,L]

    </IfModule&gt;
    </IfModule&gt;

    # Autoriser l'accès au contenu à travers le proxy.
    #Ne l'enlevez pas si vous voulez que le site fonctionne !
    <Location /&gt;
    Order deny,allow
    Allow from all
    </Location&gt;

    </VirtualHost&gt;


    <VirtualHost *:80&gt;
    # Cette partie va permettre de rediriger d'éventuelles requêtes en HTTP vers l'HTTPS
    # Vous pouvez également configurer le proxy à la place de la règle de réécriture si vous voulez autoriser l'accès en HTTP
    ServerName monsite.tld

    #ServerAlias www2.my-domain.com www.my-other-domain.com *.yet-another-domain.com

    # Theses lines only apply of the rewrite module is enabled.
    # This is a security enhancement recommanded by the nessus tool.
    <IfModule mod_rewrite.c&gt;
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} ^{TRACE|TRACK}
    RewriteRule .* - [F]
    </IfModule>

    # On renvoit toutes les requêtes HTTP vers l'HTTPS.
    Redirect permanent / https://monsite.tld/

    </VirtualHost>

N'oubliez pas bien sûr d'activer votre nouvel hôte virtuel :

$ sudo a2ensite monproxyssl
$ sudo /etc/init.d/apache2 reload

Et voila, votre reverse proxy doit fonctionner en HTTPS :)

 


Victor Avatar Victor est le rédacteur principal du blog.
Comments

Si vous avez des questions, si quelque chose n'est pas clair, n'hésitez pas à commenter !

  • Avatar
    Permalink

    lexal

    Posted on

    Oh t'es encore vivant !!

    Toujours pratique quand t'as plusieurs NDD.

  • Avatar
    Permalink

    Cedric BLAIRON

    Posted on

    Merci beaucoup pour cette explication simple et humoristique ;)
    Nous utilisons dans la boite le reverse Proxy apache depuis maintenant presque 10 ans et c'est efficace et très performant.
    Merci pour le rappel de quelques fonctionnalités.

    Cédric

  • Avatar
    Permalink

    Olivier Raulin

    Posted on

    Oh, article très intéressant, qui vient de me faire réaliser que je pouvais faire ça pour joindre différentes machines sans passer par des ports exotiques chez moi !

    C'est ... super cool :-)

    Je vais tenter de le faire avec nginx, histoire que ce soit plus léger ... j'en ferai sûrement un petit article sur mon blog (je penserai à toi, ne t'en fais pas :) )


    • Avatar
      Permalink

      Victor

      Posted on

      Merci pour le compliment :)
      C'est sûr que ça permet d'éviter pas mal de manipulation pas très simple avec des ports exotiques ^^
      Par contre, je ne suis pas pleinement satisfait des possibilités avec HTTPS (que la connexions soit chiffrée uniquement jusqu'au proxy, et plus ensuite..), mais pas trouvé mieux pour l'instant.
      Si jamais tu as des idées, n'hésite pas à me faire signe ;)

    • Avatar
      Permalink

      Olivier

      Posted on

      Comme promis, j'ai donc fait la même configuration pour nginx, pour ceux que ça peut intéresser : http://blog.olivier-raulin.fr/2013/08/28/mise-en-place-dun-reverse-proxy-nginx/

      J'imagine que tu as essayé dans le ProxyPassReverse de mettre https://ip/, ça ne fonctionnait pas ?

    • Avatar
      Permalink

      Victor

      Posted on

      Oui, c'est le premier truc que j'avais essayé, mais ça ne fonctionnait pas, de mémoire à cause du fait que l'IP dans le certificat ne correspondait pas à la cible, quelque chose dans ce gout là.
      Bon, j'y ai pas passé des jours non plus (disons des minutes :) )

      Merci pour la covnersion en NginX en tout cas, ça me donnera peut être l'occasion que j'attendais de découvrir ce serveur web ^^

  • Avatar
    Permalink

    Frederic

    Posted on

    bon tuto. Concernant ton problème de https pour que cela fonctionne, le reverse proxy doit définir dans le header X-Forwarded-Proto si la requête était en http ou https

    Par exemple la régle de récriture apache pour forcer l’https doit être :

    RewriteEngine On
    RewriteCond %{HTTP:X-Forwarded-Proto} !https
    RewriteRule / https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
    

    Bye !

  • Avatar
    Permalink

    vignemail1

    Posted on

    L'idéal serait de passer par deux reverse proxies qui sont redondant l'un avec l'autre.
    Pour cela il faut 4 adresses IP : 1 par serveur, 2 VIP (IP virtuelles) qui sont réparties sur les deux serveurs.
    Ensuite, on met au niveau DNS que les deux VIP sont les adresses d'accès aux services.
    Si l'un des serveurs tombe, sa VIP rejoint celle sur l'autre serveur et ainsi rend le service sans (quasiment) coupure.
    De même, il est idéal de redonner de la même manière les backend HTTP afin de pouvoir procéder à des maintenances.

    Parmi les avantages du reverse proxy :
    - si tu changes de serveur interne, c'est transparent pour les clients car tu n'as pas de délai de propagation DNS à gérer, tu restes avec le même couple FQDN/IP, tu changes juste les directives ProxyPass et ProxyPassReverse.
    - si ton site est piraté et qu'un script bot est installé pour donner un accès shell, il te suffit de retirer la route par défaut du backend HTTP et les accès initiés par le site piraté ne pourront s'établir car il n'y a pas de route par défaut.

    A noter pour le tuto : le vhost du serveur interne doit être le même que ce sur quoi le reverse proxy répond dû à la directive ProxyPreserveHost


    • Avatar
      Permalink

      Victor

      Posted on

      Je suis d'accord c'est le genre d'infra idéale, mais là pour le coup, juste pour héberger le blog ça consomme un peu trop de ressources ! C'est clair que les VIP permettent de régler plutôt facilement tout ce qui est problématique DNS pour qui veut de la haute disponibilité.

      Merci pour les com :)

  • Avatar
    Permalink

    Blotto

    Posted on

    Slt

    @Victor et pour les autres qui ont galeré comme moi !!!

    Le problème provient du proxy qui ne peut pas valider un certificat autosigné, il faut lui indiquer manuellement l'emplacement du certificat pour qu'il puisse effectuer la connexion.

    Modèle :

    client---https---proxy---https---serveur

    Copie le certificat SSL du serveur sur le Proxy via SCP et ensuite ajoute ceci a ton virtualhost.

    SSLProxyEngine On
    # Pointe le certificat directement
    SSLProxyCACertificateFile /etc/apache2/ssl/serveur.crt
    

    ou

    SSLProxyEngine On
    # Pointe le dossier du certificat
    SSLProxyCACertificatePath /etc/apache2/ssl/
    

    Marche impec sur Proxmox 3.1

  • Avatar
    Permalink

    SebFCT

    Posted on

    Bonjour,

    J'ai suivi ton tutoriel (très clair au passage) afin de tenter de gérer les problème que je rencontre en ce moment, mais sans résultat..

    Pour faire court, j'utilise un serveur proxmox qui contient plus conteneurs (dont ceux qui m'intéressent: CT101 et CT102).

    CT101 et CT102 sont tous deux des conteneur debian avec l'installation de base d'un site web (apache, php, ...).. Ils sont affichés respectivement lorsque je tape X.Y.Z.W:80 et X.Y.Z.W:8765 (X.Y.Z.W étant l'adresse de mon serveur).

    J'ai loué deux nom de domaine, j'aimerai les liés à chacun des conteneurs. J'ai donc rajoutés

    <VirtualHost *:80>
    
    ServerName domaine1.com
    ProxyPreserveHost On
    ProxyRequests off
    ProxyPass / http://X.Y.Z.WW:80/
    ProxyPassReverse / http:/X.Y.Z.W:80/
    
    </VirtualHost>
    
    <VirtualHost *:80>
    
    ServerName domaine2.com
    ProxyPreserveHost On
    ProxyRequests off
    ProxyPass / http://X.Y.Z.WW:8765/
    ProxyPassReverse / http:/X.Y.Z.W:8765/
    
    </VirtualHost>
    

    Au final le domaine1.com et le domaine2.com affichent tout les deux les meme contenu (celui du CT101). Par contre en ajoutant le bon port (celui attribué pour le CT102) tout fonctionne, mais bon.. on revient au problème soulevé sur tes première lignes d'article...

    Une idée du problème dans ma démarche?

    Merci d'avance!


    • Avatar
      Permalink

      Victor

      Posted on

      Hello SebFCT,

      Ta configuration à l'air correcte, le problème vient peut être plutôt de l'endroit où tu la mets.

      L'idée d'un reverse proxy est d'avoir un 3eme serveur devant les 2 autres capable de gérer les requêtes, ou au pire que l'un des 2 serveur serve de proxy.

      Cela impose que les DNS de tes domaines pointent sur ce serveur de proxy, ce qui semble bien être ton cas vu que domaine1 et domaine2 semblent arriver dessus.

      Par contre, avec ta conf, le proxy ne devrait écouter que sur le port 80, et donc le port 8765 devrait être fermé et renvoyer une erreur.
      Or ça n'a pas l'air d'être le cas, si domaine2.com:8765 répond.

      A première vue, ça me donne 2 idées : - Ton proxy tourne sur CT102, où le port 8765 écoute - Ou ta redirection de port depuis ton Ip publique (si tu en a une seule ?) fait que ce port écoute toujours depuis l'extérieur, et la redirection du port 80 elle redirige uniquement vers CT101 (et pas vers le proxy)

      Dans le premier cas, il faudrait enlever le proxypass. Sur CT102, tu n'aurais besoin que d'écouter sur le port 80, correctement pour domaine2, et avec proxy pour domaine1

      Dans le deuxième cas, il faudrait corriger ta redirection de port pour que le port 80 soit redirigé vers ton proxy, afin que ce soit lui qui gère bien les requêtes.

      3eme cas peut être, ton proxy tourne directement sur le serveur avec l'IP physique, MAIS, il y a toujours une redirection du port 80 vers CT101 ? Dans ce cas, la redirection de port prendra la priorité sur apache (puisque traité à une couche en dessous), donc il te faudra l'enlever pour que le proxy prenne la main.

      Ce sont les quelques idées de problèmes qui me viennent avec ta description.
      Si a priori ce n'est pas clair (ou incorrect), n'hésite pas à me préciser la configuration, surtout physique :) (ou est le proxy, etc)

      A bientôt

  • Avatar
    Permalink

    Doms

    Posted on

    Merci, vous m'avez sorti d'une impasse. Bravo.

  • Avatar
    Permalink

    Manu

    Posted on

    Merci pour ces explication c'est maintenant bien plus clairt ! J'ai pu faire moi aussi mon authentification sécurise et crypté avec ssl (SHA2) / reverse proxy et certificat client (ou mot de passe) ... Le tout tourne très bien depuis plusieurs semaines sur mon raspberry... Si vous souhaitez des détails j'ai moi aussi fait un tutoriel : http://domoticz.web2diz.net/?p=493 je me suis permit de faire référence à cette page.

    Merci encore et A+

  • Avatar
    Permalink

    batam

    Posted on

    Bonjour,voilà mon probleme:
    j'ai un site principal que je vais appeler monsite.com dont les fichiers se trouvent dans le répertoire /var/www/monsite.com.
    je veux donner accès à une personne tierce en lui atrribuant un nom par exemple monpetitsite, mais je veux que cette personne n'ait pas accès au repertoire /var/www, pour cela je veux lui laisser un accès complet dans un autre répertoire par exemple /home/user
    et lui créer un raccourci dans /var/www sans utiliser d'alias, mais en configurant un virtualhost. Je n'arrive pas à le faire.
    est il possible de m'aider merci

  • Avatar
    Permalink

    Rémi

    Posted on

    Merci pour ce tuto très bien documenté.
    Je bloque sur un soucis et je n'arrive pas à mettre le doigt sur le problème.
    Derrière une box (port 80 redirigé), j'ai un ordi fix + un raspberry pi. Chacun fait office de serveur web (apache). Le reverse proxy est activé sur le fix. Les domaines sont noip1 et noip2 pointant sur l'ip de ma box.

    /etc/apache2/sites-available/monsite1 (j'ai utilisé Defaut comme base et que j'ai configuré comme indiqué dans le tuto). De ce côté là toout est ok.

    /etc/apache2/sites-available/monsite2 (celui pointant sur le pi) : < VirtualHost *:80 > ServerName noip.zapto.org ProxyPreserveHost On ProxyRequests Off ProxyPass / http://192.168.1.10/v ProxyPassReverse / http://192.168.1.10/ < /VirtualHost > Cela fonctionne en local, mais pas à partir du Net. Ais-je omis quelque chose ?

    Lorsque je reload ou restart apache, j'ai comme retour : [....] Reloading web server config: apache2apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName [Tue Mar 17 21:31:35 2015] [warn] NameVirtualHost *:80 has no VirtualHosts . ok

    Je ne pige pas d'où vient le problème, y a t-il relations avec le fichier /etc/hosts ou un soucis dhcp avec /etc/network/interfaces ?

    Merci d'avance

  • Avatar
    Permalink

    Cyril

    Posted on

    Bonjour,
    Si je souhaite que quick.com soit un proxy de nddhidden.com. Et donc que quand je tappe http://quick.com/007-article-numero-un redirige sans que l'utilisateur au bout le sache vert http://nddhidden.com/007-article-numero-un
    Est-ce que cela fonctionnera ?

  • Avatar
    Permalink

    jeremy

    Posted on

    bonjour

    Merci pour ce tuto

    Comment gérer pour que le proxy mette en cache les pages afin de soulager le serveur web

  • Avatar
    Permalink

    Fred

    Posted on

    Bonjour,

    Merci pour ce tuto. Je suis un peu en galère avec mon reverse proxy, il fonctionne mais j'ai des problèmes d'encodage. Quand je charge ma page, les accents sont transformés, et ca passe de "é" à "é" par exemple. mais si je force à recharger la page sur mon navigateur (ctrl+R) les accents s'affichent correctement.

    Y a t'il une config particulière pour ne pas avoir de problèmes d'accents ?

    Encore merci

  • Avatar
    Permalink

    Jean-Michel

    Posted on

    Si tu es toujours intéressé pour avoir une connexion HTTPS avec tes serveurs interne depuis ton reverse proxy

    Rajoute dans la définition de ton virtualhost sur ton reverse proxy, ceci:

    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName   off
    

    ces deux instructions permettent d'utiliser un certificat auto-signé sur le serveur interne.

    c'est peut être pas très joli mais ça fonctionne.

  • Avatar
    Permalink

    piark

    Posted on

    Bonjour, Sauf erreur de ma part, ProxyRequests est a Off par défaut, commenter la ligne ne changera donc rien. https://httpd.apache.org/docs/2.4/fr/mod/mod_proxy.html#proxyrequests Cordialement.

Ajouter un commentaire / Add a Comment

Vous pouvez utiliser la syntaxe Markdown pour formatter votre commentaire.

You can use the Markdown syntax to format your comment.

Flux Atom pour commentaire / Comment Atom Feed

Published

Category

Système

Tags

Restez en contact