Les proxys inverses sont un outil utile dans la boîte à outils de tout administrateur système. Ils ont de nombreuses utilisations, notamment l’équilibrage de charge, la protection contre les attaques DDOS
Que sont les proxys inverses ?
Un proxy standard, appelé Forward Proxy, est un serveur par lequel la connexion d’un utilisateur est acheminée. À bien des égards, c’est comme un simple VPN, qui se trouve devant votre connexion Internet. Les VPN en sont un exemple courant, mais ils incluent également des éléments tels que les pare-feu scolaires, qui peuvent bloquer l’accès à certains contenus.
Un proxy inverse fonctionne un peu différemment. C’est un outil backend utilisé par les administrateurs système. Au lieu de se connecter directement à un site Web diffusant du contenu, un proxy inverse comme NGINX peut s’asseoir au milieu. Lorsqu’il reçoit une demande d’un utilisateur, il transmet ou « proxy » cette demande au serveur final. Ce serveur est appelé « serveur d’origine » car c’est lui qui répondra réellement aux requêtes.
Alors qu’un utilisateur saura probablement s’il est acheminé via un proxy direct comme un VPN ou un pare-feu, les proxys inverses sont des outils principaux. Pour autant que l’utilisateur le sache, il se connecte simplement à un site Web. Tout ce qui se cache 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’un tas de requêtes provenant de l’IP du proxy inverse. Cela peut être un problème, mais la plupart des services proxy comme NGINX ajoutent des en-têtes comme X-Forwarded-For à la demande. Ces en-têtes informeront le serveur d’origine de l’adresse IP réelle du client.
À quoi servent les proxys inverses ?
Les proxys inverses sont assez simples dans leur concept mais s’avèrent être un outil étonnamment utile avec de nombreux cas d’utilisation inattendus.
L’équilibrage de charge
L’un des principaux avantages d’un proxy inverse est sa légèreté. Puisqu’ils ne font que transmettre les demandes, ils n’ont pas à effectuer une tonne de traitement, 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 proxy inverse devant, vous pouvez facilement avoir plusieurs serveurs d’origine. Par exemple, le proxy pourrait envoyer 50 % des requêtes à un serveur et 50 % à un autre, doublant ainsi la capacité du site Web. Des services comme HAProxy sont conçus pour bien gérer cela.
Il s’agit d’un cas d’utilisation très courant, et la plupart des fournisseurs de cloud comme Amazon Web Services (AWS) proposent l’équilibrage de charge en tant que service, ce qui vous évite d’avoir à le configurer vous-même. Avec l’automatisation du cloud, vous pouvez même augmenter automatiquement le nombre de serveurs d’origine en réponse au 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 et descendent, le tout rendu possible par un proxy inverse sous le capot.
EN RELATION: Comment démarrer avec les équilibreurs de charge élastiques d’AWS
Mise en cache
Étant donné qu’un proxy inverse répond souvent beaucoup plus rapidement 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 courantes. La mise en cache se produit lorsque les données de la page sont stockées sur le proxy inverse et ne sont demandées au serveur d’origine qu’une fois toutes les quelques secondes/minutes. Cela réduit considérablement la pression sur le serveur d’origine.
Par exemple, cet article que vous lisez actuellement a été servi par WordPress, qui doit communiquer avec une base de données SQL pour récupérer le contenu et les métadonnées de l’article. Faire cela pour chaque actualisation de page est un gaspillage étant donné que la page ne change pas vraiment. Ainsi, cette route peut être mise en cache et le proxy inverse renverra simplement la dernière réponse à l’utilisateur suivant, plutôt que de déranger à nouveau WordPress.
Un réseau dédié de proxys inverses qui mettent en cache votre contenu est appelé un réseau de diffusion de contenu, ou CDN. Les CDN comme CloudFlare ou Fastly sont très couramment utilisés par les grands sites Web pour accélérer la livraison mondiale. Les serveurs du monde entier qui mettent en cache le contenu sont appelés «nœuds périphériques», et en avoir beaucoup peut rendre votre site Web très accrocheur.
Protection du réseau et confidentialité
Étant donné que l’utilisateur ne sait pas ce qui se cache derrière le proxy inverse, il ne pourra pas facilement attaquer directement vos serveurs d’origine. En fait, les proxys inverses sont couramment utilisés avec les serveurs d’origine dans les sous-réseaux privés, ce qui signifie qu’ils n’ont aucune connexion entrante vers l’Internet extérieur.
Cela permet de garder votre configuration réseau privée, et bien que la sécurité par l’obscurité ne soit jamais infaillible, c’est mieux que de 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 d’API dans le sous-réseau privé, et le serveur d’API agit comme pare-feu pour la base de données, n’autorisant que les bonnes connexions à travers celui-ci.
Interface configurable
L’un des avantages des proxys inverses tels que NGINX est leur degré de configuration. Souvent, il est utile de les avoir devant d’autres services uniquement pour configurer la façon dont les utilisateurs accèdent à ces services.
Par exemple, NGINX est capable de limiter les 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 adresse IP. Cela n’arrête pas les attaques DDOS, mais c’est bien d’avoir.
NGINX est également capable de transférer le trafic de plusieurs noms de domaine avec des blocs « serveur » configurables. Par exemple, il pourrait envoyer des demandes à example.com à votre serveur d’origine, mais envoyez api.example.com à votre serveur API spécial, ou files.example.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 aux serveurs d’origine existants, comme les certificats HTTPS centralisés et la configuration des en-têtes.
Parfois, il est simplement utile d’avoir NGINX sur la même machine qu’un autre service local, simplement pour diffuser le contenu de ce service. Par exemple, les API Web ASP.NET utilisent un serveur Web interne appelé Kestrel, qui répond bien aux demandes, mais pas grand-chose d’autre. Il est très courant d’exécuter Kestrel sur un port privé et d’utiliser NGINX comme proxy inverse configurable.
Journalisation centralisée
Celui-ci est assez simple, mais le fait que la majeure partie de votre trafic passe par un seul service facilite la vérification des journaux. Le journal d’accès de NGINX contient de nombreuses informations utiles sur votre trafic, et bien qu’il ne surpasse pas les fonctionnalités d’un service comme Google Analytics, ce sont d’excellentes informations à avoir.
EN RELATION: Comment configurer un panneau d’analyse et de surveillance Elasticsearch pour votre entreprise