Qu'est-ce qu'un reverse proxy ? Guide pratique DNS et web

Un reverse proxy (proxy inverse) est un serveur qui reçoit des requêtes au nom d'un ou plusieurs serveurs d'arrière-plan et les transmet à la destination appropriée. Du point de vue d'un visiteur, le proxy est souvent le point d'accès public ; le navigateur ne se connecte pas directement au serveur d'application. Un reverse proxy peut terminer HTTPS, acheminer les requêtes par nom d'hôte ou par chemin, répartir le trafic, mettre en cache des réponses, compresser le contenu et appliquer des contrôles de sécurité. Le DNS pointe généralement un nom d'hôte public vers le proxy ou vers une adresse gérée par un fournisseur placée devant lui. Le proxy utilise ensuite sa propre configuration de routage pour atteindre l'application en amont.

Reverse proxy et proxy direct

Un proxy direct (forward proxy) agit pour les clients : le client envoie ses requêtes à travers lui pour atteindre des services externes, souvent pour des raisons de politique, de confidentialité ou d'accès réseau. Un reverse proxy agit pour les serveurs : des clients externes s'y connectent, et il transmet les requêtes aux services d'arrière-plan. Le mot « proxy » seul est donc ambigu. Dans une architecture de site web, un reverse proxy présente généralement le point d'accès public du service et masque les détails du groupe de serveurs d'arrière-plan. Il peut acheminer plusieurs domaines sur la même infrastructure et diriger différents chemins vers différentes applications tout en conservant un seul point de connexion public.

Le DNS et un reverse proxy résolvent des parties différentes de la connexion. Le DNS associe un nom d'hôte à une adresse publique ou à un alias. Une fois le client connecté, le proxy utilise l'information d'hôte HTTP, l'indication de nom de serveur TLS (SNI) et sa propre configuration pour choisir le bon service. Cela explique pourquoi une requête vers une IP seule peut afficher une page par défaut ou un avertissement de certificat alors que le domaine fonctionne : la requête peut ne pas inclure le contexte de nom d'hôte attendu. De même, modifier le DNS ne crée pas automatiquement une route de proxy correspondante ni ne provisionne un certificat. Les deux couches doivent s'accorder sur le nom d'hôte et la destination.

Les façons courantes dont le proxy se retrouve au cœur d'une panne

Un domaine peut se résoudre correctement alors que le reverse proxy pointe vers un serveur en amont hors service, utilise le mauvais port ou rejette un nom d'hôte qu'il n'a pas été configuré pour servir. Des échecs TLS peuvent survenir si la périphérie n'a pas de certificat valide ou si un serveur en amont chiffré est mal configuré. Un proxy peut aussi renvoyer un délai dépassé lorsqu'un serveur d'arrière-plan est surchargé ou injoignable. À l'inverse, une application saine peut sembler indisponible si le DNS dirige les clients vers la mauvaise adresse de proxy. Commencez par noter la réponse DNS, puis examinez dans l'ordre la réponse HTTP, la connexion TLS, les journaux du proxy et l'état du serveur d'arrière-plan.

• Confirmez que le DNS pointe vers le point d'accès public du proxy prévu.
• Vérifiez que le proxy dispose d'une règle d'hôte et d'un serveur en amont sain pour le domaine.
• Contrôlez les paramètres TLS de la périphérie et du serveur en amont lorsque HTTPS échoue.
• Utilisez les journaux du proxy pour distinguer les erreurs de routage des erreurs applicatives.
• Évitez de supposer qu'une recherche d'IP révèle le serveur d'arrière-plan.

Limites de sécurité et d'exploitation

Un reverse proxy peut réduire l'exposition directe des services d'arrière-plan, mais il ne constitue pas automatiquement une frontière de sécurité tant que des règles d'accès ne sont pas configurées et maintenues. L'origine ne devrait accepter le trafic que par les chemins prévus lorsque l'architecture le permet. Les interfaces d'administration ne doivent pas être placées sur des routes publiques sans authentification appropriée. Gardez le logiciel du proxy à jour, restreignez l'accès à l'administration et validez les en-têtes transmis, car le proxy devient un interprète de confiance des informations du client et du serveur en amont. Documentez quelle équipe est responsable du DNS, des règles du proxy, des certificats et du serveur d'arrière-plan afin que la réponse à incident ne reste pas bloquée pendant que chaque groupe suppose qu'une autre couche est responsable.

Pour la relation entre la périphérie publique et l'arrière-plan, lisez ce qu'est un serveur d'origine. Pour les réseaux de proxy mondiaux, voir comment les CDN utilisent le DNS. Une vérification domaine-vers-IP publique peut confirmer l'adresse présentée par le DNS, mais la route du reverse proxy et la santé de l'application demandent leurs propres vérifications opérationnelles. Garder ces responsabilités distinctes rend le diagnostic plus précis et évite qu'un résultat d'adresse soit pris pour un diagnostic complet de l'infrastructure.

Rendre explicite la responsabilité des règles du proxy

Un reverse proxy se situe à un point de passage critique : consignez qui est responsable du DNS, du routage par hôte, des certificats, des définitions de serveurs en amont et des politiques d'accès. Une modification peut être correcte dans une couche et échouer tout de même parce qu'une autre couche n'a pas été mise à jour : le DNS pointe vers le proxy, mais le proxy n'a pas d'hôte virtuel ; la route existe, mais le certificat correspond à un autre nom ; ou le serveur en amont est sain, mais un pare-feu bloque le sous-réseau du proxy. Conservez un schéma simple du chemin et une requête de référence valide pour chaque nom d'hôte de production. Pendant un incident, comparez la réponse DNS publique, le journal d'accès du proxy, l'état du serveur en amont et le journal de l'application en utilisant le même horodatage de requête ou le même identifiant de corrélation.