On entend souvent parler de proxy dans les médias, tout le monde sait à peu près à quoi ça correspond en gros. Mais lorsqu’on parle de reverse proxy, on touche un public moins large, alors que le concept ne change pas.

Comprendre le proxy, comprendre le reverse

À l’accoutumée, tout un chacun accède à un site lambda comme ceci :

On cherche à accéder à l’adresse bar.net/forum, le DNS résout le nom pour trouver une adresse IP correspondante, on accède.

Lorsqu’on utilise un proxy, on transite en premier lieu par un serveur relai, qui va permettre de masquer l’adresse IP de la machine source, pour la "remplacer" par la sienne. On peut ainsi profiter de services de streaming encore indisponibles en France, profiter d’un accès à YouTube digne d’une vraie connexion Internet 20Mbps, entre autres.

A l’époque où l’accès Internet était lent ou dans des contextes où l’on cherche à contrôler ce que l’utilisateur consulte comme information, on utilisait un système de proxy filtrant ou proxy caching, un peu comme le cache de votre navigateur mais à l’échelle de plusieurs utilisateurs, ce qui consistait tout simplement à disposer d’une partie des ressources les plus couramment accédées de manière locale, sans avoir à le télécharger à nouveau sur le serveur cible à chaque accès ou de pouvoir en filtrer l’accès. On a donc vu l’émergence de produits comme Squid, qui offre ce genre de service "d’Optimisation de livraison du contenu Web" si l’on traduit le slogan littéralement. On peut également faire ce genre de chose avec SSH de manière très triviale, ou de manière plus avancée. On peut donc trouver tout un tas d’intérêts dans l’utilisation d’un serveur proxy.

Le reverse proxy

Dans le cas du reverse, c’est le même concept, mais à l’inverse !

On va donc permettre à des serveurs hébergeant du contenu de masquer leur IP derrière un proxy, qui leur permettra de délivrer du contenu de manière transparente pour l’utilisateur. À priori, des serveurs web ont globalement peu d’intérêt à masquer leur adresse IP puisqu’on y accède via un navigateur, il ne s’agit donc pas d’une mesure de sécurisation ...

Eh bien, non. En gros, un accès à un reverse proxy se présente à peu près comme ceci :

On peut penser que ça correspond à la mise en place de VirtualHosts, l’aspect utilisateur est d’ailleurs très similaire : on ne voit rien.

Côté sécurité, le proxy va apporter un niveau plus satisfaisant de sécurisation qu’une application exposée directement aux accès web. Cela permettra également de masquer une partie des vulnérabilités du serveur de contenu, comme la propension d’Apache à subir les attaques Slowloris. Côté répartition de charge, on aura la possibilité de mettre plusieurs serveurs derrière un reverse proxy pour servir un contenu identique. Cette fonction de répartition de charge peut également être agrémentée d’une fonctionnalité de tolérance de panne, dans la mesure où il est possible dans beaucoup de reverse proxies d’ajouter une fonctionnalité de détection du serveur web frontal, souvent au travers de requêtes HTTP ou TCP recevant un code retour positif.

On connait historiquement la fonctionnalité reverse proxy du vénérable Apache qui reprendra certainement du poil de la bête dans les grosses infrastructure une fois sa version 2.4 largement déployée, cela va demander pas mal de tests pour départager les principaux concurrents de ce monde. Pour le moment, Apache en tant que serveur de contenu a tendance à s’essouffler au bout d’un certain moment lorsqu’il est trop sollicité. En tant que reverse proxy, il n’a pas encore suffisamment de fonctionnalités pour devenir complètement "scalable" et performant comme le sont ses deux principaux concurrents dans ce domaine, j’ai nommé HAProxy et NGINX.

HAProxy

On parle ici d’un logiciel très utilisé dans des sites à fort trafic comme Twitter, Reddit, Tumblr, StackOverflow, et tellement d’autres que cela serait une perte de temps de tous les énumérer. HAProxy a été codé en C par Willy TARREAU, en 2000 (ça commence à dater un peu) dans sa première version. Depuis cette époque, il n’a été levé qu’une seule faille de sécurité pour ce reverse proxy, et celle ci n’a duré que 2 semaines en 2002. En parcourant rapidement la documentation très complète de la bête, on se rendra rapidement compte que l’un des seuls défauts de ce reverse, c’est de ne pas faire le café. Personnellement, je m’en sers principalement pour gérer l’utilisation du port 80 et d’autres ports exotiques. A titre professionnel en revanche, on se rend compte que l’utiliser permet de se passer, dans beaucoup de cas, de solution matérielles souvent hors de prix. En gros, a configuration "basique" est la suivante :

global

log 127.0.0.1 local1 notice

chroot /var/lib/haproxy

daemon

defaults

log global

mode http

option httplog

option dontlognull

contimeout 5000

clitimeout 50000

srvtimeout 50000

errorfile 400 /etc/haproxy/errors/400.http

errorfile 403 /etc/haproxy/errors/403.http

errorfile 408 /etc/haproxy/errors/408.http

errorfile 500 /etc/haproxy/errors/500.http

errorfile 502 /etc/haproxy/errors/502.http

errorfile 503 /etc/haproxy/errors/503.http

errorfile 504 /etc/haproxy/errors/504.http

option forwardfor

option http-server-close

hash-type consistent

listen stats localhost:1936

mode http

stats enable

stats hide-version

stats realm Haproxy\ Statistics

stats uri /haproxy-status

stats auth username:mon$up3r/passSecur3

Ici, on a une description du fonctionnement général, et du comportement par défaut. On pourra disposer de statistiques concernant la disponbilité des frontaux web, du trafic, bref un peu de tout :-)

On passe ensuite au cœur du fonctionnement de HAProxy :

frontend web

option forwardfor except 127.0.0.1

bind 0.0.0.0:80

On met donc en place un frontal qui va écouter sur la route par défaut du serveur, et ajouter un en tête X-Forwarded-For aux trames HTTP qui passent par le port 80. On trouve, à la suite du frontend, les ACL à appliquer sur ce frontend :

acl dooby_fr hdr(host) -i dooby.fr

L’ACL intitulée dooby_fr précise que les sites présentant le header HOST contenant la chaine "dooby.fr" sans tenir compte de la casse (majuscules, minuscules) utilisera le backend (serveur web) :

use_backend dooby if dooby_fr

Et ensuite, dans la description du backend (le serveur web, donc) :

backend dooby

server dooby localhost:8088

cookie SERVERID insert indirect nocache

option redispatch

Où l’on précise l’adresse du serveur, le port, les diverses options propre au serveur. Tout ceci est bien sûr très bien documenté.

Bref, que du bonheur !

A suivre, la présentation des fonctionnalités de reverse proxy de NGINX.