Des reverses proxy, pour vous simplifier la vie ! - suite et fin

, par  Doo , popularité : 2%

Après HAProxy, NGINX

Après cette première partie, on a maintenant connaissance des notions de proxy et de reverse proxy. Il reste maintenant à parler d’un acteur non négligeable dans le monde des internetz : NGINX.

Son auteur, Igor Sysoev , est issu de l’URSS et de l’Université Technique Moscovite. NGINX a d’abord été créé pour répondre aux besoins de l’un des sites à plus fort trafic de Russie, puis s’est propagé rapidement sur le web russophone. Aujourd’hui, il se propage à grande vitesse dans le reste du monde :

HTML - 105.2 kio

Il présente l’avantage, par rapport à Apache 2.2, d’être très light et de tolérer de très forts trafic. Il sert également des objectifs de répartition de charge, de reverse proxy, et j’en passe.

NGINX en tant que reverse proxy

Le cas le plus "pratique" d’utilisation de Nginx en tant que reverse proxy est de faire de l’offloading (déchargement) SSL.

Généralement, NGINX tourne à côté d’un serveur HAProxy qui va en suite se charger de répartir le trafic "offloadé", mais peu importe. Dans le cas du offloading, on se sert de NGINX pour présenter le certificat et chiffrer la connexion établie avec le client ; puis on part du principe que le réseau se situant entre le proxy et le service web est sécurisé, on peut donc transmettre en clair :

HTML - 199 octets

On peut ainsi présenter un grand nombre de frontaux webs pour un même trafic chiffré, on peut également conserver les sessions SSL de manière à moins charger le service de chiffrement, ou au contraire augmenter le niveau de sécurisation des sessions en les détruisant plus rapidement. Dans ce cas, la configuration d’un vhost se fera de la manière suivante :

upstream haproxy

server localhost:81 ;

server

listen 443 ;

server_name foo.com ;

ssl on ;

ssl_certificate ssl/foo.crt ;

ssl_certificate_key ssl/foo.key ;

ssl_session_cache shared:SSL:10m ;

ssl_session_timeout 5m ;

ssl_protocols SSLv2 SSLv3 TLSv1 ;

ssl_ciphers RC4+RSA :+HIGH :+MEDIUM :+LOW :+SSLv2 :+EXP ;

ssl_prefer_server_ciphers on ;

location /

proxy_pass http://haproxy ;

proxy_set_header Host $server_name ;

proxy_set_header X-Forwarded-For $remote_addr ;

proxy_set_header X-Forwarded-Proto $scheme ;

proxy_set_header X-NginX-Proxy true ;

et côté HAProxy :

frontend https-in

bind *:81

default_backend foo

option forwardfor except 127.0.0.1

option httpclose

acl racine hdr_end(host) -i foo.com -i www.foo.com

use_backend sfoo if racine

Et on récupère ensuite ça sur un backend normal, comme vu dans le premier article !

Ce qui est à noter ici, c’est que l’on a une première partie de configuration NGINX où l’on décrit un serveur HTTPS, ce dernier renvoie vers un proxy en HTTP. NGINX applique donc automatiquement un offloading pour faire la transition entre les deux méthodes de communication. On arrive en HTTPS :

server

listen 443 ;

server_name foo.com ;

ssl on ;et on repart en HTTP :

location /

proxy_pass http://haproxy ;

On peut également vouloir se contenter de relayer du trafic SSL d’un serveur à un autre :

HTML - 199 octets

Dans ce cas, la configuration se présentera de cette façon :

server

listen 443 ;

server_name foo.com ;

gzip on ;

gzip_http_version 1.0 ;

gzip_comp_level 5 ;

gzip_min_length 512 ;

gzip_buffers 4 8k ;

gzip_proxied any ;

gzip_types

text/css

text/plain

text/x-component

application/javascript

application/json

application/xml

application/xhtml+xml

application/x-font-ttf

application/x-font-opentype

application/vnd.ms-fontobject

image/svg+xml

image/x-icon ;

access_log /var/log/vhost.access.log ;

error_log /var/log/vhost.nginx_error.log debug ;

location /

proxy_pass https://bar.com:8080/ ;

error_page 500 502 503 504 /50x.html ;

location = /50x.html

root /var/www/nginx-default ;

La partie intéressante se trouve ici : listen 443 ;

server_name foo.com ;

et ici :

location /

proxy_pass https://bar.com:8080/ ;

Cela signifiera que l’on passe en https au travers de l’URL foo.com pour joindre le serveur bar.com sur le port 8080, toujours en HTTPS. Le certificat présenté sera, bien entendu, celui de bar.com.

Voilà voilà, quand Apache2.4 sera vraiment répandu et que j’aurais un peu plus d’expérience dessus, cela vaudra bien un article pour compléter !

Pour aller plus loin :

http://nginx.com/blog/nginx-ssl/ http://fr.slideshare.net/jimjag/apache-httpd-24-reverse-proxy http://blog.héry.com/article9/configurer-un-reverse-proxy-apache-http-https

Voir en ligne : http://dooby.fr/index.php?article4/...

Sites favoris Tous les sites

84 sites référencés dans ce secteur