Reverse proxy et répartition de charge : HAProxy sur pfSense

Un reverse proxy (proxy inverse) est un serveur placé devant un ou plusieurs serveurs web : il reçoit les requêtes des clients à leur place, les transmet au bon serveur, puis renvoie la réponse. Quand il répartit les requêtes entre plusieurs serveurs identiques, en vérifiant qu'ils sont en état de répondre, on l'appelle répartiteur de charge (load balancer). Ce chapitre explique à quoi sert un reverse proxy, ses notions (frontend, backend, terminaison TLS, contrôles de santé), sa mise en place avec le paquet HAProxy de pfSense pour publier le site de suivi de Sorbier, et l'équivalent avec Nginx. Les règles et la DMZ qui l'entourent sont dans le cours pfSense : DMZ et proxy inverse HAProxy.

Proxy ou reverse proxy ?

Le proxy de filtrage de la navigation est traité dans Cybersécurité des infrastructures ; ce chapitre ne parle que du reverse proxy.

Ce qu'un reverse proxy apporte

Jusqu'ici, Sorbier publiait son site de suivi par une simple redirection de port (NAT) : le pare-feu envoyait tout le TCP 443 reçu sur 203.0.113.17 vers srv-web (192.168.10.225). Ça marche pour un site. Les limites arrivent vite :

• Une seule adresse publique, un seul site par port. Avec du NAT, tout le TCP 443 va vers une seule machine. Un reverse proxy lit le nom demandé (en-tête Host, ou SNI en TLS) et envoie suivi.sorbier.example vers un serveur, portail.sorbier.example vers un autre, sur la même adresse et le même port.
• Les certificats sont éparpillés. Le reverse proxy fait la terminaison TLS (SSL offloading) : il détient les certificats publics et les renouvelle (ACME) à un seul endroit.
• Les serveurs sont exposés. Le client ne parle jamais directement à srv-web ; le reverse proxy peut rejeter les requêtes mal formées, limiter le débit, ajouter les en-têtes de sécurité, et, avec un module de pare-feu applicatif (WAF), bloquer des attaques web connues.
• Une panne de serveur est une panne du site. Avec deux serveurs derrière lui, le reverse proxy répartit les requêtes et retire automatiquement celui qui ne répond plus.

Le vocabulaire de HAProxy

Les mêmes notions existent dans tous les reverse proxys, sous des noms proches.

Les algorithmes de répartition

Avec des poids, un serveur de poids 3 reçoit trois fois plus de requêtes qu'un serveur de poids 1 : sur 100 requêtes, 75 et 25. La redondance complète d'un service (répartition, basculement, cluster) est traitée dans le cours Haute disponibilité.

Publier le site de suivi avec HAProxy sur pfSense

HAProxy est un paquet de pfSense. Le paquet acme obtient et renouvelle les certificats Let's Encrypt. Les étapes, avec les noms des menus de pfSense CE 2.8 :

1. Installer les paquets. System > Package Manager > Available Packages : installe acme, puis haproxy.

2. Libérer le port 443. L'interface d'administration de pfSense (webConfigurator) écoute par défaut sur le 443 de toutes les interfaces : HAProxy ne pourrait pas s'y installer. Dans System > Advanced > Admin Access, change le TCP port (par exemple 8443). L'interface d'administration ne doit, de toute façon, jamais être joignable depuis le WAN : les règles du pare-feu la réservent au VLAN d'administration.

3. Obtenir le certificat. Dans Services > Acme Certificates : onglet Account Keys, crée une clé de compte pour l'ACME Server « Let's Encrypt Production ACME v2 » et enregistre-la ; onglet Certificates, crée le certificat de suivi.sorbier.example avec une méthode de validation (défi DNS chez l'hébergeur de la zone, ou défi HTTP), puis Issue. Dans General Settings, active la tâche planifiée (Cron Entry) qui renouvelle les certificats.

4. Créer le backend. Services > HAProxy, onglet Backend, Add :

5. Créer le frontend. Onglet Frontend, Add :

6. Activer HAProxy. Onglet Settings : coche Enable HAProxy, règle Maximum connections, puis Save et Apply Changes.

7. Adapter les règles du pare-feu. Supprime l'ancienne redirection de port 443 vers srv-web (Firewall > NAT). Dans Firewall > Rules > WAN, autorise TCP 443 à destination de WAN address (le pare-feu lui-même, où écoute HAProxy). Aucune règle n'est nécessaire sur la DMZ : les règles de pfSense filtrent le trafic qui entre par une interface, et le trafic émis par le pare-feu lui-même (HAProxy vers srv-web) est autorisé par défaut ; vérifie seulement que le pare-feu local de srv-web accepte TCP 80 depuis 192.168.10.238. Pour la redirection HTTP vers HTTPS, ajoute un second frontend sur le port 80 dont l'action redirige vers https, ou laisse srv-web renvoyer un 301.

L'adresse du vrai client

Derrière un reverse proxy, srv-web voit toutes les connexions venir du pare-feu (192.168.10.238), pas des clients. Ses journaux, ses statistiques et ses éventuelles protections par adresse deviennent inutiles. L'en-tête X-Forwarded-For, ajouté par le proxy (case Use forwardfor option), contient l'adresse du vrai client. Il faut dire au serveur web de la croire, mais seulement quand la requête vient du proxy :

# Sur srv-web, dans le bloc http ou server de Nginx
set_real_ip_from  192.168.10.238;
real_ip_header    X-Forwarded-For;

La même chose avec Nginx ou HAProxy sous Debian

Sans pfSense, le reverse proxy est un serveur Debian dans la DMZ. Avec Nginx :

upstream suivi {
    server 192.168.10.225:80 max_fails=3 fail_timeout=30s;
    server 192.168.10.227:80 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl;
    http2 on;
    server_name suivi.sorbier.example;
    ssl_certificate     /etc/letsencrypt/live/suivi.sorbier.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/suivi.sorbier.example/privkey.pem;

    location / {
        proxy_pass http://suivi;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Nginx libre ne fait que des contrôles de santé passifs : il retire un serveur après 3 échecs (max_fails) sur des requêtes réelles, pendant 30 secondes (fail_timeout). Les contrôles actifs, qui interrogent les serveurs en permanence, sont réservés à sa version commerciale. HAProxy (version 3.0 dans Debian 13) les fait en standard :

# /etc/haproxy/haproxy.cfg (extrait)
frontend ft-public
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/
    mode http
    option forwardfor
    http-request redirect scheme https unless { ssl_fc }
    acl acl-suivi hdr(host) -i suivi.sorbier.example
    use_backend bk-suivi if acl-suivi

backend bk-suivi
    mode http
    balance roundrobin
    option httpchk GET /
    server srv-web  192.168.10.225:80 check inter 2s fall 3 rise 2
    server srv-web2 192.168.10.227:80 check inter 2s fall 3 rise 2

check inter 2s fall 3 rise 2 : un contrôle toutes les 2 secondes, un serveur déclaré hors service après 3 échecs consécutifs, et de retour après 2 succès. Vérifie la configuration avec haproxy -c -f /etc/haproxy/haproxy.cfg avant systemctl reload haproxy. La répartition de charge avec HAProxy et keepalived est déroulée pas à pas dans le cours Haute disponibilité.

Exercices