Les reverse proxies sont un outil utile dans la boîte à outils de tout administrateur système. Ils ont de nombreuses utilisations, notamment l’équilibrage de la charge, la protection contre les attaques DDOS.
Que sont les reverse proxies ?
Un proxy ordinaire, appelé Forward Proxy, est un serveur par lequel la connexion d’un utilisateur est acheminée. À bien des égards, il ressemble à un simple VPN, qui se trouve en face de votre connexion Internet. Les VPN en sont un exemple courant, mais ils comprennent également des éléments tels que les pare-feu des écoles, qui peuvent bloquer l’accès à certains contenus.
Un proxy inverse fonctionne un peu différemment. Il s’agit d’un outil d’arrière-plan utilisé par les administrateurs système. Au lieu de se connecter directement à un site Web servant du contenu, un proxy inverse comme NGINX peut se situer au milieu. Lorsqu’il reçoit une requête d’un utilisateur, il l’envoie, ou « proxy », au serveur final. Ce serveur est appelé « serveur d’origine » car c’est lui qui répondra réellement aux demandes.
Alors qu’un utilisateur saura probablement s’il est acheminé par un forward proxy comme un VPN ou un pare-feu, les reverse proxies sont des outils de backend. Pour autant que l’utilisateur le sache, il se connecte simplement à un site web. Tout ce qui se trouve derrière le proxy inverse est caché, ce qui présente également de nombreux avantages.
Cet effet se produit également en sens inverse. Le serveur d’origine n’a pas de connexion directe avec l’utilisateur et ne verra qu’une série de requêtes provenant de l’IP du proxy inverse. Cela peut être un problème, mais la plupart des services de proxy comme NGINX ajouteront des en-têtes comme X-Forwarded-For à la requête. Ces en-têtes informeront le serveur d’origine de l’adresse IP réelle du client.
Comment les services de streaming savent-ils que vous utilisez un VPN ?
À quoi servent les mandataires inversés ?
Les mandataires inversés sont assez simples dans leur concept, mais ils s’avèrent être un outil étonnamment utile dans de nombreux cas d’utilisation inattendus.
Équilibrage de la charge
L’un des principaux avantages d’un proxy inverse est sa légèreté. Puisqu’ils se contentent de transmettre les demandes, ils n’ont pas à effectuer une tonne de traitements, en particulier dans les situations où une base de données doit être interrogée.
Cela signifie que le goulot d’étranglement est souvent le serveur d’origine, mais avec un reverse proxy en face de lui, vous pouvez facilement avoir plusieurs serveurs d’origine. Par exemple, le proxy peut envoyer 50 % des demandes à un serveur et 50 % à un autre, doublant ainsi la capacité du site Web. Des services comme HAProxy sont conçus pour bien gérer ce type de situation.
Il s’agit d’un cas d’utilisation très courant et la plupart des fournisseurs de services en nuage, comme Amazon Web Services (AWS), proposent l’équilibrage de la charge en tant que service, ce qui vous évite d’avoir à le configurer vous-même. Grâce à l’automatisation du cloud, vous pouvez même augmenter automatiquement le nombre de serveurs d’origine en fonction du trafic, une fonctionnalité appelée « auto-scaling ».
Les équilibreurs de charge comme Elastic Load Balancer d’AWS peuvent être configurés pour se reconfigurer automatiquement lorsque vos serveurs d’origine montent ou descendent, tout cela étant rendu possible par un proxy inverse sous le capot.
Mise en cache
Étant donné qu’un proxy inverse est souvent beaucoup plus rapide à répondre que le serveur d’origine, une technique appelée mise en cache est couramment utilisée pour accélérer les requêtes sur les routes communes. La mise en cache consiste à stocker les données de la page sur le proxy inverse et à ne les demander au serveur d’origine qu’une fois toutes les quelques secondes/minutes. Cela réduit considérablement la charge sur le serveur d’origine.
Par exemple, l’article que vous êtes en train de lire a été servi par WordPress, qui doit communiquer avec une base de données SQL pour récupérer le contenu de l’article et les métadonnées. Faire cela à chaque rafraîchissement de page est un gaspillage, étant donné que la page ne change pas vraiment. Cette route peut donc être mise en cache, et le mandataire inverse se contentera de renvoyer la dernière réponse à l’utilisateur suivant, plutôt que d’ennuyer à nouveau WordPress.
Un réseau dédié de reverse proxies qui mettent votre contenu en cache s’appelle un Content Delivery Network, ou CDN. Les CDN comme CloudFlare ou Fastly sont très couramment utilisés par les grands sites Web pour accélérer la diffusion globale. Les serveurs qui mettent le contenu en cache dans le monde entier sont appelés « edge nodes » (nœuds de périphérie), et le fait d’en avoir beaucoup peut rendre votre site Web très rapide.
Protection du réseau et confidentialité
Comme l’utilisateur ne sait pas ce qui se trouve derrière le proxy inverse, il ne pourra pas facilement attaquer directement vos serveurs d’origine. En fait, les reverse proxies sont généralement utilisés avec des serveurs d’origine dans des sous-réseaux privés, ce qui signifie qu’ils n’ont aucune connexion entrante vers l’Internet extérieur.
La configuration de votre réseau reste ainsi privée et, même si la sécurité par l’obscurité n’est jamais infaillible, il vaut mieux la laisser ouverte aux attaques.
Cette confiance inhérente peut également être utile lors de la planification de votre réseau. Par exemple, un serveur API qui communique avec une base de données est similaire à un proxy inverse. La base de données sait qu’elle peut faire confiance au serveur API dans le sous-réseau privé, et le serveur API agit comme un pare-feu pour la base de données, n’autorisant que les bonnes connexions.
Frontal configurable
L’un des avantages des reverse proxies comme NGINX est qu’ils sont hautement configurables. Souvent, il est utile de les placer devant d’autres services afin de configurer la manière dont les utilisateurs accèdent à ces services.
Par exemple, NGINX est capable de limiter le débit des requêtes à certaines routes, ce qui peut empêcher les abuseurs de faire des milliers de requêtes aux serveurs d’origine à partir d’une seule IP. Cela n’empêche pas les attaques DDOS, mais c’est une bonne chose.
NGINX est également capable de transférer le trafic provenant de plusieurs noms de domaine avec des blocs « serveur » configurables. Par exemple, il peut envoyer des requêtes vers exemple.com à votre serveur d’origine, mais envoyer api.exemple.com à votre serveur API spécial, ou files.exemple.com à votre stockage de fichiers, et ainsi de suite. Chaque serveur peut avoir sa propre configuration et ses propres règles.
NGINX est également capable d’ajouter des fonctionnalités supplémentaires par-dessus les serveurs d’origine existants, comme les certificats HTTPS centralisés et la configuration des en-têtes.
Parfois, il est utile d’avoir NGINX sur la même machine qu’un autre service local, simplement pour servir le contenu de ce service. Par exemple, les API web ASP.NET utilisent un serveur web interne appelé Kestrel, qui est bon pour répondre aux demandes, mais pas beaucoup plus. Il est très courant d’exécuter Kestrel sur un port privé et d’utiliser NGINX comme reverse proxy configurable.
Journalisation centralisée
Celui-ci est assez simple, mais le fait que la plupart de votre trafic passe par un seul service facilite la vérification des journaux. Le journal d’accès de NGINX contient beaucoup d’informations utiles sur votre trafic, et bien qu’il ne batte pas les caractéristiques d’un service comme Google Analytics, c’est une bonne information à avoir.
4.5