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.

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)

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 :

• 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 :

• Le

  frontend:3000

  routing

:

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 des règles de trafic, comme par exemple :

• Le hostname (admin.example.com)

• Le path (/api/orders)

• Le header (X-Client-Type)

 

Le Backend Pool : Un ensemble de backends, lorsqu'il y a plusieurs destinations possibles, par exemple dans le cas de la haute disponibilité.

 

L'endpoint : le serveur interne (VM, conteuneur, virtualhost, etc...) vers lequel la requête est redirrigée.

exemples :

frontend:3000

api-1:8080

admin:9000

 

4.IV. Le SSL Offloading / SSL Termination

4.1. Définition

Le 

Dans le cas du HTTP, les redirections sont relativement transparentes. Mais cela se corse dans le cas du HTTPS. En effet le reverse proxy gèreva devoir gérer le chiffrement TLS/SSLSSL/TLS à la place des serveursclients.

internes.

 Le

proxy

Il va alors :

1. Recevoir

   Reçoit laune connexion HTTPS

2. Déchiffrer

   Déchiffrela communication HTTPS

Si backend HTTP, envoyer la requête

Envoie du HTTP interne non chiffréchiffrée auxau backends

backend(s) HTTP.

4.2.

 Avantages

 

Les principaux avantages de cette méthode sont :

• 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

Le principal inconvénient est que le trafic n'est pas chiffré de bout en bout, aussi un attaquant qui arriverait à se positionner sur un réseau interne pourrait intercepter le flux d'information et en extraire les données.

Aussi, dans les infrastructures Zero Trust, il est préférable que le backend soit aussi en HTTPS.

 

 

Dans ce cas, le reverse proxy va :

Recevoir la connexion HTTPS Déchiffrer la trame, l'analyser et appliquer les middleware La chiffrer à nouveau en sortie pour la transmettre à l'endpoint.

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.V. Cas d’usaged'usages typiques

5.1.1 Microservices

5.2.2 Load balancing

Algorithmes courants :

5.3.3 Sécurité

6.VI. Outils courants

---

VII. Notions complémentaires

Spécialiste

7.1 Proxy TCP vs Proxy WEB

7.2 Persistance et observabilité

 

Avec la possibilité de lire les données applicatives, il est dès lors possible de rendre une session persistante en utilisant un jeton de session. Ainsi, dans le cas du load balancingbalancing, si une session est redirigée vers un backend, l'on s'assure que cette session utilisera ce même backend jusqu'à sa clôture.

Concernant l'observabilité, ces sessions peuvent être logguées de manière centralisée en utilisant des métriques prometheus et des traces distribuées (openTelemetry) rendant l'analyse beaucoup plus simple et permettant d'accélérer le diagnostic d'un dysfonctionnement ou la détection d'une attaque.

 

7.3 Failover

 

Comme évoqué plus haut, il est possible à travers un pool de gérer la haute performance.

disponibilité

Traefik

d'un

Orientéservice microservices,en 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 (comprendmultipliant les routes, headers, cookies)endpoints.

Mais

il

7.2.est WebSocketségalement &possible de redonder les reverse proxy

 en eux-même. Vu que ceux-ci sont capables de s'échanger les jetons de sessions afin de les persister, la perte d'un noeud deviens transparente pour l'utilisateur du service.

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.VIII. 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é.