Squid3 – Installation d'un serveur Squid en tant que reverse-proxy – Installation



Squid3 – Installation d'un serveur Squid en tant que reverse-proxy – Installation

0 0


installation-squid3-docker


On Github pierrehts / installation-squid3-docker

Squid3

Installation basique en tant que reverse-proxy

Par Pierre HOSTEINS et Benoit GRAND

Fonctionnement

Schéma spécifique à notre infrastructure

L'utilisateur envoie une requête au serveur Squid3. Le serveur Squid3 (reverse-proxy) renvoie la requête au serveur distant. Le serveur distant réponds au serveur Squid3. Le serveur Squid3 (reverse-proxy) retourne la réponse à l'utilisateur.

Pourquoi ?

Le serveur Squid3 agit ici comme une passerelle.

En tant que point d'entrée vers le serveur distant, il permet donc une gestion avancée du cache ainsi que la mise en place d'éléments de sécurité.

Installation

Utilisation de docker pour simuler un reverse-proxy Squid détaché de notre machine locale.

Images cliquable + suite slide du bas

Docker

Mise en place d'un container docker sous Debian8 qui nous servira de base pour installer le serveur Squid.

~# docker pull debian
~# sudo docker run -i -t debian /bin/bash

Ces deux commandes permettront le téléchargement d'une image debian ainsi que le lancement de celle-ci.

Squid3

Premièrement, on installe Squid3.

~# sudo apt-get install squid3
~# service squid3 start

Le serveur Squid est maintenant bien lancé, le plus important reste sa configuration.

Configuration de Squid3

acl localnet src 172.16.0.0/12  # Ici on veut autorisé la plage d'ip par défaut utilisée par le networking Docker
http_access allow localnet # On autorise donc l'accès en HTTP aux ips faisant partie de ce réseau.

http_port 80 accel defaultsite=rest-bookmarks.herokuapp.com # Cette ligne permet au serveur squid d'écouter sur le port 80 et d'agir en tant qu'accelerateur http pour le site déterminé.
cache_peer rest-bookmarks.herokuapp.com parent 80 0 no-query no-digest # Cette ligne permet de configurer le serveur rest-bookmarks.herokuapp.com en tant que cache parent et sera donc le site en cache dans le cadre d'un reverse proxy.
cache_mem 1024 MB # Cette ligne définit le taille maximale du cache
cache_dir aufs /var/spool/squid3 81920 16 256 # Cette ligne définit l'emplacement du cache
maximum_object_size 5120 MB # Cette ligne définit la taille maximale d'un objet du cache
cache_store_log /var/log/squid3/store.log # Emplacement du fichier log lié au cache

coredump_dir /var/spool/squid3
refresh_pattern ^http: 600000 100% 700000 override-expire override-lastmod reload-into-ims ignore-reload ignore-no-cache ignore-private ignore-auth

Il est ici très important de mettre en place des refresh_pattern en fonction de l'utilité du reverse-proxy. Ici nous avons utilisé un pattern de test qui mettra en cache définitif la totalité des éléments reçus en http. C'est donc un pattern a ne pas utiliser en version de production.

Preuve de fonctionnement

172.17.42.1 est la machine locale, 172.17.0.6 est le serveur squid, 50.17.242.145 est le serveur herokuapp, rest-bookmarks.io est un ndd pointant vers le serveur squid définit dans le fichier /etc/hosts de la machine locale.

On remarque ici deux appels GET sur la racine de rest-bookmarks.io.

Le 1er appel n'étant pas caché génère bien un appel du reverse-proxy vers le serveur distant (packet 22 et 32).

Cependant, le 2ème appel fonctionne différemment ! Le cache étant bien effectif, on remarque que le reverse-proxy réponds cette fois directement (packet 49 et 51).

Squid3 Installation basique en tant que reverse-proxy Par Pierre HOSTEINS et Benoit GRAND