Skip to main content

Réseau - Le reverse proxy

DISCLAIMER : Cette page est en cours de rédaction et son contenu peut être faux ou inexact. Merci de lire cette page avec toutes les précautions nécessaires.

image.png

Difficulté : Intermédiaire


Notions : Réseau, protocoles WEB HTTP(s)


I. Introduction

Les architectures réseaux modernes font que de nombreux services passent aujourd'hui par une WEB UI et sont donc présentées à l'utilisateur en tant que "web Apps".

Ceci est également renforcé par les besoins de mobilité des utilisateurs et d'inter-connectivité entre les différentes entités participant à un flux de marchandises ( production, acheminement, entreposage, transformation, vente ).

De plus, l'explosion des API liés à l'automatisation des échanges (traçabilité produit, EDI, commandes, facturation électronique, etc...) ou des services (authentification, SSO, etc...) et du cloud font que les services amenés à être exposés se font nombreux.

Evidemment, pour des raisons de sécurité, ces services exposés sont répartis entre plusieurs zones réseaux micro-segmentées, dans des DMZ voire même dans des cas d'architecture hybride, décentralisée en tout ou partie sur le cloud.

Cela créée quelques problématiques :

  • Multiplication des adresses et ports

  • Risques de sécurité (IP internes visibles, surfaces d’attaque élargies)

  • Gestion complexe des certificats SSL/TLS

  • Absence de centralisation des logs, politiques, limitations, etc.

C'est pour cela que l'on met en place un "Reverse Proxy".

II. Le reverse proxy

2.1 Définition

Un reverse proxy est un serveur intermédiaire qui reçoit les requêtes des clients et les redirige vers un ou plusieurs serveurs internes, redondés ou non, dans une ou plusieurs zones différentes.

Ainsi, le client ne voit jamais les serveurs internes : il ne connaît qu’un point d’entrée unique.

2.2 Principe général

Un reverse proxy assure plusieurs fonctions essentielles :

  • Point d’entrée unique pour toutes les requêtes

  • Routage vers les services internes (path-based, host-based)

  • Load balancing (répartition de charge)

  • TLS/SSL termination (décryptage au bord du réseau)

  • Caching des réponses

  • Sécurité (WAF, rate limiting, filtrage)

  • Observabilité (logs, métriques, traces)

drawing-1-1788959539.png

Info : En effet, dans reverse proxy, il y a la notion de Proxy permettant par nature de faire du cache sur le trafic.

2.3 Reverse proxy vs forward proxy

Il ne faut toutefois pas confondre le 'Reverse Proxy' et le 'Forward Proxy'

Le rôle du Forward proxy est de masquer l'identité du client, de filtrer le traffic et se positionne côté client.

  • Exemple : Proxy d'entreprise (squid, sophos proxy, etc...)

Le rôle du Reverse proxy quand à lui est de masquer les serveurs, router les requêtes et participer à la sécurisation des services.

  • Exemple : nginx, HAproxy, traefik, etc...

III. Terminologie technique

 

L'on retrouve dans l'ordre :

drawing-1-1788960132.png

 

  • Les Entrypoints : Les points d'accès publics côté externe.

Par exemple si le client veux joindre https://app.example.com , le DNS va pointer vers l'IP publique du reverse proxy. Le reverse proxy reçoit la requête sur le port 443 exposé par NGINX ou Traefik.

L’entrypoint reçoit la requête, établit la connexion TLS, inspecte les headers et choisit une route.

 

  • Le middleware : Composant intermédiaire appliqué Avant la redirection au backend.

Il peut s'agir de fonctions spécifiques comme :

  • Redirections HTTP → HTTPS

  • Ajout d’en-têtes de sécurité

  • Rate limiting

  • Authentification

  • Réécriture d’URL Les middlewares sont très présents dans Traefik, Envoy, API Gateway.

 

3.3. Endpoint / Upstream

L’endpoint (ou upstream) est le serveur interne vers lequel le reverse proxy envoie la requête. Exemples :

  • frontend:3000

  • api-1:8080

  • admin:9000

3.4. Backend pool

Groupe de serveurs internes derrière une même route. Utilisé pour le load balancing.

3.5. Routing

Décision de redirection basée sur :

  • Le hostname (admin.example.com)

  • Le path (/api/orders)

  • Le header (X-Client-Type)


4. SSL Offloading / SSL Termination

4.1. Définition

Le reverse proxy gère le chiffrement TLS/SSL à la place des serveurs internes. Le proxy :

  1. Reçoit la connexion HTTPS

  2. Déchiffre la requête

  3. Envoie du HTTP interne non chiffré aux backends

4.2. Avantages

  • Performance : les backends n’ont plus à gérer les handshakes TLS (CPU intense)

  • Centralisation : un seul endroit pour gérer les certificats

  • Sécurité :

    • Choix des protocoles TLS

    • OCSP stapling

    • HSTS

    • Mise à jour des suites cryptographiques

  • Simplicité : les services internes peuvent rester en HTTP

4.3. Exemple NGINX

nginx


server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/ssl/certs/api.pem;
    ssl_certificate_key /etc/ssl/private/api.key;

    location / {
        proxy_pass http://api_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}


5. Cas d’usage typiques

5.1. Microservices

Un reverse proxy sert d’ingress pour un ensemble de services internes. Exemple :

  • / → frontend

  • /api → API

  • /auth → service d’authentification

5.2. Load balancing

Algorithmes courants :

  • Round-robin

  • Least connections

  • Weighted

5.3. Sécurité

  • WAF

  • Rate limiting

  • Filtrage des payloads

  • Masquage des IP internes

5.4. Caching

Cache des assets statiques ou réponses API pour réduire la charge backend.


6. Outils courants

NGINX

Le plus utilisé, très performant, très configurable.

HAProxy

Spécialiste du load balancing haute performance.

Traefik

Orienté microservices, configuration dynamique, middlewares puissants.

Envoy

Proxy moderne utilisé par Istio, très avancé (L7, observabilité, filtres).

Caddy

HTTPS automatique via Let’s Encrypt.


7. Points que tu pourrais ajouter au cours

7.1. L4 vs L7 Proxy

  • L4 : proxy TCP brut (ne lit pas HTTP)

  • L7 : proxy HTTP (comprend les routes, headers, cookies)

7.2. WebSockets & reverse proxy

Gestion des connexions persistantes (upgrade headers).

7.3. Observabilité

  • Logs centralisés

  • Metrics Prometheus

  • Traces distribuées (OpenTelemetry)

7.4. Failover & haute disponibilité

  • Proxy en cluster

  • Keepalived / VRRP

  • Load balancer devant le reverse proxy

7.5. API Gateway vs Reverse Proxy

Différences de philosophie (auth, quotas, transformations).


8. Conclusion

Le reverse proxy est un composant indispensable dans toute architecture moderne. Il permet :

  • De sécuriser les services internes

  • De centraliser le chiffrement TLS

  • De router intelligemment les requêtes

  • De répartir la charge

  • D’ajouter des politiques de sécurité sans toucher au code

  • De simplifier la gestion opérationnelle

Il constitue la porte d’entrée de l’infrastructure, le point où se concentrent les décisions critiques de sécurité, de performance et d’observabilité.

Back to top