Browse Source

Ajout de commentaire pour l'article sur haproxy en tant que reverse proxy

pull/4/head
LecygneNoir 3 years ago
parent
commit
d55d84f7fc
3 changed files with 36 additions and 1 deletions
  1. +1
    -1
      content/comments/configurer-reverse-proxy-haproxy/26.md
  2. +15
    -0
      content/comments/configurer-reverse-proxy-haproxy/27.md
  3. +20
    -0
      content/comments/configurer-reverse-proxy-haproxy/28.md

+ 1
- 1
content/comments/configurer-reverse-proxy-haproxy/26.md View File

@ -1,5 +1,5 @@
email: courriel+blog@victor-hery.com
date: 2020-08-31T08:08+07:00
date: 2020-08-31T08:08+01:00
author: Victor
website: https://blog.victor-hery.com/
replyto: 25md

+ 15
- 0
content/comments/configurer-reverse-proxy-haproxy/27.md View File

@ -0,0 +1,15 @@
email:
date: 2020-10-17T22:06+01:00
author: Bola OUSSOU
Bonjour Mon cher
Mes sincères salutations et remerciements pour un tuto claire, limpide qui a penser au lecteur lors de sa rédaction.
J'ai toutefois besoin d’être qui sur le cas où:
* * * si différents serveur web existant après haproxy gèrent déjà eux même leur certificats (renouvellement auto y compris) comment en tenir compte dans la config haproxy ?
* * * certains des différents serveur gèrent aussi le forcing vers le https de toute requêtes venu en http. comment en tenir compte dans la config svp
Encore une foi Merci

+ 20
- 0
content/comments/configurer-reverse-proxy-haproxy/28.md View File

@ -0,0 +1,20 @@
email: courriel+blog@victor-hery.com
date: 2020-10-19T09:19+01:00
author: Victor
website: https://blog.victor-hery.com/
replyto: 27md
Hello !
Merci pour ton commentaire ! Désolé j'étais absent tout le week end je n'ai pas pu répondrep lus tôt :-)
Concernant le fait d'avoir les serveurs finaux qui gèrent les certificats, il y a 2 solutions principales :
- Utiliser haproxy en mode TCP, il se contente donc de balancer le flux TCP vers les serveurs finaux sans se préoccuper de l'http, et donc il délègue aussi l'établissement de la liaison SSL
- Si mettre le certificat également sur haproxy est envisageable, on peut avoir un fonctionnement "full ssl", c'est à dire que le navigateur parle en ssl à haproxy, qui lui même parle en ssl aux serveurs finaux (mot clef "ssl" dans les backend)
J'ai une préférence pour la seconde option qui permet de profiter du `mode http` d'haproxy et donc de toutes les options qui vont avec (notamment le travail sur les header http, x-forward-for, etc) mais le balancing TCP marche aussi très bien, il est plus brute de souche on va dire (et hors scope de cet article pour le coup, désolé)
Concernant le forcing http -> https , dans le cas où haproxy est en TCP, il ne fait rien applicativement donc c'est effectivement aux serveurs finaux de s'en occuper.
Dans le cas où haproxy est en full ssl, il faut faire attention à ce que haproxy gèrel a redirection, car comme lui parlera aux serveurs finaux en https, ceux-ci auront l'impression d'être tout le temps en https. Donc si haproxy ne fait pas la redirection, tu risques de te retrouver avec des cas trèèès ambigu où le navigateur sera en http, et le serveur final pensera lui être en https, autant dire que c'est crade ^^"
J'espère que ça pourra te donner des pistes ! Que ça soit pour le TCP ou le mode full ssl, la doc de haproxy reste vraiment bien faite je trouve : http://cbonte.github.io/haproxy-dconv/1.8/configuration.html

Loading…
Cancel
Save