Forward Proxy vs NAT

Forward Proxy vs NAT — Comparaison détaillée

Ces deux mécanismes masquent tous les deux l’identité des clients côté Internet, ce qui les fait souvent confondre. Pourtant ils opèrent à des couches OSI différentes, avec des objectifs et des capacités radicalement distincts.

---

Positionnement dans le modèle OSI

Couche 7 — Application    ┌──────────────────────┐
                          │   Forward Proxy      │  lit HTTP, HTTPS, FTP…
Couche 4 — Transport      │   (Squid, mitmproxy) │  comprend les URLs, headers
                          └──────────────────────┘

Couche 3 — Réseau         ┌──────────────────────┐
                          │       NAT            │  traduit des adresses IP
Couche 4 — Transport      │   (routeur/firewall) │  + ports (PAT)
                          └──────────────────────┘

Le NAT ne voit que des paquets IP — il ignore tout du contenu applicatif. Le Forward Proxy voit des requêtes HTTP/HTTPS — il comprend les URLs, les headers, les cookies.

---

Tableau comparatif complet

Critère	Forward Proxy	NAT
Couche OSI	L7 (Application)	L3/L4 (Réseau/Transport)
Ce qu’il manipule	Requêtes HTTP/HTTPS, URLs, headers	Adresses IP et ports (paquets)
Configuration côté client	Requise (variable http_proxy, PAC)	Transparente — le client ne sait pas
Connaissance du protocole	Oui — comprend HTTP, HTTPS, FTP	Non — flux opaque
Filtrage de contenu	Oui — peut bloquer par URL, domaine, mots-clés	Non — uniquement IP:port
Cache	Oui — met en cache les ressources HTTP	Non
Journalisation	URL, méthode, user-agent, code HTTP	IP source, IP dest, port, volume
Inspection TLS	Oui (avec SSL inspection / man-in-the-middle)	Non — les données TLS sont opaques
Authentification	Oui — peut exiger un login avant d’accéder au web	Non
Performances	Plus lent (traitement applicatif)	Très rapide (kernel/hardware)
Scalabilité	Limitée (stateful L7)	Haute (millions de connexions)
Masque l’IP client	Oui	Oui
Protocoles supportés	HTTP, HTTPS, FTP (limité)	Tous (TCP, UDP, ICMP…)

---

Flux réseau comparés

Avec NAT (PAT)

Client 192.168.1.10:5432
        │
        │  paquet : src=192.168.1.10:5432  dst=8.8.8.8:53
        ▼
  [ Routeur NAT ]
        │  traduit : src=203.0.113.1:10500 dst=8.8.8.8:53
        │  mémorise : 203.0.113.1:10500 ↔ 192.168.1.10:5432
        ▼
    8.8.8.8 (DNS Google)
        │  voit la requête venir de 203.0.113.1:10500
        │  répond à 203.0.113.1:10500
        ▼
  [ Routeur NAT ]
        │  retraduit : dst=192.168.1.10:5432
        ▼
Client reçoit la réponse

Ce que le routeur NAT ne sait pas : qu’il s’agit d’une requête DNS, ce que contient la réponse, quel utilisateur a lancé la requête.

---

Avec Forward Proxy

Client 192.168.1.10
        │
        │  CONNECT github.com:443 HTTP/1.1
        │  Proxy-Authorization: Basic dXNlcjpwYXNz
        ▼
  [ Proxy Squid :3128 ]
        │
        ├── Authentifie l'utilisateur ✅
        ├── Vérifie la politique (github.com autorisé ✅)
        ├── Logge : user=alice url=https://github.com heure=14h32
        ├── Ouvre une connexion TCP vers github.com:443
        │
        │  src=10.0.0.5:8841  dst=140.82.121.4:443
        ▼
    github.com
        │  voit la requête venir de 10.0.0.5 (IP du proxy)
        │  ne connaît pas 192.168.1.10

Ce que le proxy sait : qui a fait la requête, vers quel site, à quelle heure, avec quel navigateur, combien de données ont transité.

---

Ce que chacun peut (et ne peut pas) faire

Le NAT peut :

• Permettre à un réseau privé entier de sortir sur Internet avec une seule IP publique
• Bloquer les connexions entrantes non initiées depuis l’intérieur
• Fonctionner pour tout protocole (DNS, SSH, FTP, jeux en ligne, VoIP…)
• Opérer à très haute vitesse (traitement kernel, souvent hardware)

Le NAT ne peut pas :

• Bloquer facebook.com tout en autorisant linkedin.com (il ne voit que l’IP, pas le domaine)
• Journaliser quel utilisateur a visité quel site
• Mettre en cache des pages web
• Inspecter ou bloquer du contenu à l’intérieur d’une connexion TCP

---

Le Forward Proxy peut :

• Bloquer par URL, domaine, catégorie de site, mots-clés
• Authentifier les utilisateurs avant d’accorder l’accès
• Loguer précisément qui a visité quoi et quand
• Mettre en cache les réponses HTTP pour économiser la bande passante
• Inspecter le contenu HTTPS (avec SSL inspection)

Le Forward Proxy ne peut pas :

• Gérer du trafic non-HTTP natif (SSH, jeux, VoIP) sans configuration spécifique
• Opérer de manière transparente sans configuration du client (sauf avec WPAD/PAC ou interception transparente)
• Atteindre les performances d’un NAT kernel pour de très hauts débits

---

Peuvent-ils coexister ?

Oui, et c’est même la configuration standard en entreprise :

Réseau interne
      │
      ▼
[ Forward Proxy ]   ← filtre le trafic HTTP/HTTPS (Squid, Zscaler...)
      │
      ▼
[ Firewall ]        ← règles L3/L4 (IP, ports)
      │
      ▼
[ NAT Gateway ]     ← traduit l'IP du proxy vers l'IP publique
      │
      ▼
  Internet

Le proxy gère la politique applicative (qui accède à quoi). Le NAT gère la translation d’adresses (comment les paquets sortent).

---

Quand choisir quoi ?

Besoin	Solution
Permettre à un réseau privé d’accéder à Internet	NAT suffit
Bloquer des sites spécifiques par domaine	Forward Proxy
Journaliser les accès web par utilisateur	Forward Proxy
Gérer du trafic SSH, DNS, jeux en ligne	NAT
Mettre en cache les téléchargements (ex: apt, Docker images)	Forward Proxy
Inspection HTTPS / DLP	Forward Proxy
Performance maximale, haut débit	NAT
Conformité réglementaire sur les accès web	Forward Proxy

---

En relation avec

• Proxy — Vue d’ensemble — hub : forward proxy, reverse proxy, outils, comparatif
• NAT — détail du mécanisme de translation d’adresses
• Forward Proxy — détail du proxy applicatif sortant
• Reverse Proxy — proxy côté serveur (à ne pas confondre)
• Pile réseau — Vue d’ensemble — comprendre pourquoi la couche OSI change tout (L3 vs L7)
• Table de Routage — le NAT s’appuie sur les routes pour acheminer les paquets traduits
• Internet Gateway (IGW) — le NAT sort sur Internet via l’IGW