Qu’est-ce qu’un reverse proxy et comment ça marche ?
Les proxys inverses sont un outil utile dans la boîte à outils de tout administrateur système. Ils ont de nombreuses utilisations, y compris l’équilibrage de charge, la protection DDOS
Qu’est-ce qu’un proxy inverse ?
Un serveur proxy standard, appelé proxy de transfert, est un serveur via 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. Il s’agit d’un outil interne utilisé par les administrateurs système. Au lieu de se connecter directement au site Web qui diffuse le contenu, un proxy inverse tel que 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é le « serveur d’origine » car ce sera celui qui répondra aux requêtes.
Alors que l’utilisateur est susceptible de savoir s’il est acheminé via un proxy direct tel qu’un VPN ou un pare-feu, les proxys inverses sont des outils internes. Pour autant que l’utilisateur le sache, il se connecte simplement au site Web. Tout ce qui se cache derrière un proxy inverse est caché et cela présente également de nombreux avantages.
Cependant, 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’adresse IP du proxy inverse. Cela peut être un problème, mais la plupart des services proxy comme NGINX ajoutent X-Forwarded-For
des en-têtes de type à la requête. Ces en-têtes informeront le serveur d’origine de l’adresse IP réelle du client.
A quoi servent les proxys inverses ?
Les proxys inverses sont assez simples dans leur concept mais se sont avérés être un outil étonnamment utile avec de nombreux cas d’utilisation inattendus.
L’équilibrage de charge
L’un des principaux avantages d’un reverse proxy est sa légèreté. Parce qu’ils ne font que transmettre les requêtes, ils n’ont pas besoin d’effectuer beaucoup de traitement, en particulier dans les situations où une requête de base de données doit être exécuté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, un proxy peut envoyer 50 % des requêtes à un serveur et 50 % à un autre, doublant ainsi la bande passante d’un site Web. Des services comme HAProxy sont bons dans ce domaine.
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 faire évoluer automatiquement le nombre de serveurs sources en fonction du trafic, une fonctionnalité appelée « autoscaling ».
Les équilibreurs de charge comme Elastic Load Balancer d’AWS peuvent être configurés pour se reconfigurer automatiquement lorsque vos serveurs sources tombent en panne, le tout rendu possible par un proxy inverse sous le capot.
mise en cache
Étant donné que le 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 partagées. La mise en cache se produit lorsque les données de la page sont stockées sur un serveur 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 charge sur le serveur source.
Par exemple, cet article que vous lisez actuellement a été fourni par WordPress, qui doit accéder à une base de données SQL pour obtenir 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 réellement. De cette façon, cette route peut être mise en cache et le proxy inverse enverra simplement la dernière réponse à l’utilisateur suivant au lieu de déranger à nouveau WordPress.
Un réseau dédié de serveurs proxy 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 un grand nombre d’entre eux peuvent rendre votre site très rapide.
Sécurité et confidentialité du réseau
Parce que l’utilisateur ne sait pas ce qui se cache derrière le proxy inverse, il ne pourra pas facilement attaquer directement les serveurs d’origine. En fait, les proxys inverses sont généralement utilisés avec des serveurs d’origine sur des 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 fiable, 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 interagit avec une base de données est comme un proxy inverse. La base de données sait qu’elle peut faire confiance au serveur d’API sur le sous-réseau privé, et le serveur d’API agit comme un pare-feu pour la base de données, n’autorisant que les connexions valides via celui-ci.
Interface personnalisable
L’un des avantages des proxys inverses comme NGINX est qu’ils sont faciles à configurer. Il est souvent utile de les placer devant d’autres services uniquement pour configurer l’accès des utilisateurs à ces services.
Par exemple, NGINX peut restreindre les requêtes à certaines routes, ce qui peut empêcher les attaquants 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 une bonne chose.
NGINX peut également rediriger le trafic de plusieurs noms de domaine à l’aide de blocs « serveur » personnalisés. Par exemple, il peut envoyer des demandes à example.com
votre serveur d’origine, mais les envoyer api.example.com
à votre serveur d’API personnalisé ou files.example.com
à votre stockage de fichiers, etc. Chaque serveur peut avoir sa propre configuration et ses propres règles.
NGINX peut également ajouter des fonctionnalités supplémentaires aux serveurs d’origine existants, telles que les certificats HTTPS centralisés et la configuration des en-têtes.
Parfois, il est utile d’avoir simplement NGINX sur la même machine qu’un autre service local, juste pour servir le contenu de ce service. Par exemple, les API Web ASP.NET utilisent un serveur Web interne appelé Kestrel, qui est bien réactif, mais pas plus que cela. Il est très courant d’exécuter Kestrel sur un port privé et d’utiliser NGINX comme proxy inverse personnalisé.
Journalisation centralisée
C’est assez simple, mais la plupart de votre trafic passe par un seul service, ce qui facilite la vérification des journaux. Le journal d’accès NGINX contient de nombreuses informations utiles sur votre trafic, et bien qu’il ne surpasse pas les services comme Google Analytics, il s’agit d’informations utiles.
Laisser un commentaire