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 X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Host 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, 10.0.0.10:8080).
• Un domaine (par exemple, example.com) dont les DNS A/AAAA pointent 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’empaqueter pour HAProxy

Installer certbot et obtenir le certificat (une seule fois)

#

 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

Regrouper et recharger automatiquement 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 example.com par l’IP/port de votre backend aux endroits indiqués

# /etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 50000 daemon defaults log global mode http option httplog timeout connect 5s timeout client 60s timeout server 60s http-reuse safe # Frontend : listen on 80/443, redirect to HTTPS, route ACME and app traffic frontend fe_https bind :80 bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1 # Force HTTPS http-request redirect scheme https unless { ssl_fc } # Basic security header http-response set-header Strict-Transport-Security "max-age=31536000 ; includeSubDomains ; preload" if { ssl_fc } # Preserve client info for your app option forwardfor header X-Forwarded-For http-request set-header X-Forwarded-Proto https if { ssl_fc } http-request set-header X-Forwarded-Host %[req.hdr(host)] # Simple rate cap : 100 requêtes / 10s par IP stick-table type ip size 100k expire 10m store http_req_rate(10s) http-request track-sc0 src acl too_fast sc0_http_req_rate gt 100 http-request deny status 429 if too_fast # Route ACME HTTP-01 challenges to local certbot (used during renewals) acl acme path_beg /.well-known/acme-challenge/ use_backend be_acme if acme # Route votre domaine vers le backend d'origine acl host_example hdr(host) -i example.com use_backend be_app if host_example default_backend be_app # Backend : votre serveur d'origine backend be_app balance leastconn option httpchk GET /health http-check expect status 200 server app1 10.0.0.10:8080 check # Backend pour servir les défis ACME (certbot standalone hook) backend be_acme server local 127.0.0.1:8081

Pourquoi cela fonctionne-t-il ?

• HAProxy termine TLS sur :443 et redirige :80 → HTTPS.
• Le trafic normal va vers votre origine à 10.0.0.10:8080.
• Seul /.well-known/acme-challenge/* est redirigé vers un petit serveur web local que Certbot exécutera lors des renouvellements.

Etape 4 – Démarrer, recharger et valider

#

 Valider la configuration sudo haproxy -c -f /etc/haproxy/haproxy.cfg # Activer et démarrer sudo systemctl enable --now haproxy # Recharger après modifications/renouvellements sudo systemctl reload haproxy

Étape 5 – Renouvellements sans intervention

Laissez Certbot se lier brièvement à :8081 pendant que HAProxy garde :80/:443 ouvert :

# Typiquement géré par le timer de systemd ; sans danger à exécuter manuellement pour les tests sudo certbot renew --deploy-hook "/etc/letsencrypt/renewal-hooks/deploy/haproxy.sh"  --http-01-port 8081 --pre-hook "systemctl start haproxy" --post-hook "systemctl start haproxy"

Lors du renouvellement, Certbot répond au défi sur le port 8081; HAProxy achemine déjà ce chemin vers 127.0.0.1:8081

Variantes (choisissez ce dont vous avez besoin)

A) Origines multiples par nom d’hôte

# Ajouter un frontend : acl host_api hdr(host) -i api.example.com use_backend be_api if host_api # Définir un backend API : 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 ou de fonctionnalités L7 ici.

frontend fe_tcp mode tcp bind :443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } use_backend be_tls_app if { req_ssl_sni -i example.com } backend be_tls_app mode tcp server app_tls 10.0.0.10:443 check

C) Proxy inverse minimal HTTP uniquement (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

# Le DNS doit pointer vers HAProxy dig +short example.com # HTTP doit rediriger vers HTTPS (301) curl -I http://example.com # HTTPS doit servir le contenu curl -I https://example.com # Voir les en-têtes que l'application reçoit (dans vos logs d'application) : # X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host

Conseils pour les pare-feux

• Verrouillez votre origine pour qu’elle n’accepte que le trafic provenant du serveur HAProxy (par exemple, avec ufw, firewalld ou des groupes de sécurité cloud).
• 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 un délai plus long).
• Exposez un point de terminaison /health dans votre application pour httpchk.
• Prévoyez des déploiements sans temps d’arrêt : videz un serveur(désactivé) pendant les déploiements, puis réactivez-le.

Avis important :si 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 dans le processus de configuration de manière efficace. 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