Comment créer un reverse Proxy avec HAProxy ⋆ AVA.HOSTING

Vue d’ensemble

Apprenez à mettre en place un reverse proxy avec HAProxy sur un VPS pour cacher votre IP d’origine réelle, améliorer les performances et protéger vos applications des tiers. Comment créer un reverse proxy avec HAProxy pour cacher l’IP réelle de votre serveur d’origine ?

Qu’est-ce qu’un reverse proxy ?

Un reverse proxy se situe entre les clients et vos serveurs. Il reçoit les requêtes entrantes, décide où les envoyer et renvoie les réponses, tout en gardant vos serveurs d’origine cachés de l’Internet public. Il peut également équilibrer la chargeentre plusieurs serveurs, ajouter des en-têtes de sécurité, limiter le débit des clients abusifs et centraliser la terminaison TLS (HTTPS). Voyez-le comme un videur intelligent : il dirige les gens vers les bonnes salles, mais garde les coulisses privées.

En bref, un proxy inverse est le cheval de bataille silencieux qui assure le bon fonctionnement de tout, tandis que votre serveur d’origine reste privé

Proxy inverse avec HAProxy : Comment ça marche

HAProxy est un puissant proxy L4/L7 et un équilibreur de charge. Les requêtes des clients atteignent d’abord HAProxy, où

TLS (HTTPS) peut être terminé.
Des en-têtes comme ##ATP_NOTR_13_CODE_TAG_NOTR_ATP###, ##ATP_NOTR_14_CODE_TAG_NOTR_ATP###, et ##ATP_NOTR_15_CODE_TAG_NOTR_ATP### sont ajoutés.
Le trafic est acheminé vers les backends par nom d’hôte, chemin d’accès ou règles personnalisées.
Les contrôles de santé, le basculement automatique, les limites de débit, la compression, la mise en cache légère, les WebSockets et le passage gRPC sont disponibles.
Des journaux détaillés et une page de statistiques en direct permettent d’observer la situation.

Conclusion : HAProxy simplifie votre architecture, renforce la sécurité et les performances, et facilite la mise à l’échelle

Avantages et inconvénients de HAProxy

Avantages (pourquoi HAProxy brille)

Haute performance et faible surcharge (événementiel, multithread).
L4 + L7 intelligents (TCP/SNI passthrough ou routage HTTP complet/réécritures).
Équilibrage de charge et contrôles de santé robustes (round-robin, leastconn, hachage ; contrôles actifs, basculement).
Fonctionnalités de sécurité (terminaison TLS, HSTS, ACL, limitation de débit via des tables d’autocollants, autorisation/refus d’IP).
Observabilité (journaux riches, statistiques en direct socket/page ; exportateurs Prometheus disponibles).
Fiabilité (rechargements gracieux, avec un temps d’arrêt proche de zéro ; testé en conditions réelles).
Faible encombrement (fonctionne pratiquement partout : Linux/BSD/conteneurs).

Inconvénients (compromis)

Courbe d’apprentissage (configuration puissante mais verbeuse).
L‘automatisation des certificats n’est pas intégrée (coupler avec Certbot/lego ou Data Plane API).
Découverte manuelle des services par défaut (les backends dynamiques ont besoin de templates/API).
Mise en cache / service statique intégré limité (utiliser CDN/Varnish/Nginx si nécessaire).
Pas de WAF communautaire natif (utiliser un WAF séparé ou HAProxy Enterprise).
Les réécritures complexes peuvent devenir fastidieuses.
Support Windows limité (meilleur sur Linux/BSD).

Ce dont vous aurez besoin

Un VPS/serveur public pour HAProxy (le reverse proxy).
Votre serveur d’origine (par exemple, ###ATP_NOTR_16_CODE_TAG_NOTR_ATP##).
Un domaine (par exemple, ##ATP_NOTR_17_CODE_TAG_NOTR_ATP###) avec DNS A/AAAA pointant vers l’IP publique du serveur HAProxy.

Conseil de confidentialité : pour vraiment cacher votre IP d’origine, assurez-vous que l’origine n’est pas accessible au public, parez-la pour qu’elle n’ accepte que le trafic provenant du serveur HAProxy, et évitez les enregistrements DNS qui révèlent l’origine

Étape 1 – Installer HAProxy

Ubuntu/Debian

sudo apt update
sudo apt install -y haproxy

RHEL/Alma/Rocky

sudo dnf install -y haproxy

Étape 2 – Obtenir un certificat TLS (Let’s Encrypt)

Nous allons laisser Certbot obtenir un certificat et nous allons l’intégrer à HAProxy

Installer certbot et obtenir le certificat (à usage unique)

# Ubuntu/Debian
sudo apt install -y certbot
sudo certbot certonly --standalone -d example.com --agree-tos -m you@example.com --non-interactive

Créer le bundle PEM de HAProxy (fullchain + privkey)

sudo mkdir -p /etc/haproxy/certs
sudo bash -c 'cat /etc/letsencrypt/live/example.com/fullchain.pem 
              /etc/letsencrypt/live/example.com/privkey.pem 
              > /etc/haproxy/certs/example.com.pem'
sudo chmod 600 /etc/haproxy/certs/example.com.pem

#######################

Regroupement automatique et rechargement de HAProxy lors des renouvellements

sudo bash -c 'cat >/etc/letsencrypt/renewal-hooks/deploy/haproxy.sh' <<'EOF'
#!/usr/bin/env bash
cat /etc/letsencrypt/live/example.com/fullchain.pem 
    /etc/letsencrypt/live/example.com/privkey.pem 
    > /etc/haproxy/certs/example.com.pem
systemctl reload haproxy
EOF
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/haproxy.sh

Étape 3 – Configuration minimale de HAProxy, prête pour la production (HTTPS + redirection)

Remplacez ##ATP_NOTR_18_CODE_TAG_NOTR_ATP### et l’IP/port de votre backend par ##ATP_NOTR_6_CODE_TAG_NOTR_ATP###Pourquoi cela fonctionne-t-il?

HAProxy met fin à TLS sur ##ATP_NOTR_19_CODE_TAG_NOTR_ATP## et redirige ##ATP_NOTR_20_CODE_TAG_NOTR_ATP###.
Le trafic régulier va vers votre origine à ##ATP_NOTR_21_CODE_TAG_NOTR_ATP###.
Seul /.well-known/acme-challenge/* est acheminé vers un minuscule serveur web local que Certbot exécutera lors des renouvellements.

Étape 4 – Démarrer, recharger et valider

# Validate config
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

# Enable and start
sudo systemctl enable --now haproxy

# Reload after edits/renewals
sudo systemctl reload haproxy

Étape 5 – Renouvellements sans intervention

Laissez Certbot se lier brièvement à ##ATP_NOTR_23_CODE_TAG_NOTR_ATP## pendant que HAProxy garde ##ATP_NOTR_24_CODE_TAG_NOTR_ATP### ouvert :
##ATP_NOTR_8_CODE_TAG_NOTR_ATP###Lors du renouvellement, Certbot répond au challenge sur le port ##ATP_NOTR_25_CODE_TAG_NOTR_ATP### ; HAProxy achemine déjà ce chemin vers ##ATP_NOTR_26_CODE_TAG_NOTR_ATP###.

Variantes (choisissez ce dont vous avez besoin)

A) Origines multiples par nom d’hôte

# Add in frontend:
acl host_api hdr(host) -i api.example.com
use_backend be_api if host_api

# Define an API backend:
backend be_api
  balance roundrobin
  option httpchk GET /healthz
  server api1 10.0.0.21:9000 check
  server api2 10.0.0.22:9000 check

B) TLS passthrough (l’origine gère TLS/mTLS)

Utiliser le mode TCP avec le routage SNI. Pas de réécriture d’en-tête ni de fonctionnalités L7 ici ##ATP_NOTR_10_CODE_TAG_NOTR_ATP###

C) Proxy inverse HTTP minimal (pas de TLS)

Pour les tests internes uniquement – utilisez HTTPS pour la production

global
  log /dev/log local0

defaults
  mode http
  log global
  option httplog
  timeout connect 5s
  timeout client  60s
  timeout server  60s

frontend public_http
  bind :80
  option forwardfor
  default_backend app

backend app
  server app1 10.0.0.10:8080 check

Vérifications rapides et dépannage

# DNS should point to HAProxy
dig +short example.com

# HTTP should redirect to HTTPS (301)
curl -I http://example.com

# HTTPS should serve content
curl -I https://example.com

# See headers the app receives (in your app logs):
# X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host

Conseils pour le pare-feu

Verrouillez votre origine pour qu’elle n’accepte que le trafic provenant du serveur HAProxy (par exemple, avec ufw, firewalld, ou les groupes de sécurité du nuage).
Bloquez éventuellement l’accès public direct à l’IP d’origine au niveau de votre fournisseur.

Notes finales

Gardez des délais raisonnables pour vos charges de travail (WebSockets/gRPC peuvent nécessiter des délais plus élevés).
Exposez un point de terminaison /health dans votre application pour httpchk.
Prévoyez des déploiements sans temps d’arrêt : drainez un serveur (disabled) pendant les déploiements, puis réactivez-le.

Avis importantSi vous n’êtes pas sûr de savoir comment configurer correctement le serveur, nous vous recommandons vivement de faire appel à un professionnel pour terminer la configuration. Il est essentiel de s’assurer que tous les réglages sont effectués avec précision, y compris la vérification des ports du pare-feu pour confirmer qu’il n’y a pas de blocage de port. Il est important d’avoir au moins une compréhension de base des pare-feu et des commandes Linux pour naviguer efficacement dans le processus de configuration. Veuillez noter que nous ne sommes pas responsables des dommages ou des problèmes qui peuvent survenir lors du processus de configuration. Toutes les informations fournies ici le sont uniquement à des fins de connaissances techniques et d’apprentissage. Nous vous remercions de votre compréhension