Nous aborderons ici le sujet des serveurs mandataires inverses, plus communément reverse proxies, et parfois surrogates. Notre propos ne sera pas technique, mais conceptuel, et permettra idéalement de parcourir la typologie des serveurs existants, et d’en découvrir progressivement les rôles, les bénéfices et les contraintes, de préférence au travers d’exemples concrets.
Nous supposerons toutefois une familiarité pratique du lecteur avec les technologies Web.
Puisque la découverte procède le plus souvent par questionnement, posons immédiatement la première question : qu’est-ce qu’un reverse proxy ?
Non.
Pardon !?
Non, ça c’est la deuxième question. La première est : pourquoi parler des reverse proxies ?
Pourquoi un reverse proxy ?
Les architectures de service typées Web, de la boutique dématérialisée au processus interne en SoA, posent un ensemble classique de contraintes d’exploitation, en ordre et importance variant selon le cas :
– Assurer la continuité/disponibilité du service
– Réduire la latence de réponse du service
– Maitriser le cout de ressources de l’activité.
L’intégration d’un reverse proxy peut apporter des améliorations très significatives sur ces trois plans.
D’un point de vue production, il présente l’avantage considérable de pouvoir être intégré a posteriori sur une plateforme existante ; dans de nombreux cas, il n’est pas nécessaire que la possibilité ait été prévue initialement, et la mise en place peut être gérée sans appel au développeur original de la solution.
D’un point de vue développement, il est toutefois plus efficace de prévoir l’implantation de mandataires dans l’architecture de solution. Cela implique une réflexion, notamment sur la nature des données traitées et la gestion de la concurrence, qui trouve tout naturellement sa place dans la définition de la solution logicielle.
Alors, satisfait ?
Peut-être. Le sujet mérite d’être lu en diagonale …
Et donc ?
Et donc, il est temps maintenant : qu’est-ce qu’un reverse proxy ?
Qu’est-ce qu’un reverse proxy ?
L’explication la plus simple commence probablement par la description de ce qu’est un proxy server, ou serveur mandataire.
Il s’agit en fait d’un qualificatif de rôle assez général : un serveur mandataire va accepter des requêtes d’un ensemble de clients, les réémettre en son nom vers la ressource désirée, et à l’inverse transmettre la réponse de cette ressource au client original.
Bien que ce rôle soit implémenté de manières multiples pour de nombreux protocoles, l’exemple le plus commun est LE proxy, le serveur mandataire Web, cette chose à mettre dans la configuration du navigateur pour accéder à Internet dans la plupart des entreprises, et qui régulièrement bloque des pages parce qu’un mot ne lui a pas plu.
On parle de proxy tout court (ou forward proxy si on veut insister sur la distinction) lorsque les requêtes proviennent du réseau interne, et que les ressources sont dans le reste du monde.
On parle donc de reverse proxy, ou mandataire inverse, lorsque les requêtes viennent du monde, et ciblent quelques serveurs du réseau interne.
S’ajoutent à cette description de nombreuses fonctionnalités, qui permettent des usages variés et créatifs, que nous tenterons de survoler progressivement.
Le schéma le plus simple sera donc :
client ——1——–> reverse ——-2——-> serveur
externe <——4——— proxy <——3——– interne
Bien le dessin en mode texte …
J’ai dit le schéma le plus simple !
Mais ce truc n’est qu’un intermédiaire, il coute une machine et il ne sert à rien !
Oui et non. La plupart des proxies ont une valeur ajoutée au-delà de leur rôle de base ; le proxy Web en entreprise, et en fait un mandataire cache filtrant. Mais même dans cette configuration simple, le mandataire inverse peut avoir un rôle important. Il faut le voir comme un facilitateur plus qu’un intermédiaire, si on veut conserver le vocabulaire économique …
Gestion de l’accessibilité
Le motif le plus simple présente déjà une utilité : permettre l’accès depuis le monde à un serveur interne. Ce dernier n’a pas vocation à être déplacé en DMZ, et ne peut donc pas être directement visible.
Le serveur proxy dans ce cas peut être un simple serveur Web : quasiment tous les serveurs actuels (Apache, IIS, Tomcat, nginx, …) proposent une fonctionnalité de ‘sous-traitance’ conditionnelle : sous certaines conditions, le serveur Web ne répond pas lui-même, mais transmet la requête à une autre machine, et renvoie cette réponse. De fait, le nom de la fonctionnalité en question ressemble souvent à ‘proxy pass’.
Ça ressemble à la délégation en programmation objet, en fait.
Cette configuration survient dans la pratique. Par exemple lorsque que l’extranet d’une société est en fait porté par le serveur de l’intranet, avec une adaptation dynamique de certain contenus suivant la zone de requête ; ce serveur n’est souvent pas monté pour entrer en DMZ, et pose des problèmes de traversée de zones si, classiquement, il s’appuie sur un Active Directory. Bref, il reste interne, et on expose son service par proxy.
Une variante de ce cas de figure se trouve dans les bonnes pratiques Microsoft concernant SharePoint Server : il est préconisé par l’éditeur de ne pas exposer le SharePoint lui-même à l’extérieur, mais de passer par un Forefront Unified Access Gateway, autre produit de la marque, qui est un reverse proxy (extrêmement élaboré). Dans ce cas particulier, on utilisera l’UAG pour toutes les fonctions décrites plus bas, et bien d’autres encore.
Oui, enfin il n’y a pas besoin de sortir des mots compliqués et des serveurs en plus. Un petit NAT sur le firewall, et hop, le service et visible sans exposer la machine. Et j’ai du filtrage en supplément.
Discutablement. D’abord, c’est sale. Ensuite, le pare-feu classique agit naturellement sur les couches basses (avec des incursions au niveau applicatif), les proxies sont beaucoup plus riches à la couche applicatives. Les deux se complètent bien, en fait.
Dans le cas le plus simple de cette configuration (ie : utilisation d’un serveur HTTP en tant que reverse proxy), il devient possible de faire appel aux autres fonctionnalités du serveur HTTP afin d’enrichir son rôle.
Par exemple, tous les serveurs Web sont capables de réécriture d’URL ; ceci peut servir à encapsuler les fonctionnalités du serveur interne.
En cas d’application : le serveur interne appartient à une entité distincte, qui ne souhaite pas y apporter de modification. La translation d’URL, impossible à gérer sur le serveur de destination pour raisons non techniques, trouve naturellement sa place sur un reverse proxy. Dans la pratique, il n’a pas été utile de monter un serveur dédié à ce rôle, le serveur Web principal assumait le rôle de proxy avec réécriture sans soucis.
De même, un simple serveur Web est capable d’assurer un filtrage très fin ; même si la sécurité périphérique reste évidemment à la charge du pare-feu, d’éventuelles restrictions sur URL, paramètres de requêtes, … s’implémente plus facilement sur le reverse proxy. Cela permet aussi de limiter la pollution de règles sur le pare-feu, point non négligeable.
Ce reverse proxy simpliste est aussi capable de supporter des stratégies d’authentification complexes, basées sur des listes de contrôle d’accès (ACL), et/ou l’annuaire d’entreprise (notablement, Active Directory).
Ceci permet de centraliser les besoins d’authentification, et éventuellement de palier à l’insuffisance technique d’un serveur interne vétuste.
Holà, c’est pas un peu tiré par les cheveux, centraliser les besoins d’un seul serveur interne ?
Bah oui, mais ça me fournissait une transition vers la possibilité d’extension fonctionnelle via le serveur mandataire ; et aussi de glisser discrètement qu’il pouvait y avoir plus d’un serveur interne derrière le proxy …
Ceci dit, les cas de mandataires complexes ne masquant qu’un seul serveur peuvent exister : typiquement, une grappe de basculement (failover cluster) n’expose qu’un seul serveur (virtuel) au proxy frontal. Les solutions Microsoft complexes incluent souvent des mandataires inverses fonctionnellement riches, ce qui est une bonne chose à beaucoup d’égards.
Tiens, nous parlerons vers la fin des produits de type Bee Ware : nous reviendrons au schéma simple, mais dans une application complexe, et ça me permettra une jolie épanadiplose narrative.
C’est pas plutôt une anadiplose ?
C’est pas faux.
C’est quoi le mot que .., enfin, c’est quoi cette idée d’étendre les fonctionnalités de la solution avec un proxy ?
Extension de fonctionnalités
Ce besoin se rencontre le plus souvent dans des situations transitionnelles : la solution existante est vieille, son remplacement n’est pas envisagé à court terme, mais il faut l’intégrer au SSO de l’entreprise.
Un mandataire inverse assurant l’authentification et une réécriture d’URL peut suffire à une intégration à peu de frais, en attendant une solution définitive.
Le besoin d’extension de fonctionnalité n’implique pas nécessairement la vétusté des solutions déployées. Varnish est un reverse proxy cache ESI-capable (nous y reviendrons plus tard), totalement actuel et très intéressant (c’est bien pour cela que nous y reviendrons).
Ceci dit, son auteur à fait le choix de ne pas intégrer de support SSL. Donc, pas de HTTPS avec Varnish, ce qui est dommage tout de même.
La solution simple est donc de poser un reverse proxy en charge du chiffrement SSL, en frontal du reverse proxy Varnish, lui-même frontal du serveur Web ‘final’ (qui peut lui aussi être un reverse proxy, implémentant une fonctionnalité de grappe, mais nous y viendrons).
C’est simple ça ?
Oui, il y a facilement pire. Mais ça n’est pas un concours, il faut quand même réfléchir avant d’empiler les couches.
Autre situation, la solution envisagée impliquait du code en PHP et du Java. Cela arrive, et passé la réaction initiale, n’est pas dénué d’intérêt. Tomcat couvre le besoin fonctionnel : il est capable de servir du HTTP(S), des JSP, et d’interpréter du PHP via un module additionnel.
Dans notre exemple spécifique, l’applicatif n’était malheureusement pas RESTful, mais la persistance d’état était assurée par une ressource mutualisée indépendante du serveur Web ; en clair, la base de données.
Il était alors possible et intéressant de poser frontalement un couple nginx + PHP-FPM, capable de moudre très efficacement le PHP, et sous-traiter les JSP au Tomcat. nginx comportait donc en reverse proxy partiel, et toujours dans le schéma simpliste évoqué plus haut.
Dans la pratique, nginx et Tomcat peuvent parfaitement partager le même serveur physique, si la charge et les performances le permettent.
Et là, j’ai ma transition : les serveurs mandataires offrent de nombreuses possibilités pour gérer la charge.
Ah oui, on m’a dit, il faut toujours mettre un serveur Apache devant un serveur Tomcat, ce dernier est trop lent et pas assez sûr !
C’était vrai, mais bon, cela fait longtemps que Tomcat-native fait jeu égal avec Apache httpd sur les performances ; la sécurité aussi a beaucoup progressé. Je pensais plus à nginx, ou à des exemples de SSL ..
Bon, dans quelques jours, la suite avec le chapitre 2 : la performance !
