2892 lines
129 KiB
Plaintext
2892 lines
129 KiB
Plaintext
-------------------
|
|
HAProxy
|
|
Manuel de référence
|
|
-------------------
|
|
version 1.3.2
|
|
willy tarreau
|
|
2006/09/03
|
|
|
|
|
|
!!!! NOTE: CE DOCUMENT EST PERIME !!!!
|
|
|
|
Veuillez utiliser le fichier "configuration.txt" situé dans le même
|
|
répertoire, ou télécharger une version à jour à l'emplacement ci-dessous :
|
|
|
|
http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
|
|
|
|
|
|
================
|
|
| Introduction |
|
|
================
|
|
|
|
HAProxy est un relais TCP/HTTP offrant des facilités d'intégration en
|
|
environnement hautement disponible. En effet, il est capable de :
|
|
- effectuer un aiguillage statique défini par des cookies ;
|
|
- effectuer une répartition de charge avec création de cookies pour assurer
|
|
la persistence de session ;
|
|
- fournir une visibilité externe de son état de santé ;
|
|
- s'arrêter en douceur sans perte brutale de service ;
|
|
- modifier/ajouter/supprimer des en-têtes dans la requête et la réponse ;
|
|
- interdire des requêtes qui vérifient certaines conditions ;
|
|
- utiliser des serveurs de secours lorsque les serveurs principaux sont hors
|
|
d'usage.
|
|
- maintenir des clients sur le bon serveur serveur d'application en fonction
|
|
de cookies applicatifs.
|
|
- fournir des rapports d'état en HTML à des utilisateurs authentifiés, à
|
|
travers des URI de l'application interceptées.
|
|
|
|
Il requiert peu de ressources, et son architecture événementielle mono-
|
|
processus lui permet facilement de gérer plusieurs milliers de connexions
|
|
simultanées sur plusieurs relais sans effondrer le système.
|
|
|
|
|
|
===========================
|
|
| Paramètres de lancement |
|
|
===========================
|
|
|
|
Les options de lancement sont peu nombreuses :
|
|
|
|
-f <fichier de configuration>
|
|
-n <nombre maximal total de connexions simultanées>
|
|
= 'maxconn' dans la section 'global'
|
|
-N <nombre maximal de connexions simultanées par instance>
|
|
= 'maxconn' dans les sections 'listen' ou 'default'
|
|
-d active le mode debug
|
|
-D passe en daemon
|
|
-Ds passe en daemon systemd
|
|
-q désactive l'affichage de messages sur la sortie standard.
|
|
-V affiche les messages sur la sortie standard, même si -q ou 'quiet' sont
|
|
spécifiés.
|
|
-c vérifie le fichier de configuration puis quitte avec un code de retour 0
|
|
si aucune erreur n'a été trouvée, ou 1 si une erreur de syntaxe a été
|
|
détectée.
|
|
-p <fichier> indique au processus père qu'il doit écrire les PIDs de ses
|
|
fils dans ce fichier en mode démon.
|
|
-sf specifie une liste de PIDs auxquels envoyer un signal FINISH
|
|
-st specifie une liste de PIDs auxquels envoyer un signal TERMINATE
|
|
-s affiche les statistiques (si option compilée)
|
|
-l ajoute des informations aux statistiques
|
|
-dk désactive l'utilisation de kqueue()
|
|
-ds désactive l'utilisation de epoll() speculatif
|
|
-de désactive l'utilisation de epoll()
|
|
-dp désactive l'utilisation de poll()
|
|
-db désactive la mise en arrière-plan (utile pour débugger)
|
|
-m <megs> applique une limitation de <megs> Mo d'utilisation mémoire
|
|
|
|
Le nombre maximal de connexion simultanées par proxy est le paramètre par
|
|
défaut pour les proxies pour lesquels ce paramètre n'est pas précisé dans le
|
|
fichier de configuration. Il s'agit du paramètre 'maxconn' dans les sections
|
|
'listen'.
|
|
|
|
Le nombre maximal total de connexions simultanées limite le nombre de
|
|
connexions TCP utilisables à un instant donné par le processus, tous proxies
|
|
confondus. Ce paramètre remplace le paramètre 'maxconn' de la section 'global'.
|
|
|
|
Le mode debug correspond à l'option 'debug' de la section 'global'. Dans ce
|
|
mode, toutes les connexions, déconnexions, et tous les échanges d'en-têtes HTTP
|
|
sont affichés.
|
|
|
|
Pour debugger, l'option '-db' est très pratique car elle désactive
|
|
temporairement le mode daemon et le mode multi-processus. Le service peut alors
|
|
être arrêté par un simple appui sur Ctrl-C, sans avoir à modifier la
|
|
configuration ni à activer le mode debug complet.
|
|
|
|
Les statistiques ne sont disponibles que si le programme a été compilé avec
|
|
l'option "STATTIME". Il s'agit principalement de données brutes n'ayant
|
|
d'utilité que lors de benchmarks par exemple, et sont amenées à disparaitre.
|
|
|
|
Les paramètres '-st' et '-sf' sont utilisés pour la reconfiguration à chaud.
|
|
Voir la section à ce sujet.
|
|
|
|
============================
|
|
| Fichier de configuration |
|
|
============================
|
|
|
|
Structure
|
|
=========
|
|
|
|
L'analyseur du fichier de configuration ignore des lignes vides, les espaces,
|
|
les tabulations, et tout ce qui est compris entre le symbole '#' (s'il n'est
|
|
pas précédé d'un '\'), et la fin de la ligne, ce qui constitue un commentaire.
|
|
|
|
Le fichier de configuration est découpé en sections répérées par des mots clés
|
|
tels que :
|
|
|
|
- 'global'
|
|
- 'listen'
|
|
- 'defaults'
|
|
|
|
Tous les paramètres font référence à la section définie par le dernier mot clé
|
|
reconnu.
|
|
|
|
|
|
1) Paramètres globaux
|
|
=====================
|
|
|
|
Il s'agit des paramètres agissant sur le processus, ou bien sur l'ensemble des
|
|
proxies. Ils sont tous spécifiés dans la section 'global'. Les paramètres
|
|
supportés sont :
|
|
|
|
- log <adresse> <catégorie> [niveau_max]
|
|
- maxconn <nombre>
|
|
- uid <identifiant>
|
|
- gid <identifiant>
|
|
- user <nom d'utilisateur>
|
|
- group <nom de groupe>
|
|
- chroot <répertoire>
|
|
- nbproc <nombre>
|
|
- daemon
|
|
- debug
|
|
- nokqueue
|
|
- noepoll
|
|
- nopoll
|
|
- quiet
|
|
- pidfile <fichier>
|
|
- ulimit-n <nombre>
|
|
- tune.maxpollevents <nombre>
|
|
|
|
|
|
1.1) Journalisation des événements
|
|
----------------------------------
|
|
La plupart des événements sont journalisés : démarrages, arrêts, disparition et
|
|
apparition de serveurs, connexions, erreurs. Tous les messages sont envoyés en
|
|
syslog vers un ou deux serveurs. La syntaxe est la suivante :
|
|
|
|
log <adresse_ip> <catégorie> [niveau_max]
|
|
|
|
Les connexions sont envoyées en niveau "info". Les démarrages de service et de
|
|
serveurs seront envoyés en "notice", les signaux d'arrêts en "warning" et les
|
|
arrêts définitifs de services et de serveurs en "alert". Ceci est valable aussi
|
|
bien pour les proxies que pour les serveurs testés par les proxies. Le
|
|
paramètre optionnel <niveau_max> définit le niveau maximal de traces émises
|
|
parmi les 8 valeurs suivantes :
|
|
emerg, alert, crit, err, warning, notice, info, debug
|
|
|
|
Par compatibilité avec les versions 1.1.16 et antérieures, la valeur par défaut
|
|
est "debug" si l'option n'est pas précisée.
|
|
|
|
Les catégories possibles sont :
|
|
kern, user, mail, daemon, auth, syslog, lpr, news,
|
|
uucp, cron, auth2, ftp, ntp, audit, alert, cron2,
|
|
local0, local1, local2, local3, local4, local5, local6, local7
|
|
|
|
Conformément à la RFC3164, les messages émis sont limités à 1024 caractères.
|
|
|
|
Exemple :
|
|
---------
|
|
global
|
|
log 192.168.2.200 local3
|
|
log 127.0.0.1 local4 notice
|
|
|
|
1.2) limitation du nombre de connexions
|
|
---------------------------------------
|
|
Il est possible et conseillé de limiter le nombre global de connexions par
|
|
processus à l'aide du mot clé global 'maxconn'. Les connexions sont comprises
|
|
au sens 'acceptation de connexion', donc il faut s'attendre en règle général à
|
|
avoir un peu plus du double de sessions TCP que le maximum de connexions fixé.
|
|
C'est important pour fixer le paramètre 'ulimit -n' avant de lancer le proxy.
|
|
Pour comptabiliser le nombre de sockets nécessaires, il faut prendre en compte
|
|
ces paramètres :
|
|
|
|
- 1 socket par connexion entrante
|
|
- 1 socket par connexion sortante
|
|
- 1 socket par couple adresse/port d'écoute par proxy
|
|
- 1 socket pour chaque serveur en cours de health-check
|
|
- 1 socket pour les logs (tous serveurs confondus)
|
|
|
|
Dans le cas où chaque proxy n'écoute que sur un couple adresse/port,
|
|
positionner la limite du nombre de descripteurs de fichiers (ulimit -n) à
|
|
(2 * maxconn + nbproxy + nbserveurs + 1). A partir des versions 1.1.32/1.2.6,
|
|
il est possible de spécifier cette limite dans la configuration à l'aide du
|
|
mot-clé global 'ulimit-n', à condition bien entendu que le proxy ait été
|
|
démarré sous le compte root (ou avec des droits suffisants pour élever le
|
|
nombre de descripteurs de fichiers). Cette solution met un terme au problème
|
|
récurrent d'incertitude de l'adéquation entre les limites systèmes lors de la
|
|
dernière relance du proxessus et les limites en nombre de connexions. Noter que
|
|
cette limite s'applique par processus.
|
|
|
|
Exemple :
|
|
---------
|
|
global
|
|
maxconn 32000
|
|
ulimit-n 65536
|
|
|
|
|
|
1.3) Diminution des privilèges
|
|
------------------------------
|
|
Afin de réduire les risques d'attaques dans le cas où une faille non identifiée
|
|
serait exploitée, il est possible de diminuer les privilèges du processus, et
|
|
de l'isoler dans un répertoire sans risque.
|
|
|
|
Dans la section 'global', le paramètre 'uid' permet de spécifier un identifiant
|
|
numérique d'utilisateur. La valeur 0, correspondant normalement au super-
|
|
utilisateur, possède ici une signification particulière car elle indique que
|
|
l'on ne souhaite pas changer cet identifiant et conserver la valeur courante.
|
|
C'est la valeur par défaut. De la même manière, le paramètre 'gid' correspond à
|
|
un identifiant de groupe, et utilise par défaut la valeur 0 pour ne rien
|
|
changer. Dans le cas où il ne serait pas possible de spécifier un identifiant
|
|
numérique pour l'uid, il est possible de spécifier un nom d'utilisateur après
|
|
le mot-clé 'user'. De la même manière, il est possible de préciser un nom de
|
|
groupe après le mot-clé 'group'.
|
|
|
|
Il est particulièrement déconseillé d'utiliser des comptes génériques tels que
|
|
'nobody' car cette pratique revient à utiliser 'root' si d'autres processus
|
|
utilisent les mêmes identifiants.
|
|
|
|
Le paramètre 'chroot' autorise à changer la racine du processus une fois le
|
|
programme lancé, de sorte que ni le processus, ni l'un de ses descendants ne
|
|
puissent remonter de nouveau à la racine. Ce type de cloisonnement (chroot) est
|
|
généralement contournable sur certains OS (Linux, Solaris) pour peu que
|
|
l'attaquant possède des droits 'root' et soit en mesure d'utiliser ou de créer
|
|
un répertoire. Aussi, il est important d'utiliser un répertoire spécifique au
|
|
service pour cet usage, et de ne pas mutualiser un même répertoire pour
|
|
plusieurs services de nature différente. Pour rendre l'isolement plus robuste,
|
|
il est conseillé d'utiliser un répertoire vide, sans aucun droit, et de changer
|
|
l'uid du processus de sorte qu'il ne puisse rien faire dans ledit répertoire.
|
|
|
|
Remarque importante :
|
|
---------------------
|
|
Dans le cas où une telle faille serait mise en évidence, il est fort probable
|
|
que les premières tentatives de son exploitation provoquent un arrêt du
|
|
programme, à cause d'un signal de type 'Segmentation Fault', 'Bus Error' ou
|
|
encore 'Illegal Instruction'. Même s'il est vrai que faire tourner le serveur
|
|
en environnement limité réduit les risques d'intrusion, il est parfois bien
|
|
utile dans ces circonstances de connaître les conditions d'apparition du
|
|
problème, via l'obtention d'un fichier 'core'. La plupart des systèmes, pour
|
|
des raisons de sécurité, désactivent la génération du fichier 'core' après un
|
|
changement d'identifiant pour le processus. Il faudra donc soit lancer le
|
|
processus à partir d'un compte utilisateur aux droits réduits (mais ne pouvant
|
|
pas effectuer le chroot), ou bien le faire en root sans réduction des droits
|
|
(uid 0). Dans ce cas, le fichier se trouvera soit dans le répertoire de
|
|
lancement, soit dans le répertoire spécifié après l'option 'chroot'. Ne pas
|
|
oublier la commande suivante pour autoriser la génération du fichier avant de
|
|
lancer le programme :
|
|
|
|
# ulimit -c unlimited
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
# with uid/gid
|
|
global
|
|
uid 30000
|
|
gid 30000
|
|
chroot /var/chroot/haproxy
|
|
|
|
# with user/group
|
|
global
|
|
user haproxy
|
|
group public
|
|
chroot /var/chroot/haproxy
|
|
|
|
|
|
1.4) Modes de fonctionnement
|
|
----------------------------
|
|
Le service peut fonctionner dans plusieurs modes :
|
|
- avant- / arrière-plan
|
|
- silencieux / normal / debug
|
|
|
|
Le mode par défaut est normal, avant-plan, c'est à dire que le programme ne
|
|
rend pas la main une fois lancé. Il ne faut surtout pas le lancer comme ceci
|
|
dans un script de démarrage du système, sinon le système ne finirait pas son
|
|
initialisation. Il faut le mettre en arrière-plan, de sorte qu'il rende la main
|
|
au processus appelant. C'est ce que fait l'option 'daemon' de la section
|
|
'global', et qui est l'équivalent du paramètre '-D' de la ligne de commande.
|
|
|
|
Le paramètre de ligne de commande '-db' inhibe les options globales 'daemon'
|
|
et 'nbproc' pour faire fonctionner le processus en mode normal, avant-plan.
|
|
|
|
Par ailleurs, certains messages d'alerte sont toujours envoyés sur la sortie
|
|
standard, même en mode 'daemon'. Pour ne plus les voir ailleurs que dans les
|
|
logs, il suffit de passer en mode silencieux par l'ajout de l'option 'quiet'.
|
|
Cette option n'a pas d'équivalent en ligne de commande.
|
|
|
|
Enfin, le mode 'debug' permet de diagnostiquer les origines de certains
|
|
problèmes en affichant les connexions, déconnexions et échanges d'en-têtes HTTP
|
|
entre les clients et les serveurs. Ce mode est incompatible avec les options
|
|
'daemon' et 'quiet' pour des raisons de bon sens.
|
|
|
|
1.5) Accroissement de la capacité de traitement
|
|
-----------------------------------------------
|
|
Sur des machines multi-processeurs, il peut sembler gâché de n'utiliser qu'un
|
|
processeur pour effectuer les tâches de relayage, même si les charges
|
|
nécessaires à saturer un processeur actuel sont bien au-delà des ordres de
|
|
grandeur couramment rencontrés. Cependant, pour des besoins particuliers, le
|
|
programme sait démarrer plusieurs processus se répartissant la charge de
|
|
travail. Ce nombre de processus est spécifié par le paramètre 'nbproc' de la
|
|
section 'global'. Sa valeur par défaut est naturellement 1. Ceci ne fonctionne
|
|
qu'en mode 'daemon'. Un usage déjà rencontré pour ce paramètre fut de dépasser
|
|
la limite de nombre de descripteurs de fichiers allouée par processus sous
|
|
Solaris.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
global
|
|
daemon
|
|
quiet
|
|
nbproc 2
|
|
|
|
1.6) Simplification de la gestion des processus
|
|
-----------------------------------------------
|
|
Haproxy supporte dorénavant la notion de fichiers de pid (-> pidfiles). Si le
|
|
paramètre '-p' de ligne de commande, ou l'option globale 'pidfile' sont suivis
|
|
d'un nom de fichier, alors ce fichier sera supprimé puis recréé et contiendra
|
|
le numéro de PID des processus fils, à raison d'un par ligne (valable
|
|
uniquement en mode démon). Ce fichier n'est PAS relatif au cloisonnement chroot
|
|
afin de rester compatible avec un répertoire protégé en lecture seule. Il
|
|
appartiendra à l'utilisateur ayant lancé le processus, et disposera des droits
|
|
0644.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
global
|
|
daemon
|
|
quiet
|
|
nbproc 2
|
|
pidfile /var/run/haproxy-private.pid
|
|
|
|
# pour stopper seulement ces processus parmi d'autres :
|
|
# kill $(</var/run/haproxy-private.pid)
|
|
|
|
# pour recharger une configuration avec un impact minimal sur le service,
|
|
# et sans casser les sessions existantes :
|
|
# haproxy -f haproxy.cfg -p /var/run/haproxy-private.pid -sf $(</var/run/haproxy-private.pid)
|
|
|
|
1.7) Mécanismes de traitements des événements
|
|
---------------------------------------------
|
|
A partir de la version 1.2.5, haproxy supporte les mécanismes poll() et
|
|
epoll(). Sur les systems où select() est limité par FD_SETSIZE (comme Solaris),
|
|
poll() peut être une alternative intéressante. Des tests de performance
|
|
montrent que les performances de poll() ne décroissent pas aussi vite que le
|
|
nombre de sockets augmente, ce qui en fait une solution sûre pour les fortes
|
|
charges. Cela dit, Soalris utilise déjà poll() pour émuler select(), donc tant
|
|
que le nombre de sockets ne dépasse pas FD_SETSIZE, poll() ne devrait pas
|
|
apporter de performances supplémentaires. Sur les systèmes à base Linux
|
|
incluant le patch epoll() (ou tous les Linux 2.6), haproxy utilisera epoll()
|
|
qui est extrèmement rapide indépendamment du nombre de sockets. Les tests sur
|
|
haproxy ont montré une performance constante de 1 à 40000 sessions simultanées.
|
|
La version 1.3.9 a introduit le support de kqueue() pour FreeBSD/OpenBSD, ainsi
|
|
qu'une variante appelée "speculative epoll()" consistant à tenter d'effectuer
|
|
les opérations d'entrées/sorties avant de chaîner les événements par les appels
|
|
système.
|
|
|
|
Afin d'optimiser la latence, il est désormais possible de limiter le nombre
|
|
d'événements remontés à chaque appel. La limite par défaut est fixée à 200. Si
|
|
une latence plus petite est recherchée, il peut être justifié d'abaisser cette
|
|
limite par l'utilisation du paramètre 'tune.maxpollevents' dans la section
|
|
'global'. L'augmenter permettra d'économiser un peu le processeur en présence
|
|
de très grands nombres de connexions simultanées.
|
|
|
|
Haproxy utilisera kqueue() ou speculative epoll() lorsque ce sera disponible,
|
|
puis epoll(), et se repliera sur poll(), puis en dernier lieu sur select().
|
|
Cependant, si pour une raison quelconque il s'avérait nécessaire de désactiver
|
|
epoll() ou poll() (p.ex: à cause d'un bug ou juste pour comparer les
|
|
performances), de nouvelles options globales ont été ajoutées dans ce but :
|
|
'nokqueue', 'noepoll' et 'nopoll'.
|
|
|
|
Exemple :
|
|
---------
|
|
global
|
|
# utiliser seulement select()
|
|
noepoll
|
|
nopoll
|
|
tune.maxpollevents 100
|
|
|
|
Remarque :
|
|
----------
|
|
Dans le but d'assurer une portabilité maximale des configurations, ces options
|
|
sont acceptées et ignorées si les mécanismes poll() ou epoll() n'ont pas été
|
|
activés lors de la compilation.
|
|
|
|
Afin de simplifier la résolution de problèmes, le paramètre '-de' en ligne de
|
|
commande désactive epoll(), le paramètre '-dp' désactive poll(), '-dk' kqueue()
|
|
et '-ds' désactive speculative epoll(). Ils sont respectivement équivalents à
|
|
'noepoll', 'nopoll', et 'nokqueue'.
|
|
|
|
|
|
2) Définition d'un service en écoute
|
|
====================================
|
|
|
|
Les sections de service débutent par le mot clé "listen" :
|
|
|
|
listen <nom_instance> [ <adresse_IP>:<plage_ports>[,...] ]
|
|
|
|
- <nom_instance> est le nom de l'instance décrite. Ce nom sera envoyé dans les
|
|
logs, donc il est souhaitable d'utiliser un nom relatif au service relayé.
|
|
Aucun test n'est effectué concernant l'unicité de ce nom, qui n'est pas
|
|
obligatoire, mais fortement recommandée.
|
|
|
|
- <adresse_IP> est l'adresse IP sur laquelle le relais attend ses connexions.
|
|
L'absence d'adresse ainsi que l'adresse 0.0.0.0 signifient que les connexions
|
|
pourront s'effectuer sur toutes les adresses de la machine.
|
|
|
|
- <plage_ports> correspond soit à un port, soit à une plage de ports sur
|
|
lesquels le relais acceptera des connexions pour l'adresse IP spécifiée.
|
|
Cette plage peut être :
|
|
- soit un port numérique (ex: '80')
|
|
- soit une plage constituée de deux valeurs séparées par un tiret
|
|
(ex: '2000-2100') représentant les extrémités incluses dans la
|
|
plage.
|
|
Il faut faire attention à l'usage des plages, car chaque combinaison
|
|
<adresse_IP>:<port> consomme une socket, donc un descripteur de fichier.
|
|
Le couple <adresse_IP>:<port> doit être unique pour toutes les instances
|
|
d'une même machine. L'attachement à un port inférieur à 1024 nécessite un
|
|
niveau de privilège particulier lors du lancement du programme
|
|
(indépendamment du paramètre 'uid' de la section 'global').
|
|
|
|
- le couple <adresse_IP>:<plage_ports> peut être répété indéfiniment pour
|
|
demander au relais d'écouter également sur d'autres adresses et/ou d'autres
|
|
plages de ports. Pour cela, il suffit de séparer les couples par une virgule.
|
|
|
|
Exemples :
|
|
---------
|
|
listen http_proxy :80
|
|
listen x11_proxy 127.0.0.1:6000-6009
|
|
listen smtp_proxy 127.0.0.1:25,127.0.0.1:587
|
|
listen ldap_proxy :389,:663
|
|
|
|
Si toutes les adresses ne tiennent pas sur une ligne, il est possible d'en
|
|
rajouter à l'aide du mot clé 'bind'. Dans ce cas, il n'est même pas nécessaire
|
|
de spécifier la première adresse sur la ligne listen, ce qui facilite parfois
|
|
l'écriture de configurations :
|
|
|
|
bind [ <adresse_IP>:<plage_ports>[,...] ]
|
|
|
|
Exemples :
|
|
----------
|
|
listen http_proxy
|
|
bind :80,:443
|
|
bind 10.0.0.1:10080,10.0.0.1:10443
|
|
|
|
2.1) Inhibition d'un service
|
|
----------------------------
|
|
Un service peut être désactivé pour des besoins de maintenance, sans avoir à
|
|
commenter toute une partie du fichier. Il suffit de positionner le mot clé
|
|
"disabled" dans sa section :
|
|
|
|
listen smtp_proxy 0.0.0.0:25
|
|
disabled
|
|
|
|
Remarque: le mot clé 'enabled' permet de réactiver un service préalablement
|
|
désactivé par le mot clé 'disabled', par exemple à cause d'une
|
|
configuration par défaut.
|
|
|
|
2.2) Mode de fonctionnement
|
|
---------------------------
|
|
Un service peut fonctionner dans trois modes différents :
|
|
- TCP
|
|
- HTTP
|
|
- état de santé
|
|
|
|
Mode TCP
|
|
--------
|
|
Dans ce mode, le service relaye, dès leur établissement, les connexions TCP
|
|
vers un ou plusieurs serveurs. Aucun traitement n'est effectué sur le flux. Il
|
|
s'agit simplement d'une association
|
|
source<adresse:port> -> destination<adresse:port>.
|
|
Pour l'utiliser, préciser le mode TCP sous la déclaration du relais.
|
|
|
|
Exemple :
|
|
---------
|
|
listen smtp_proxy 0.0.0.0:25
|
|
mode tcp
|
|
|
|
Mode HTTP
|
|
---------
|
|
Dans ce mode, le service relaye les connexions TCP vers un ou plusieurs
|
|
serveurs, une fois qu'il dispose d'assez d'informations pour en prendre la
|
|
décision. Les en-têtes HTTP sont analysés pour y trouver un éventuel cookie, et
|
|
certains d'entre-eux peuvent être modifiés par le biais d'expressions
|
|
régulières. Pour activer ce mode, préciser le mode HTTP sous la déclaration du
|
|
relais.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
|
|
Mode supervision
|
|
----------------
|
|
Il s'agit d'un mode offrant à un composant externe une visibilité de l'état de
|
|
santé du service. Il se contente de retourner "OK" à tout client se connectant
|
|
sur son port. Il peut être utilisé avec des répartiteurs de charge évolués pour
|
|
déterminer quels sont les services utilisables. Si l'option 'httpchk' est
|
|
activée, alors la réponse changera en 'HTTP/1.0 200 OK' pour satisfaire les
|
|
attentes de composants sachant tester en HTTP. Pour activer ce mode, préciser
|
|
le mode HEALTH sous la déclaration du relais.
|
|
|
|
Exemple :
|
|
---------
|
|
# réponse simple : 'OK'
|
|
listen health_check 0.0.0.0:60000
|
|
mode health
|
|
|
|
# réponse HTTP : 'HTTP/1.0 200 OK'
|
|
listen http_health_check 0.0.0.0:60001
|
|
mode health
|
|
option httpchk
|
|
|
|
|
|
2.2.1 Supervision
|
|
-----------------
|
|
Les versions 1.1.32 et 1.2.6 apportent une nouvelle solution pour valider le
|
|
bon fonctionnement du proxy sans perturber le service. Le mot-clé 'monitor-net'
|
|
a été créé dans le butd de spécifier un réseau d'équipements qui ne PEUVENT PAS
|
|
utiliser le service pour autre chose que des tests de fonctionnement. C'est
|
|
particulièrement adapté aux proxies TCP, car cela empêche le proxy de relayer
|
|
des établissements de connexion émis par un outil de surveillance.
|
|
|
|
Lorsque c'est utilisé sur un proxy TCP, la connexion est acceptée puis refermée
|
|
et rien n'est logué. C'est suffisant pour qu'un répartiteur de charge en amont
|
|
détecte que le service est disponible.
|
|
|
|
Lorsque c'est utilisé sur un proxy HTTP, la connexion est acceptée, rien n'est
|
|
logué, puis la réponse suivante est envoyée et la session refermée :
|
|
"HTTP/1.0 200 OK". C'est normalement suffisant pour qu'un répartiteur de charge
|
|
HTTP en amont détecte le service comme opérationnel, aussi bien à travers des
|
|
tests TCP que HTTP.
|
|
|
|
Les proxies utilisant le mot-clé 'monitor-net' peuvent accessoirement se passer
|
|
de l'option 'dontlognull', ce qui permettra de loguer les connexions vides
|
|
émises depuis d'autres adresses que celles du réseau de tests.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
listen tse-proxy
|
|
bind :3389,:1494,:5900 # TSE, ICA and VNC at once.
|
|
mode tcp
|
|
balance roundrobin
|
|
server tse-farm 192.168.1.10
|
|
monitor-net 192.168.1.252/31 # L4 load-balancers on .252 and .253
|
|
|
|
|
|
Lorsque le système effectuant les tests est situé derrière un proxy, le mot-clé
|
|
'monitor-net' n'est pas utilisable du fait que haproxy verra toujours la même
|
|
adresse pour le proxy. Pour pallier à cette limitation, la version 1.2.15 a
|
|
apporté le mot-clé 'monitor-uri'. Il définit une URI qui ne sera ni retransmise
|
|
ni logée, mais pour laquelle haproxy retournera immédiatement une réponse
|
|
"HTTP/1.0 200 OK". Cela rend possibles les tests de validité d'une chaîne
|
|
reverse-proxy->haproxy en une requête HTTP. Cela peut être utilisé pour valider
|
|
une combinaision de stunnel+haproxy à l'aide de tests HTTPS par exemple. Bien
|
|
entendu, ce mot-clé n'est valide qu'en mode HTTP, sinon il n'y a pas de notion
|
|
d'URI. Noter que la méthode et la version HTTP sont simplement ignorées.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
listen stunnel_backend :8080
|
|
mode http
|
|
balance roundrobin
|
|
server web1 192.168.1.10:80 check
|
|
server web2 192.168.1.11:80 check
|
|
monitor-uri /haproxy_test
|
|
|
|
|
|
2.3) Limitation du nombre de connexions simultanées
|
|
---------------------------------------------------
|
|
Le paramètre "maxconn" permet de fixer la limite acceptable en nombre de
|
|
connexions simultanées par proxy. Chaque proxy qui atteint cette valeur cesse
|
|
d'écouter jusqu'à libération d'une connexion. Voir plus loin concernant les
|
|
limitations liées au système.
|
|
|
|
Exemple :
|
|
---------
|
|
listen tiny_server 0.0.0.0:80
|
|
maxconn 10
|
|
|
|
|
|
2.4) Arrêt en douceur
|
|
---------------------
|
|
Il est possible d'arrêter les services en douceur en envoyant un signal
|
|
SIGUSR1 au processus relais. Tous les services seront alors mis en phase
|
|
d'arrêt, mais pourront continuer d'accepter des connexions pendant un temps
|
|
défini par le paramètre 'grace' (en millisecondes). Cela permet par exemple,
|
|
de faire savoir rapidement à un répartiteur de charge qu'il ne doit plus
|
|
utiliser un relais, tout en continuant d'assurer le service le temps qu'il
|
|
s'en rende compte.
|
|
|
|
Remarque :
|
|
----------
|
|
Les connexions actives ne sont jamais cassées. Dans le pire des cas, il faudra
|
|
attendre en plus leur expiration avant l'arrêt total du processus, ou bien tuer
|
|
manuellement le processus par l'envoi d'un signal SIGTERM. La valeur par défaut
|
|
du paramètre 'grace' est 0 (pas de grâce, arrêt immédiat de l'écoute).
|
|
|
|
Exemple :
|
|
---------
|
|
# arrêter en douceur par 'killall -USR1 haproxy'
|
|
# le service tournera encore 10 secondes après la demande d'arrêt
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
grace 10000
|
|
|
|
# ce port n'est testé que par un répartiteur de charge.
|
|
listen health_check 0.0.0.0:60000
|
|
mode health
|
|
grace 0
|
|
|
|
A partir de la version 1.2.8, un nouveau mécanisme de reconfiguration à chaud
|
|
a été introduit. Il est désormais possible de mettre les proxies en "pause" en
|
|
envoyant un signal SIGTTOU aux processus. Cela désactivera les sockets d'écoute
|
|
sans casser les sessions existantes. Suite à cela, l'envoi d'un signal SIGTTIN
|
|
réactivera les sockets d'écoute. Ceci est très pratique pour tenter de charger
|
|
une nouvelle configuration ou même une nouvelle version de haproxy sans casser
|
|
les connexions existantes. Si le rechargement s'effectue correctement, il ne
|
|
reste plus qu'à envoyer un signal SIGUSR1 aux anciens processus, ce qui
|
|
provoquera leur arrêt immédiat dès que leurs connexions seront terminées ; en
|
|
revanche, si le rechargement échoue, il suffit d'envoyer un signal SIGTTIN pour
|
|
remettre les ports en écoute et rétablir le service immédiatement. Veuillez
|
|
noter que le paramètre 'grace' est ignoré pour le signal SIGTTOU ainsi que le
|
|
signal SIGUSR1 une fois le processus en pause. Aussi, il peut s'avérer très
|
|
utile de sauver le fichier de pid avant de démarrer une nouvelle instance.
|
|
|
|
Ce mécanisme est pleinement exploité à partir de la version 1.2.11 avec les
|
|
options '-st' et '-sf' (voir ci-dessous).
|
|
|
|
2.4) Reconfiguration à chaud
|
|
----------------------------
|
|
Les paramètres '-st' et '-sf' sont utilisés pour informer des processus
|
|
existants que la configuration va être rechargée. Ils recevront le signal
|
|
SIGTTOU, leur demandant de libérer les ports en écoute afin que le nouveau
|
|
processus puisse les prendre. Si quoi que ce soit se passe mal, le nouveau
|
|
processus leur enverra un signal SIGTTIN pour leur indiquer qu'ils peuvent
|
|
se remettre en écoute et continuer leur travail. En revanche, si la
|
|
configuration se charge correctement, alors ils recevront un signal de demande
|
|
de fin de travail en douceur (-sf), ou de terminaison immédiate (-st) qui
|
|
coupera les sessions en cours. Un usage typique tel que celui-ci permet de
|
|
recharger une configuration sans interruption de service :
|
|
|
|
# haproxy -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
|
|
|
|
|
|
2.5) Temps d'expiration des connexions
|
|
--------------------------------------
|
|
Il est possible de paramétrer certaines durées d'expiration au niveau des
|
|
connexions TCP. Trois temps indépendants sont configurables et acceptent des
|
|
valeurs en millisecondes. Si l'une de ces trois temporisations est dépassée, la
|
|
session est terminée à chaque extrémité.
|
|
|
|
- temps d'attente d'une donnée de la part du client, ou de la
|
|
possibilité de lui envoyer des données : "clitimeout" :
|
|
|
|
# time-out client à 2mn30.
|
|
clitimeout 150000
|
|
|
|
- temps d'attente d'une donnée de la part du serveur, ou de la
|
|
possibilité de lui envoyer des données : "srvtimeout" :
|
|
|
|
# time-out serveur à 30s.
|
|
srvtimeout 30000
|
|
|
|
- temps d'attente de l'établissement d'une connexion vers un serveur
|
|
"contimeout" :
|
|
|
|
# on abandonne si la connexion n'est pas établie après 4 secondes
|
|
contimeout 4000
|
|
|
|
Remarques :
|
|
-----------
|
|
- "contimeout" et "srvtimeout" n'ont pas d'utilité dans le cas du serveur de
|
|
type "health".
|
|
- sous de fortes charges, ou sur un réseau saturé ou défectueux, il est
|
|
possible de perdre des paquets. Du fait que la première retransmission
|
|
TCP n'ait lieu qu'au bout de 3 secoudes, fixer un timeout de connexion
|
|
inférieur à 3 secondes ne permet pas de se rattraper sur la perte
|
|
de paquets car la session aura été abandonnée avant la première
|
|
retransmission. Une valeur de 4 secondes réduira considérablement
|
|
le nombre d'échecs de connexion.
|
|
- A compter de la version 1.3.14, il est possible de spécifier les durées
|
|
d'expiration dans des unités de temps arbitraires à choisir parmi
|
|
{ us, ms, s, m, h, d }. Pour cela, la valeur entière doit être suffixée
|
|
de l'unité.
|
|
|
|
2.6) Tentatives de reconnexion
|
|
------------------------------
|
|
Lors d'un échec de connexion vers un serveur, il est possible de
|
|
retenter (potentiellement vers un autre serveur, en cas de répartition
|
|
de charge). Le nombre de nouvelles tentatives infructueuses avant
|
|
abandon est fourni par le paramètre "retries".
|
|
|
|
Exemple :
|
|
---------
|
|
# on essaie encore trois fois maxi
|
|
retries 3
|
|
|
|
Il est à noter que la tentative de reconnexion peut amener à utiliser un autre
|
|
serveur si le premier a disparu entre deux tentatives de connexion.
|
|
|
|
|
|
2.7) Adresse du serveur
|
|
-----------------------
|
|
Le serveur vers lequel sont redirigées les nouvelles connexions est défini par
|
|
le paramètre "dispatch" sous la forme <adresse_ip>:<port>. Il correspond à un
|
|
serveur d'assignation de cookie dans le cas où le service consiste à assurer
|
|
uniquement une persistence HTTP, ou bien simplement au serveur destination dans
|
|
le cas de relayage TCP simple. Cet ancien mode ne permet pas de tester l'état
|
|
du serveur distant, et il est maintenant recommandé d'utiliser de préférence
|
|
le mode 'balance'.
|
|
|
|
Exemple :
|
|
---------
|
|
# on envoie toutes les nouvelles connexions ici
|
|
dispatch 192.168.1.2:80
|
|
|
|
Remarque :
|
|
----------
|
|
Ce paramètre n'a pas d'utilité pour un serveur en mode 'health', ni en mode
|
|
'balance'.
|
|
|
|
|
|
2.8) Adresse de sortie
|
|
----------------------
|
|
Il est possible de forcer l'adresse utilisée pour établir les connexions vers
|
|
les serveurs à l'aide du paramètre "source". Il est même possible de forcer le
|
|
port, bien que cette fonctionnalité se limite à des usages très spécifiques.
|
|
C'est particulièrement utile en cas d'adressage multiple, et plus généralement
|
|
pour permettre aux serveurs de trouver le chemin de retour dans des contextes
|
|
de routage difficiles. Si l'adresse est '0.0.0.0' ou '*' ou vide, elle sera
|
|
choisie librement par le systeme. Si le port est '0' ou vide, il sera choisi
|
|
librement par le système. Il est à noter que depuis la version 1.1.18, les
|
|
tests de bon fonctionnement des serveurs seront aussi effectués à partir de la
|
|
source spécifiée par ce paramètre.
|
|
|
|
Exemples :
|
|
----------
|
|
listen http_proxy *:80
|
|
# toutes les connexions prennent l'adresse 192.168.1.200
|
|
source 192.168.1.200:0
|
|
|
|
listen rlogin_proxy *:513
|
|
# utiliser l'adresse 192.168.1.200 et le port réservé 900
|
|
source 192.168.1.200:900
|
|
|
|
|
|
2.9) Définition du nom du cookie
|
|
--------------------------------
|
|
En mode HTTP, il est possible de rechercher la valeur d'un cookie pour savoir
|
|
vers quel serveur aiguiller la requête utilisateur. Le nom du cookie est donné
|
|
par le paramètre "cookie".
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy :80
|
|
mode http
|
|
cookie SERVERID
|
|
|
|
On peut modifier l'utilisation du cookie pour la rendre plus intelligente
|
|
vis-à-vis des applications relayées. Il est possible, notamment de supprimer ou
|
|
réécrire un cookie retourné par un serveur accédé en direct, et d'insérer un
|
|
cookie dans une réponse HTTP adressée à un serveur sélectionné en répartition
|
|
de charge, et même de signaler aux proxies amont de ne pas cacher le cookie
|
|
inséré.
|
|
|
|
Exemples :
|
|
----------
|
|
|
|
Pour ne conserver le cookie qu'en accès indirect, donc à travers le
|
|
dispatcheur, et supprimer toutes ses éventuelles occurences lors des accès
|
|
directs :
|
|
|
|
cookie SERVERID indirect
|
|
|
|
Pour remplacer la valeur d'un cookie existant par celle attribuée à un serveur,
|
|
lors d'un accès direct :
|
|
|
|
cookie SERVERID rewrite
|
|
|
|
Pour créer un cookie comportant la valeur attribuée à un serveur lors d'un
|
|
accès en répartition de charge interne. Dans ce cas, il est souhaitable que
|
|
tous les serveurs aient un cookie renseigné. Un serveur non assigné d'un cookie
|
|
retournera un cookie vide (cookie de suppression) :
|
|
|
|
cookie SERVERID insert
|
|
|
|
Pour réutiliser un cookie applicatif et lui préfixer l'identifiant du serveur,
|
|
puis le supprimer dans les requêtes suivantes, utiliser l'option 'prefix'. Elle
|
|
permet d'insérer une instance de haproxy devant une application sans risquer
|
|
d'incompatibilités dûes à des clients qui ne supporteraient pas d'apprendre
|
|
plus d'un cookie :
|
|
|
|
cookie JSESSIONID prefix
|
|
|
|
Pour insérer un cookie, en s'assurant qu'un cache en amont ne le stockera pas,
|
|
ajouter le mot clé 'nocache' après 'insert' :
|
|
|
|
cookie SERVERID insert nocache
|
|
|
|
Pour insérer un cookie seulement suite aux requêtes de type POST, ajouter le
|
|
mot clé 'postonly' après 'insert' :
|
|
|
|
cookie SERVERID insert postonly
|
|
|
|
|
|
Remarques :
|
|
-----------
|
|
- Il est possible de combiner 'insert' avec 'indirect' ou 'rewrite' pour
|
|
s'adapter à des applications générant déjà le cookie, avec un contenu
|
|
invalide. Il suffit pour cela de les spécifier sur la même ligne.
|
|
|
|
- dans le cas où 'insert' et 'indirect' sont spécifiés, le cookie n'est jamais
|
|
transmis au serveur vu qu'il n'en a pas connaissance et ne pourrait pas le
|
|
comprendre.
|
|
|
|
- il est particulièrement recommandé d'utiliser 'nocache' en mode insertion si
|
|
des caches peuvent se trouver entre les clients et l'instance du proxy. Dans
|
|
le cas contraire, un cache HTTP 1.0 pourrait cacher la réponse, incluant le
|
|
cookie de persistence inséré, donc provoquer des changements de serveurs pour
|
|
des clients partageant le même cache.
|
|
|
|
- le mode 'prefix' ne nécessite pas d'utiliser 'indirect', 'nocache', ni
|
|
'postonly', car tout comme le mode 'rewrite', il s'appuie sur un cookie
|
|
présenté par l'application qui est censée savoir à quel moment il peut
|
|
être émis sans risque. Toutefois, comme il nécessite de rectifier le cookie
|
|
présenté par le client dans chaque requête ultérieure, il est indispensable
|
|
de s'assurer que le client et le serveur communiqueront sans "keep-alive
|
|
HTTP". Dans le doute, il est recommandé d'utiliser l'option "httpclose".
|
|
|
|
- lorsque l'application est bien connue, et que les parties nécessitant de la
|
|
persistence sont systématiquement accédées par un formulaire en mode POST,
|
|
il est plus efficace encore de combiner le mot clé "postonly" avec "insert"
|
|
et "indirect", car la page d'accueil reste cachable, et c'est l'application
|
|
qui gère le 'cache-control'.
|
|
|
|
2.10) Assignation d'un serveur à une valeur de cookie
|
|
----------------------------------------------------
|
|
En mode HTTP, il est possible d'associer des valeurs de cookie à des serveurs
|
|
par le paramètre 'server'. La syntaxe est :
|
|
|
|
server <identifiant> <adresse_ip>:<port> cookie <valeur>
|
|
|
|
- <identifiant> est un nom quelconque de serveur utilisé pour l'identifier dans la
|
|
configuration et les logs.
|
|
- <adresse_ip>:<port> est le couple adresse-port sur lequel le serveur écoute.
|
|
- <valeur> est la valeur à reconnaître ou positionner dans le cookie.
|
|
|
|
Exemple : le cookie SERVERID peut contenir server01 ou server02
|
|
---------
|
|
listen http_proxy :80
|
|
mode http
|
|
cookie SERVERID
|
|
dispatch 192.168.1.100:80
|
|
server web1 192.168.1.1:80 cookie server01
|
|
server web2 192.168.1.2:80 cookie server02
|
|
|
|
Attention : la syntaxe a changé depuis la version 1.0.
|
|
-----------
|
|
|
|
3) Répartiteur de charge autonome
|
|
=================================
|
|
|
|
Le relais peut effectuer lui-même la répartition de charge entre les différents
|
|
serveurs définis pour un service donné, en mode TCP comme en mode HTTP. Pour
|
|
cela, on précise le mot clé 'balance' dans la définition du service,
|
|
éventuellement suivi du nom d'un algorithme de répartition. Jusqu'à la version
|
|
1.2.11, seul 'roundrobin' était géré, et c'est aussi la valeur implicite par
|
|
défaut. Avec la version 1.2.12, le nouveau mot clé 'source' est apparu. La
|
|
version 1.3.10 a également apporté le mot clé 'uri'. Il est évident qu'en cas
|
|
d'utilisation du répartiteur interne, il ne faudra pas spécifier d'adresse de
|
|
dispatch, et qu'il faudra au moins un serveur.
|
|
|
|
Exemple : même que précédemment en répartition interne
|
|
---------
|
|
|
|
listen http_proxy :80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
server web1 192.168.1.1:80 cookie server01
|
|
server web2 192.168.1.2:80 cookie server02
|
|
|
|
Depuis la version 1.1.22, il est possible de déterminer automatiquement le port
|
|
du serveur vers lequel sera envoyée la connexion, en fonction du port d'écoute
|
|
sur lequel le client s'est connecté. En effet, il y a 4 possibilités pour le
|
|
champ <port> de l'adresse serveur :
|
|
|
|
- non spécifié ou nul :
|
|
la connexion sera envoyée au serveur sur le même port que celui sur
|
|
lequel le relais a reçu la connexion.
|
|
|
|
- valeur numérique (seul cas supporté pour les versions antérieures) :
|
|
le serveur recevra la connexion sur le port désigné.
|
|
|
|
- valeur numérique précédée d'un signe '+' :
|
|
la connexion sera envoyée au serveur sur le même port que celui sur
|
|
lequel le relais a reçu la connexion, auquel on ajoute la valeur désignée.
|
|
|
|
- valeur numérique précédée d'un signe '-' :
|
|
la connexion sera envoyée au serveur sur le même port que celui sur
|
|
lequel le relais a reçu la connexion, duquel on soustrait la valeur
|
|
désignée.
|
|
|
|
Exemples :
|
|
----------
|
|
|
|
# même que précédemment
|
|
|
|
listen http_proxy :80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
server web1 192.168.1.1 cookie server01
|
|
server web2 192.168.1.2 cookie server02
|
|
|
|
# relayage simultané des ports 80 et 81 et 8080-8089
|
|
|
|
listen http_proxy :80,:81,:8080-8089
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
server web1 192.168.1.1 cookie server01
|
|
server web2 192.168.1.2 cookie server02
|
|
|
|
# relayage TCP des ports 25, 389 et 663 vers les ports 1025, 1389 et 1663
|
|
|
|
listen http_proxy :25,:389,:663
|
|
mode tcp
|
|
balance roundrobin
|
|
server srv1 192.168.1.1:+1000
|
|
server srv2 192.168.1.2:+1000
|
|
|
|
Comme indiqué précédemment, la version 1.2.12 apporta le nouveau mot clé
|
|
'source'. Lorsque celui-ci est utilisé, l'adresse IP du client est hachée et
|
|
distribuée de manière homogène parmi les serveurs disponibles, de sorte qu'une
|
|
même adresse IP aille toujours sur le même serveur tant qu'il n'y a aucun
|
|
changement dans le nombre de serveurs disponibles. Ceci peut être utilisé par
|
|
exemple pour attacher le HTTP et le HTTPS sur un même serveur pour un même
|
|
client. Cela peut également être utilisé pour améliorer la persistance
|
|
lorsqu'une partie de la population des clients n'accepte pas les cookies. Dans
|
|
ce cas, seuls ces derniers seront perturbés par la perte d'un serveur.
|
|
|
|
NOTE: il est important de prendre en compte le fait que beaucoup d'internautes
|
|
naviguent à travers des fermes de proxies qui assignent des adresses IP
|
|
différentes à chaque requête. D'autres internautes utilisent des liens à
|
|
la demande et obtiennent une adresse IP différente à chaque connexion. De
|
|
ce fait, le paramètre 'source' doit être utilisé avec une extrème
|
|
précaution.
|
|
|
|
Exemples :
|
|
----------
|
|
|
|
# assurer qu'une même adresse IP ira sur le même serveur pour tout service
|
|
|
|
listen http_proxy
|
|
bind :80,:443
|
|
mode http
|
|
balance source
|
|
server web1 192.168.1.1
|
|
server web2 192.168.1.2
|
|
|
|
# améliorer la persistance par l'utilisation de la source en plus du cookie :
|
|
|
|
listen http_proxy :80
|
|
mode http
|
|
cookie SERVERID
|
|
balance source
|
|
server web1 192.168.1.1 cookie server01
|
|
server web2 192.168.1.2 cookie server02
|
|
|
|
De plus, tel qu'indiqué ci-dessus, la version 1.3.10 a introduit le mot clé
|
|
'uri'. Il est très pratique dans le cas de répartition de charge entre des
|
|
reverse-proxy-caches, parce qu'il utilisera le résultat d'un hachage de l'URI
|
|
pour choisir un serveur, ce qui aura pour effet d'optimiser le taux de cache
|
|
du fait que la même URI sera toujours envoyée au même cache. Ce mot-clé n'est
|
|
autorisé qu'en mode HTTP.
|
|
|
|
Example :
|
|
---------
|
|
|
|
# Envoie toujours une URI donnée au même serveur
|
|
|
|
listen http_proxy
|
|
bind :3128
|
|
mode http
|
|
balance uri
|
|
server squid1 192.168.1.1
|
|
server squid2 192.168.1.2
|
|
|
|
La version 1.3.14 a apporté une nouvelle méthode 'balance url_param'. Elle
|
|
consiste à se baser sur un paramètre passé dans l'URL pour effectuer un hachage
|
|
utilisé pour déterminer le serveur à utiliser. Ceci est principalement utile
|
|
pour des applications n'ayant pas une exigence stricte de persistance, mais
|
|
pour lesquelles elle procure un gain de performance notable dans des
|
|
environnements où il n'est pas toujours possible d'utiliser des cookies. En cas
|
|
d'absence du paramètre dans l'URL, alors une répartition de type 'round robin'
|
|
est effectuée.
|
|
|
|
Example :
|
|
---------
|
|
|
|
# hache le paramètre "basket_id" dans l'URL pour déterminer le serveur
|
|
|
|
listen http_proxy
|
|
bind :3128
|
|
mode http
|
|
balance url_param basket_id
|
|
server ebiz1 192.168.1.1
|
|
server ebiz2 192.168.1.2
|
|
|
|
|
|
3.1) Surveillance des serveurs
|
|
------------------------------
|
|
Il est possible de tester l'état des serveurs par établissement de connexion
|
|
TCP ou par envoi d'une requête HTTP. Un serveur hors d'usage ne sera pas
|
|
utilisé dans le processus de répartition de charge interne. Pour activer la
|
|
surveillance, ajouter le mot clé 'check' à la fin de la déclaration du serveur.
|
|
Il est possible de spécifier l'intervalle (en millisecondes) séparant deux
|
|
tests du serveur par le paramètre "inter", le nombre d'échecs acceptés par le
|
|
paramètre "fall", et le nombre de succès avant reprise par le paramètre "rise".
|
|
Les paramètres non précisés prennent les valeurs suivantes par défaut :
|
|
|
|
- inter : 2000
|
|
- rise : 2
|
|
- fall : 3
|
|
- port : port de connexion du serveur
|
|
- addr : adresse de connexion du serveur (par defaut: adresse du serveur)
|
|
|
|
Le mode par défaut consiste à établir des connexions TCP uniquement. Dans
|
|
certains cas de pannes, des serveurs peuvent continuer à accepter les
|
|
connexions sans les traiter. Depuis la version 1.1.16, haproxy est en mesure
|
|
d'envoyer des requêtes HTTP courtes et très peu coûteuses. Les versions 1.1.16
|
|
et 1.1.17 utilisent "OPTIONS / HTTP/1.0". Dans les versions 1.1.18 à 1.1.20,
|
|
les requêtes ont été changées en "OPTIONS * HTTP/1.0" pour des raisons de
|
|
contrôle d'accès aux ressources. Cependant, cette requête documentée dans la
|
|
RFC2068 n'est pas comprise par tous les serveurs. Donc à partir de la version
|
|
1.1.21, la requête par défaut est revenue à "OPTIONS / HTTP/1.0", mais il est
|
|
possible de paramétrer la partie URI. Les requêtes OPTIONS présentent
|
|
l'avantage d'être facilement extractibles des logs, et de ne pas induire
|
|
d'accès aux fichiers côté serveur. Seules les réponses 2xx et 3xx sont
|
|
considérées valides, les autres (y compris non-réponses) aboutissent à un
|
|
échec. Le temps maximal imparti pour une réponse est égal à l'intervalle entre
|
|
deux tests (paramètre "inter"). Pour activer ce mode, spécifier l'option
|
|
"httpchk", éventuellement suivie d'une méthode et d'une URI. L'option "httpchk"
|
|
accepte donc 4 formes :
|
|
|
|
- option httpchk -> OPTIONS / HTTP/1.0
|
|
- option httpchk URI -> OPTIONS <URI> HTTP/1.0
|
|
- option httpchk METH URI -> <METH> <URI> HTTP/1.0
|
|
- option httpchk METH URI VER -> <METH> <URI> <VER>
|
|
|
|
HAProxy est souvent utilisé pour relayer divers protocoles reposant sur TCP,
|
|
tels que HTTPS, SMTP ou LDAP, le plus commun étant HTTPS. Un problème assez
|
|
couramment rencontré dans les data centers est le besoin de relayer du trafic
|
|
vers des serveurs lointains tout en maintenant la possibilité de basculer sur
|
|
un serveur de secours. Les tests purement TCP ne suffisent pas toujours dans
|
|
ces situations car l'on trouve souvent, dans la chaîne, des proxies, firewalls
|
|
ou répartiteurs de charge qui peuvent acquitter la connexion avant qu'elle
|
|
n'atteigne le serveur. La seule solution à ce problème est d'envoyer des tests
|
|
applicatifs. Comme la demande pour les tests HTTPS est élevée, ce test a été
|
|
implémenté en version 1.2.15 sur la base de messages SSLv3 CLIENT HELLO. Pour
|
|
l'activer, utiliser "option ssl-hello-chk". Ceci enverra des messages SSLv3
|
|
CLIENT HELLO aux serveurs, en annonçant un support pour la majorité des
|
|
algorithmes de chiffrement. Si en retour, le serveur envoie ce qui ressemble à
|
|
une réponse SSLv3 SERVER HELLO ou ALERT (refus des algorithmes), alors la
|
|
réponse sera considérée comme valide. Noter qu'Apache ne produit pas de log
|
|
lorsqu'il reçoit des messages HELLO, ce qui en fait un type de message
|
|
parfaitement adapté à ce besoin.
|
|
|
|
La version 1.3.10 est accompagnée d'un nouveau test d'état pour le SMTP. Par
|
|
défaut, il consiste à envoyer "HELO localhost" aux serveurs, et à attendre le
|
|
message "250" en retour. Notez qu'il peut aussi envoyer une requête plus
|
|
spécifique :
|
|
|
|
- option smtpchk -> envoie "HELO localhost"
|
|
- option smtpchk EHLO mail.mydomain.com -> envoie ce message ESMTP
|
|
|
|
Voir les exemples ci-après.
|
|
|
|
Depuis la version 1.1.17, il est possible de définir des serveurs de secours,
|
|
utilisés uniquement lorsqu'aucun des autres serveurs ne fonctionne. Pour cela,
|
|
ajouter le mot clé "backup" sur la ligne de définition du serveur. Un serveur
|
|
de secours n'est appelé que lorsque tous les serveurs normaux, ainsi que tous
|
|
les serveurs de secours qui le précèdent sont hors d'usage. Il n'y a donc pas
|
|
de répartition de charge entre des serveurs de secours par défaut. A partir
|
|
de la version 1.2.9, il est possible de les utiliser simultanément grâce à
|
|
l'option 'allbackups'. Ce type de serveurs peut servir à retourner des pages
|
|
d'indisponibilité de service. Dans ce cas, il est préférable de ne pas affecter
|
|
de cookie, afin que les clients qui le rencontrent n'y soient pas affectés
|
|
définitivement. Le fait de ne pas mettre de cookie envoie un cookie vide, ce
|
|
qui a pour effet de supprimer un éventuel cookie affecté précédemment.
|
|
|
|
Depuis la version 1.1.22, il est possible d'envoyer les tests de fonctionnement
|
|
vers un port différent de celui de service. C'est nécessaire principalement
|
|
pour les configurations où le serveur n'a pas de port prédéfini, par exemple
|
|
lorsqu'il est déduit du port d'acceptation de la connexion. Pour cela, utiliser
|
|
le paramètre 'port' suivi du numéro de port devant répondre aux requêtes. Il
|
|
est possible d'envoyer les tests de fonctionnement vers une adresse différente
|
|
de celle de service. Cela permet d'utiliser, sur la machine faisant fonctionner
|
|
HAproxy, un démon permettant des tests specifiques ( REGEX sur un résultat et
|
|
basculement de plusieurs fermes en cas d'erreur sur l'une d'elles).
|
|
|
|
Enfin, depuis la version 1.1.17, il est possible de visualiser rapidement
|
|
l'état courant de tous les serveurs. Pour cela, il suffit d'envoyer un signal
|
|
SIGHUP au processus proxy. L'état de tous les serveurs de tous les proxies est
|
|
envoyé dans les logs en niveau "notice", ainsi que sur la sortie d'erreurs si
|
|
elle est active. C'est une bonne raison pour avoir au moins un serveur de logs
|
|
local en niveau notice.
|
|
|
|
Depuis la version 1.1.18 (et 1.2.1), un message d'urgence est envoyé dans les
|
|
logs en niveau 'emerg' si tous les serveurs d'une même instance sont tombés,
|
|
afin de notifier l'administrateur qu'il faut prendre une action immédiate.
|
|
|
|
Depuis les versions 1.1.30 et 1.2.3, plusieurs serveurs peuvent partager la
|
|
même valeur de cookie. C'est particulièrement utile en mode backup, pour
|
|
sélectionner des chemins alternatifs pour un serveur donné, pour mettre en
|
|
oeuvre l'arrêt en douceur d'un serveur, ou pour diriger les clients
|
|
temporairement vers une page d'erreur en attendant le redémarrage d'une
|
|
application. Le principe est que lorsqu'un serveur est détecté comme inopérant,
|
|
le proxy cherchera le prochain serveur possédant la même valeur de cookie pour
|
|
chaque client qui le demandera. S'il ne trouve pas de serveur normal, alors il
|
|
le cherchera parmi les serveurs de backup. Consulter le guide d'architecture
|
|
pour plus d'informations.
|
|
|
|
Exemples :
|
|
----------
|
|
# conf du paragraphe 3) avec surveillance TCP
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
|
|
|
|
# même que précédemment avec surveillance HTTP par 'OPTIONS / HTTP/1.0'
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
option httpchk
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
|
|
|
|
# même que précédemment avec surveillance HTTP par 'OPTIONS /index.html HTTP/1.0'
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
option httpchk /index.html
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
|
|
|
|
# idem avec surveillance HTTP par 'HEAD /index.jsp? HTTP/1.1\r\nHost: www'
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID
|
|
balance roundrobin
|
|
option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
|
|
|
|
# répartition avec persistence basée sur le préfixe de cookie, et arrêt en
|
|
# douceur utilisant un second port (81) juste pour les health-checks.
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie JSESSIONID prefix
|
|
balance roundrobin
|
|
option httpchk HEAD /index.jsp? HTTP/1.1\r\nHost:\ www
|
|
server web1-norm 192.168.1.1:80 cookie s1 check port 81
|
|
server web2-norm 192.168.1.2:80 cookie s2 check port 81
|
|
server web1-stop 192.168.1.1:80 cookie s1 check port 80 backup
|
|
server web2-stop 192.168.1.2:80 cookie s2 check port 80 backup
|
|
|
|
# Insertion automatique de cookie dans la réponse du serveur, et suppression
|
|
# automatique dans la requête, tout en indiquant aux caches de ne pas garder
|
|
# ce cookie.
|
|
listen web_appl 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check
|
|
|
|
# idem avec serveur applicatif de secours sur autre site, et serveur de pages d'erreurs
|
|
listen web_appl 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
server web2 192.168.1.2:80 cookie server02 check
|
|
server web-backup 192.168.2.1:80 cookie server03 check backup
|
|
server web-excuse 192.168.3.1:80 check backup
|
|
|
|
# relayage SMTP+TLS avec test du serveur et serveur de backup
|
|
|
|
listen http_proxy :25,:587
|
|
mode tcp
|
|
balance roundrobin
|
|
server srv1 192.168.1.1 check port 25 inter 30000 rise 1 fall 2
|
|
server srv2 192.168.1.2 backup
|
|
|
|
# relayage HTTPS avec test du serveur et serveur de backup
|
|
|
|
listen http_proxy :443
|
|
mode tcp
|
|
option ssl-hello-chk
|
|
balance roundrobin
|
|
server srv1 192.168.1.1 check inter 30000 rise 1 fall 2
|
|
server srv2 192.168.1.2 backup
|
|
|
|
# Utilisation d'un groupe de serveurs pour le backup (nécessite haproxy 1.2.9)
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
balance roundrobin
|
|
option httpchk
|
|
server inst1 192.168.1.1:80 cookie s1 check
|
|
server inst2 192.168.1.2:80 cookie s2 check
|
|
server inst3 192.168.1.3:80 cookie s3 check
|
|
server back1 192.168.1.10:80 check backup
|
|
server back2 192.168.1.11:80 check backup
|
|
option allbackups # all backups will be used
|
|
|
|
|
|
3.2) Reconnexion vers un répartiteur en cas d'échec direct
|
|
----------------------------------------------------------
|
|
En mode HTTP, si un serveur défini par un cookie ne répond plus, les clients
|
|
seront définitivement aiguillés dessus à cause de leur cookie, et de ce fait,
|
|
définitivement privés de service. La spécification du paramètre 'redispatch'
|
|
autorise dans ce cas à renvoyer les connexions échouées vers le répartiteur
|
|
(externe ou interne) afin d'assigner un nouveau serveur à ces clients.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID
|
|
dispatch 192.168.1.100:80
|
|
server web1 192.168.1.1:80 cookie server01
|
|
server web2 192.168.1.2:80 cookie server02
|
|
redispatch # renvoyer vers dispatch si refus de connexion.
|
|
|
|
Par défaut (et dans les versions 1.1.16 et antérieures), le paramètre
|
|
redispatch ne s'applique qu'aux échecs de connexion au serveur. Depuis la
|
|
version 1.1.17, il s'applique aussi aux connexions destinées à des serveurs
|
|
identifiés comme hors d'usage par la surveillance. Si l'on souhaite malgré
|
|
tout qu'un client disposant d'un cookie correspondant à un serveur défectueux
|
|
tente de s'y connecter, il faut préciser l'option "persist" :
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
option persist
|
|
cookie SERVERID
|
|
dispatch 192.168.1.100:80
|
|
server web1 192.168.1.1:80 cookie server01
|
|
server web2 192.168.1.2:80 cookie server02
|
|
redispatch # renvoyer vers dispatch si serveur HS.
|
|
|
|
|
|
3.3) Assignation de poids différents à des serveurs
|
|
---------------------------------------------------
|
|
Parfois il arrive d'ajouter de nouveaux serveurs pour accroître la capacité
|
|
d'une ferme de serveur, mais le nouveau serveur est soit beaucoup plus petit
|
|
que les autres (dans le cas d'un ajout d'urgence de matériel de récupération),
|
|
soit plus puissant (lors d'un investissement dans du matériel neuf). Pour cette
|
|
raison, il semble parfois judicieux de pouvoir envoyer plus de clients vers les
|
|
plus gros serveurs. Jusqu'à la version 1.2.11, il était nécessaire de répliquer
|
|
plusieurs fois les définitions des serveurs pour augmenter leur poids. Depuis
|
|
la version 1.2.12, l'option 'weight' est disponible. HAProxy construit alors
|
|
une vue des serveurs disponibles la plus homogène possible en se basant sur
|
|
leur poids de sorte que la charge se distribue de la manière la plus lisse
|
|
possible. Le poids compris entre 1 et 256 doit refléter la capacité d'un
|
|
serveur par rapport aux autres. Le poids de 1 donne la fréquence d'apparition
|
|
la plus faible, et 256 la fréquence la plus élevée. De cette manière, si un
|
|
serveur disparait, les capacités restantes sont toujours respectées.
|
|
|
|
|
|
Exemple :
|
|
---------
|
|
# distribution équitable sur 2 opteron and un ancien pentium3
|
|
|
|
listen web_appl 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server pentium3-800 192.168.1.1:80 cookie server01 weight 8 check
|
|
server opteron-2.0G 192.168.1.2:80 cookie server02 weight 20 check
|
|
server opteron-2.4G 192.168.1.3:80 cookie server03 weight 24 check
|
|
server web-backup1 192.168.2.1:80 cookie server04 check backup
|
|
server web-excuse 192.168.3.1:80 check backup
|
|
|
|
Notes :
|
|
-------
|
|
- lorsque le poids n'est pas spécifié, la valeur par défaut est à 1
|
|
|
|
- le poids n'impacte pas les tests de fonctionnement (health checks), donc il
|
|
est plus propre d'utiliser les poids que de répliquer le même serveur
|
|
plusieurs fois.
|
|
|
|
- les poids s'appliquent également aux serveurs de backup si l'option
|
|
'allbackups' est positionnée.
|
|
|
|
- le poids s'applique aussi à la répartition selon la source
|
|
('balance source').
|
|
|
|
- quels que soient les poids, le premier serveur sera toujours assigné en
|
|
premier. Cette règle facilite les diagnostics.
|
|
|
|
- pour les puristes, l'algorithme de calculation de la vue des serveurs donne
|
|
une priorité aux premiers serveurs, donc la vue est la plus uniforme si les
|
|
serveurs sont déclarés dans l'ordre croissant de leurs poids.
|
|
|
|
La distribution du trafic suivra exactement le séquencement suivant :
|
|
|
|
Request| 1 1 1 1
|
|
number | 1 2 3 4 5 6 7 8 9 0 1 2 3
|
|
--------+---------------------------
|
|
p3-800 | X . . . . . . X . . . . .
|
|
opt-20 | . X . X . X . . . X . X .
|
|
opt-24 | . . X . X . X . X . X . X
|
|
|
|
|
|
3.4) Limitation du nombre de sessions concurrentes par serveur
|
|
--------------------------------------------------------------
|
|
Certains serveurs web multi-processus tels qu'Apache souffrent dès qu'il y a
|
|
trop de sessions concurrentes, parce qu'il est très coûteux de faire
|
|
fonctionner des centaines ou des milliers de processus sur un système. Une
|
|
solution consiste à augmenter le nombre de serveurs et de répartir la charge
|
|
entre eux, mais cela pose un problème lorsque le but est uniquement de résister
|
|
à des pics de charge occasionnels.
|
|
|
|
Pour résoudre ce problème, une nouvelle fonctionnalité a été implémentée dans
|
|
HAProxy 1.2.13. Il s'agit d'une limite "maxconn" par serveur, associée à une
|
|
file d'attente par serveur et par proxy. Ceci transforme HAProxy en un tampon
|
|
entre des milliers de clients et quelques serveurs. Dans bien des cas, le fait
|
|
de diminuer la valeur maxconn améliorera notablement les performances des
|
|
serveurs et diminuera les temps de réponse simplement parce que les serveurs
|
|
seront moins congestionnés.
|
|
|
|
Quand une requête cherche à joindre n'importe quel serveur, le premier serveur
|
|
non saturé est utilisé, en respectant l'algorithme de répartition de charge. Si
|
|
tous les serveurs sont saturés, alors la requête sera mise dans la file
|
|
d'attente globale de l'instance. Elle sortira de cette file d'attente lorsque
|
|
toutes les requêtes précédentes auront été libérées et qu'un serveur aura été
|
|
libéré d'une connexion pour la traiter.
|
|
|
|
Si une requête fait référence à un serveur en particulier (p.ex: hachage d'IP
|
|
source, ou persistance par cookie), et que ce server est saturé, alors la
|
|
requête sera mise dans la file d'attente dédiée à ce serveur. Cette file
|
|
d'attente est prioritaire sur la file d'attente globale, de sorte qu'il soit
|
|
plus facile d'atteindre le site pour les utilisateurs qui s'y trouvent déjà
|
|
que pour les nouveaux utilisateurs.
|
|
|
|
Pour cela, les logs ont dû être enrichis pour indiquer le nombre de sessions
|
|
par serveur, la position de la requête dans les files d'attentes, et le temps
|
|
passé en file d'attente. Ceci aide considérablement à faire de la prévision de
|
|
capacité. Voir la section 'logs' plus bas pour plus d'informations.
|
|
|
|
Exemple :
|
|
---------
|
|
# Prendre soin du P3 qui n'a que 256 Mo de RAM.
|
|
listen web_appl 0.0.0.0:80
|
|
maxconn 10000
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server pentium3-800 192.168.1.1:80 cookie s1 weight 8 maxconn 100 check
|
|
server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 maxconn 300 check
|
|
server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 maxconn 300 check
|
|
server web-backup1 192.168.2.1:80 cookie s4 check maxconn 200 backup
|
|
server web-excuse 192.168.3.1:80 check backup
|
|
|
|
Cette option se montra si efficace pour réduire les temps de réponse des
|
|
serveurs que certains utilisateurs voulaient utiliser des valeurs trop basses
|
|
pour améliorer les performances de leurs serveurs. Seulement, ils n'étaient
|
|
alors plus en mesure de supporter de très fortes charges parce qu'il n'était
|
|
plus possible de les saturer. Pour cette raison, la version 1.2.14 a apporté la
|
|
limitation dynamique de connexions avec l'addition du paramètre "minconn".
|
|
Lorsque ce paramètre est associé à "maxconn", il active la limitation dynamique
|
|
basée sur la charge de l'instance. Le nombre maximal de sessions concurrentes
|
|
sur un serveur devient alors proportionnel au nombre de sessions de l'instance
|
|
par rapport à son 'maxconn'. Un minimum de <minconn> sessions sera toujours
|
|
permis quelle que soit la charge. Ceci assurera que les serveurs travailleront
|
|
au meilleur de leurs performances sous des charges normales, et qu'ils seront
|
|
tout de même capables de supporter de fortes pointes lorsque nécessaire. La
|
|
limite dynamique est calculée comme ceci :
|
|
|
|
srv.dyn_limit = max(srv.minconn, srv.maxconn * inst.sess / inst.maxconn)
|
|
|
|
Exemple :
|
|
---------
|
|
# Prendre soin du P3 qui n'a que 256 Mo de RAM.
|
|
listen web_appl 0.0.0.0:80
|
|
maxconn 10000
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server pentium3-800 192.168.1.1:80 cookie s1 weight 8 minconn 10 maxconn 100 check
|
|
server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 minconn 30 maxconn 300 check
|
|
server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 minconn 30 maxconn 300 check
|
|
server web-backup1 192.168.2.1:80 cookie s4 check maxconn 200 backup
|
|
server web-excuse 192.168.3.1:80 check backup
|
|
|
|
Dans l'exemple ci-dessus, le serveur "pentium3-800' recevra au plus 100
|
|
connexions simultanées lorsque l'instance du proxy en atteindra 10000, et
|
|
recevra seulement 10 connexions simultanées tant que le proxy sera sous les 1000
|
|
sessions.
|
|
|
|
Il est possible de limiter la taille de la file d'attente dans le but de
|
|
redistribuer les connexions destinées à un serveur en particulier qui sont trop
|
|
loin pour avoir une chance d'être servies en un temps raisonnable. Ceci n'est
|
|
acceptable que dans le cas où l'affinité entre le client et le serveur n'est
|
|
pas obligatoire, mais motivée uniquement par des raisons de performances, par
|
|
exemple, par l'utilisation d'un cache local au serveur. L'option 'maxqueue'
|
|
permet de préciser la limite par serveur, tel que dans l'exemple ci-dessous :
|
|
|
|
... (même exemple que précédemment)
|
|
server pentium3-800 192.168.1.1:80 cookie s1 weight 8 minconn 10 maxconn 100 check maxqueue 50
|
|
server opteron-2.0G 192.168.1.2:80 cookie s2 weight 20 minconn 30 maxconn 300 check maxqueue 200
|
|
server opteron-2.4G 192.168.1.3:80 cookie s3 weight 24 minconn 30 maxconn 300 check
|
|
|
|
En l'absence du paramètre 'maxqueue', la file d'un serveur n'a pas de limite
|
|
définie. Dans le cas contraire, lorsque la file atteint la limite fixée par
|
|
'maxqueue', les clients sont déplacés vers la file globale.
|
|
|
|
Notes :
|
|
-------
|
|
- la requête ne restera pas indéfiniment en file d'attente, elle est
|
|
assujétie au paramètre 'contimeout', et si une requête ne peut pas
|
|
sortir de la file avant ce time-out, soit parce que le serveur est
|
|
saturé, soit parce qu'il y a trop de requêtes en file d'attente,
|
|
alors elle expirera avec une erreur 503.
|
|
|
|
- si seul <minconn> est spécifié, il a le même effet que <maxconn>
|
|
|
|
- positionner des valeurs trop basses pour 'maxconn' peut améliorer les
|
|
performances mais aussi permettre à des utilisateurs trop lents de bloquer
|
|
un serveur pour les autres utilisateurs.
|
|
|
|
|
|
3.5) Abandon des requêtes abortées
|
|
----------------------------------
|
|
En présence de très fortes charges, les serveurs mettront un certain temps à
|
|
répondre. La file d'attente du proxy se remplira, et les temps de réponse
|
|
suivront une croissance proportionnelle à la taille de file d'attente fois
|
|
le temps moyen de réponse par session. Lorsque les clients attendront plus de
|
|
quelques secondes, ils cliqueront souvent sur le bouton 'STOP' de leur
|
|
navigateur, laissant des requêtes inutiles en file d'attente et ralentissant
|
|
donc les autres utilisateurs.
|
|
|
|
Comme il n'y a aucun moyen de distinguer un vrai clic sur STOP d'une simple
|
|
fermeture du canal de sortie sur le client (shutdown(SHUT_WR)), les agents HTTP
|
|
doivent être conservateurs et considérer que le client n'a probablement fermé
|
|
que le canal de sortie en attendant la réponse. Toutefois, ceci introduit des
|
|
risques de congestion lorsque beaucoup d'utilisateurs font de même, et s'avère
|
|
aujourd'hui complètement inutile car probablement aucun client ne referme la
|
|
session en attendant la réponse. Certains agents HTTP supportent ceci (Squid,
|
|
Apache, HAProxy), et d'autres ne le supportent pas (TUX, et la plupart des
|
|
répartiteurs de charge matériels). Donc la probabilité pour qu'une notification
|
|
de fermeture d'un canal d'entrée côté client représente un utilisateur cliquant
|
|
sur 'STOP' est proche de 100%, et il est vraiment tentant d'abandonner la
|
|
requête prématurément sans polluer les serveurs.
|
|
|
|
Pour cette raison, une nouvelle option "abortonclose" a été introduite en
|
|
version 1.2.14. Par défaut (sans l'option), le comportement reste conforme à
|
|
HTTP. Mais lorsque l'option est spécifiée, une session dont le canal entrant
|
|
est fermé sera abortée si cela est possible, c'est à dire que la requête est
|
|
soit en file d'attente, soit en tentative de connexion. Ceci réduit
|
|
considérablement la longueur des files d'attentes et la charge sur les serveurs
|
|
saturés lorsque les utilisateurs sont tentés de cliquer sur 'STOP', ce qui à
|
|
son tour, réduit les temps de réponse pour les autres utilisateurs.
|
|
|
|
Exemple :
|
|
---------
|
|
listen web_appl 0.0.0.0:80
|
|
maxconn 10000
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server web1 192.168.1.1:80 cookie s1 weight 10 maxconn 100 check
|
|
server web2 192.168.1.2:80 cookie s2 weight 10 maxconn 100 check
|
|
server web3 192.168.1.3:80 cookie s3 weight 10 maxconn 100 check
|
|
server bck1 192.168.2.1:80 cookie s4 check maxconn 200 backup
|
|
option abortonclose
|
|
|
|
|
|
4) Fonctionnalités additionnelles
|
|
=================================
|
|
|
|
D'autres fonctionnalités d'usage moins courant sont disponibles. Il s'agit
|
|
principalement du mode transparent, de la journalisation des connexions, de la
|
|
réécriture des en-têtes, et du statut sous forme de page HTML.
|
|
|
|
|
|
4.1) Fonctionnalités réseau
|
|
---------------------------
|
|
4.1.1) Fonctionnement en mode transparent
|
|
---------------------------------------
|
|
En mode HTTP, le mot clé 'transparent' permet d'intercepter des sessions
|
|
routées à travers la machine hébergeant le proxy. Dans ce mode, on ne précise
|
|
pas l'adresse de répartition 'dispatch', car celle-ci est tirée de l'adresse
|
|
destination de la session détournée. Le système doit permettre de rediriger les
|
|
paquets vers un processus local.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:65000
|
|
mode http
|
|
transparent
|
|
cookie SERVERID
|
|
server server01 192.168.1.1:80
|
|
server server02 192.168.1.2:80
|
|
|
|
# iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \
|
|
--dport 80 -j REDIRECT --to-ports 65000
|
|
|
|
Remarque :
|
|
----------
|
|
Si le port n'est pas spécifié sur le serveur, c'est le port auquel s'est
|
|
adressé le client qui sera utilisé. Cela permet de relayer tous les ports TCP
|
|
d'une même adresse avec une même instance et sans utiliser directement le mode
|
|
transparent.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:65000
|
|
mode tcp
|
|
server server01 192.168.1.1 check port 60000
|
|
server server02 192.168.1.2 check port 60000
|
|
|
|
# iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \
|
|
-j REDIRECT --to-ports 65000
|
|
|
|
|
|
4.1.2) Choix d'une adresse source par serveur
|
|
---------------------------------------------------
|
|
Avec les versions 1.1.30 et 1.2.3, il devient possible de spécifier une adresse
|
|
IP source pour joindre chaque serveur. C'est utile pour joindre des serveurs de
|
|
backup à partir d'un LAN différent, ou pour utiliser des chemins alternatifs
|
|
pour joindre le même serveur. C'est également utilisable pour faciliter une
|
|
répartition de charge selon l'adresse IP source pour des connexions sortantes.
|
|
Bien entendu, la même adresse est utilisée pour les health-checks.
|
|
|
|
Exemple :
|
|
---------
|
|
# utiliser une adresse particulière pour joindre les 2 serveur
|
|
listen http_proxy 0.0.0.0:65000
|
|
mode http
|
|
balance roundrobin
|
|
server server01 192.168.1.1:80 source 192.168.2.13
|
|
server server02 192.168.1.2:80 source 192.168.2.13
|
|
|
|
Exemple :
|
|
---------
|
|
# utiliser une adresse particulière pour joindre chaque serveur
|
|
listen http_proxy 0.0.0.0:65000
|
|
mode http
|
|
balance roundrobin
|
|
server server01 192.168.1.1:80 source 192.168.1.1
|
|
server server02 192.168.2.1:80 source 192.168.2.1
|
|
|
|
Exemple :
|
|
---------
|
|
# faire une répartition d'adresse sources pour joindre le même proxy à
|
|
# travers deux liens WAN
|
|
listen http_proxy 0.0.0.0:65000
|
|
mode http
|
|
balance roundrobin
|
|
server remote-proxy-way1 192.168.1.1:3128 source 192.168.2.1
|
|
server remote-proxy-way2 192.168.1.1:3128 source 192.168.3.1
|
|
|
|
Exemple :
|
|
---------
|
|
# forcer une connexion TCP à s'attacher à un port particulier
|
|
listen http_proxy 0.0.0.0:2000
|
|
mode tcp
|
|
balance roundrobin
|
|
server srv1 192.168.1.1:80 source 192.168.2.1:20
|
|
server srv2 192.168.1.2:80 source 192.168.2.1:20
|
|
|
|
4.1.3) Maintien de session TCP (keep-alive)
|
|
-------------------------------------------
|
|
Avec la version 1.2.7, il devient possible d'activer le maintien de session
|
|
TCP (TCP keep-alive) à la fois côté client et côté serveur. Cela permet
|
|
d'empêcher des sessions longues d'expirer sur des équipements de niveau 4
|
|
externes tels que des firewalls ou des répartiteurs de charge. Cela permet
|
|
aussi au système de détecter et terminer des sessions figées lorsqu'aucun
|
|
time-out n'a été positionné (fortement déconseillé). Le proxy ne peut pas
|
|
positionner l'intervalle entre les annonces ni le nombre maximal, veuillez
|
|
vous référer au manuel du système d'exploitation pour cela. Il existe 3 options
|
|
pour activer le maintien de session TCP :
|
|
|
|
option tcpka # active le keep-alive côté client et côté serveur
|
|
option clitcpka # active le keep-alive côté client
|
|
option srvtcpka # active le keep-alive côté serveur
|
|
|
|
4.1.4) Rémanence des données TCP (lingering)
|
|
--------------------------------------------
|
|
Il est possible de désactiver la conservation de données non acquittées par un
|
|
client à la fin d'une session. Cela peut parfois s'avérer nécessaire lorsque
|
|
haproxy est utilisé en face d'un grand nombre de clients non fiables et qu'un
|
|
nombre élevé de sockets en état FIN_WAIT est observé sur la machine. L'option
|
|
peut être utilisée dans un frontend pour ajuster les connexions vers les
|
|
clients, et dans un backend pour ajuster les connexions vers les serveurs :
|
|
|
|
option nolinger # désactive la conservation de données
|
|
|
|
|
|
4.2) Journalisation des connexions
|
|
----------------------------------
|
|
|
|
L'un des points forts de HAProxy est indéniablement la précision de ses logs.
|
|
Il fournit probablement le plus fin niveau d'information disponible pour un
|
|
tel outil, ce qui est très important pour les diagnostics en environnements
|
|
complexes. En standard, les informations journalisées incluent le port client,
|
|
les chronométrages des états TCP/HTTP, des états de session précis au moment de
|
|
la terminaison et sa cause, des informations sur les décisions d'aiguillage du
|
|
trafic vers un serveur, et bien sûr la possibilité de capturer des en-têtes
|
|
arbitraires.
|
|
|
|
Dans le but d'améliorer la réactivité des administrateurs, il offre une grande
|
|
transparence sur les problèmes rencontrés, à la fois internes et externes, et
|
|
il est possible d'envoyer les logs vers des serveurs différents en même temps
|
|
avec des niveaux de filtrage différents :
|
|
|
|
- logs globaux au niveau processus (erreurs système, arrêts/démarrages, ...)
|
|
- erreurs système et internes par instance (manque de ressources, bugs, ...)
|
|
- problèmes externes par instance (arrêts/relance serveurs, limites, ...)
|
|
- activité par instance (connexions clients), aussi bien lors de leur
|
|
établissement qu'à leur terminaison.
|
|
|
|
La possibilité de distribuer différents niveaux de logs à différents serveurs
|
|
permet à plusieurs équipes de production d'intéragir et de corriger leurs
|
|
problèmes le plus tôt possible. Par exemple, l'équipe système peut surveiller
|
|
occasionnellement les erreurs système, pendant que l'équipe application
|
|
surveille les alertes d'arrêts/démarrages de ses serveurs en temps réel, et
|
|
que l'équipe sécurité analyse l'activité en différé d'une heure.
|
|
|
|
|
|
4.2.1) Niveaux de log
|
|
---------------------
|
|
Les connexions TCP et HTTP peuvent donner lieu à une journalisation sommaire ou
|
|
détaillée indiquant, pour chaque connexion, la date, l'heure, l'adresse IP
|
|
source, le serveur destination, la durée de la connexion, les temps de réponse,
|
|
la requête HTTP, le code de retour, la quantité de données transmises, et même
|
|
dans certains cas, la valeur d'un cookie permettant de suivre les sessions.
|
|
Tous les messages sont envoyés en syslog vers un ou deux serveurs. Se référer à
|
|
la section 1.1 pour plus d'information sur les catégories de logs. La syntaxe
|
|
est la suivante :
|
|
|
|
log <adresse_ip_1> <catégorie_1> [niveau_max_1]
|
|
log <adresse_ip_2> <catégorie_2> [niveau_max_2]
|
|
ou
|
|
log global
|
|
|
|
Remarque :
|
|
----------
|
|
La syntaxe spécifique 'log global' indique que l'on souhaite utiliser les
|
|
paramètres de journalisation définis dans la section 'global'.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
log 192.168.2.200 local3
|
|
log 192.168.2.201 local4
|
|
|
|
4.2.2) Format des logs
|
|
----------------------
|
|
Par défaut, les connexions sont journalisées au niveau TCP dès l'établissement
|
|
de la session entre le client et le relais. En précisant l'option 'tcplog',
|
|
la connexion ne sera journalisée qu'en fin de session, ajoutant des précisions
|
|
sur son état lors de la déconnexion, ainsi que le temps de connexion et la
|
|
durée totale de la session. Le nombre de sessions restantes après la
|
|
déconnexion est également indiqué (pour le serveur, l'instance et le process).
|
|
|
|
Exemple de journalisation TCP :
|
|
-------------------------------
|
|
listen relais-tcp 0.0.0.0:8000
|
|
mode tcp
|
|
option tcplog
|
|
log 192.168.2.200 local3
|
|
|
|
>>> haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/0/5007 0 -- 1/1/1 0/0
|
|
|
|
Champ Format / Description Exemple
|
|
|
|
1 nom_processus '[' pid ']:' haproxy[18989]:
|
|
2 ip_client ':' port_client 127.0.0.1:34550
|
|
3 '[' date ']' [15/Oct/2003:15:24:28]
|
|
4 nom_instance relais-tcp
|
|
5 nom_serveur Srv1
|
|
6 temps_file '/' temps_connect '/' temps_total 0/0/5007
|
|
7 octets lus 0
|
|
8 etat_terminaison --
|
|
9 conn_srv '/' conns_inst '/' conns_processus 1/1/1
|
|
10 position en file d'attente srv '/' globale 0/0
|
|
|
|
Une autre option, 'httplog', fournit plus de détails sur le protocole HTTP,
|
|
notamment la requête et l'état des cookies. Dans les cas où un mécanisme de
|
|
surveillance effectuant des connexions et déconnexions fréquentes, polluerait
|
|
les logs, il suffit d'ajouter l'option 'dontlognull', pour ne plus obtenir une
|
|
ligne de log pour les sessions n'ayant pas donné lieu à un échange de données
|
|
(requête ou réponse).
|
|
|
|
Exemple de journalisation HTTP :
|
|
--------------------------------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
option httplog
|
|
option dontlognull
|
|
log 192.168.2.200 local3
|
|
|
|
>>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/0/7/147/723 200 243 - - ---- 2/3/3 0/0 "HEAD / HTTP/1.0"
|
|
|
|
Exemple plus complet :
|
|
|
|
haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/-1/11215 503 0 - - SC-- 137/202/205 0/0 {w.ods.org|Mozilla} {} "HEAD / HTTP/1.0"
|
|
|
|
Champ Format / Description Exemple
|
|
|
|
1 nom_processus '[' pid ']:' haproxy[18989]:
|
|
2 ip_client ':' port_client 10.0.0.1:34552
|
|
3 '[' date ']' [15/Oct/2003:15:26:31]
|
|
4 nom_instance relais-http
|
|
5 nom_serveur Srv1
|
|
6 Tq '/' Tw '/' Tc '/' Tr '/' Tt 3183/-1/-1/-1/11215
|
|
7 Code_retour_HTTP 503
|
|
8 octets lus 0
|
|
9 cookies_requête_capturés -
|
|
10 cookies_reponse_capturés -
|
|
11 etat_terminaison SC--
|
|
12 conns_srv '/' conns_inst '/' conns_processus 137/202/205
|
|
13 position file serveur '/' globale 0/0
|
|
14 '{' entetes_requête_capturés '}' {w.ods.org|Mozilla}
|
|
15 '{' entetes_reponse_capturés '}' {}
|
|
16 '"' requête_HTTP '"' "HEAD / HTTP/1.0"
|
|
|
|
Note pour les analyseurs de logs : l'URI est TOUJOURS le dernier champ de la ligne, et
|
|
commence par un guillemet '"'.
|
|
|
|
Le problème de loguer uniquement en fin de session, c'est qu'il est impossible
|
|
de savoir ce qui se passe durant de gros transferts ou des sessions longues.
|
|
Pour pallier à ce problème, une nouvelle option 'logasap' a été introduite dans
|
|
la version 1.1.28 (1.2.1). Lorsqu'elle est activée, le proxy loguera le plus
|
|
tôt possible, c'est à dire juste avant que ne débutent les transferts de
|
|
données. Cela signifie, dans le cas du TCP, qu'il loguera toujours le résultat
|
|
de la connexion vers le serveur, et dans le cas HTTP, qu'il loguera en fin de
|
|
traitement des en-têtes de la réponse du serveur, auquel cas le nombre d'octets
|
|
représentera la taille des en-têtes retournés au client.
|
|
|
|
Afin d'éviter toute confusion avec les logs normaux, le temps total de
|
|
transfert et le nombre d'octets transférés sont préfixés d'un signe '+'
|
|
rappelant que les valeurs réelles sont certainement plus élevées.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
option httplog
|
|
option dontlognull
|
|
option logasap
|
|
log 192.168.2.200 local3
|
|
|
|
>>> haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- 3/3 "GET /image.iso HTTP/1.0"
|
|
|
|
|
|
4.2.3) Chronométrage des événements
|
|
-----------------------------------
|
|
Pour déceler des problèmes réseau, les mesures du temps écoulé entre certains
|
|
événements sont d'une très grande utilité. Tous les temps sont mesurés en
|
|
millisecondes (ms). En mode HTTP, quatre points de mesure sont rapportés sous
|
|
la forme Tq/Tw/Tc/Tr/Tt :
|
|
|
|
- Tq: temps total de réception de la requête HTTP de la part du client.
|
|
C'est le temps qui s'est écoulé entre le moment où le client a établi
|
|
sa connexion vers le relais, et le moment où ce dernier a reçu le dernier
|
|
en-tête HTTP validant la fin de la requête. Une valeur '-1' ici indique
|
|
que la requête complète n'a jamais été reçue.
|
|
|
|
- Tw: temps total passé dans les files d'attente avant d'obtenir une place
|
|
vers un serveur. Ceci tient compte à la fois de la file d'attente globale
|
|
et de celle du serveur, et dépend du nombre de requêtes dans la file et du
|
|
temps nécessaire au serveur pour compléter les sessions précédentes. La
|
|
valeur '-1' indique que la requête a été détruite avant d'atteindre une
|
|
file.
|
|
|
|
- Tc: temps d'établissement de la connexion TCP du relais vers le serveur.
|
|
C'est le temps écoulé entre le moment ou le relais a initié la demande de
|
|
connexion vers le serveur, et le moment où ce dernier l'a acquittée, c'est
|
|
à dire le temps entre l'envoi du paquet TCP SYN la réception du SYN/ACK.
|
|
Une valeur '-1' ici indique que la connexion n'a jamais pu être établie
|
|
vers le serveur.
|
|
|
|
- Tr: temps de réponse du serveur. C'est le temps que le serveur a mis pour
|
|
renvoyer la totalité des en-têtes HTTP à partir du moment où il a acquitté
|
|
la connexion. Ca représente exactement le temps de traitement de la
|
|
transaction sans le transfert des données associées. Une valeur '-1'
|
|
indique que le serveur n'a pas envoyé la totalité de l'en-tête HTTP.
|
|
|
|
- Tt: durée de vie totale de la session, entre le moment où la demande de
|
|
connexion du client a été acquittée et le moment où la connexion a été
|
|
refermée aux deux extrémités (client et serveur). La signification change
|
|
un peu si l'option 'logasap' est présente. Dans ce cas, le temps correspond
|
|
uniquement à (Tq + Tw + Tc + Tr), et se trouve préfixé d'un signe '+'. On
|
|
peut donc déduire Td, le temps de transfert des données, en excluant les
|
|
autres temps :
|
|
|
|
Td = Tt - (Tq + Tw + Tc + Tr)
|
|
|
|
Les temps rapportés à '-1' sont simplement à éliminer de cette équation.
|
|
|
|
En mode TCP ('option tcplog'), seuls les deux indicateurs Tw, Tc et Tt sont
|
|
rapportés.
|
|
|
|
Ces temps fournissent de précieux renseignement sur des causes probables de
|
|
problèmes. Du fait que le protocole TCP définisse des temps de retransmission
|
|
de 3 secondes, puis 6, 12, etc..., l'observation de temps proches de multiples
|
|
de 3 secondes indique pratiquement toujours des pertes de paquets liés à un
|
|
problème réseau (câble ou négociation). De plus, si <Tt> est proche d'une
|
|
valeur de time-out dans la configuration, c'est souvent qu'une session a été
|
|
abandonnée sur expiration d'un time-out.
|
|
|
|
Cas les plus fréquents :
|
|
|
|
- Si Tq est proche de 3000, un paquet a très certainement été perdu entre
|
|
le client et le relais.
|
|
- Si Tc est proche de 3000, un paquet a très certainement été perdu entre
|
|
le relais et le serveur durant la phase de connexion. Cet indicateur
|
|
devrait normalement toujours être très bas (moins de quelques dizaines).
|
|
- Si Tr est presque toujours inférieur à 3000, et que certaines valeurs
|
|
semblent proches de la valeur moyenne majorée de 3000, il y a peut-être
|
|
de pertes entre le relais et le serveur.
|
|
- Si Tt est légèrement supérieur au time-out, c'est souvent parce que le
|
|
client et le serveur utilisent du keep-alive HTTP entre eux et que la
|
|
session est maintenue après la fin des échanges. Voir plus loin pour
|
|
savoir comment désactiver le keep-alive HTTP.
|
|
|
|
Autres cas ('xx' représentant une valeur quelconque à ignorer) :
|
|
-1/xx/xx/xx/Tt: le client n'a pas envoyé sa requête dans le temps imparti ou
|
|
a refermé sa connexion sans compléter la requête.
|
|
Tq/-1/xx/xx/Tt: Il n'était pas possible de traiter la request, probablement
|
|
parce que tous les serveurs étaient hors d'usage.
|
|
Tq/Tw/-1/xx/Tt: la connexion n'a pas pu s'établir vers le serveur (refus ou
|
|
time-out au bout de Tt-(Tq+Tw) ms).
|
|
Tq/Tw/Tc/-1/Tt: le serveur a accepté la connexion mais n'a pas répondu dans
|
|
les temps ou bien a refermé sa connexion trop tôt, au bout
|
|
de Tt-(Tq+Tw+Tc) ms.
|
|
|
|
4.2.4) Conditions de déconnexion
|
|
--------------------------------
|
|
Les logs TCP et HTTP fournissent un indicateur de complétude de la session dans
|
|
le champ 'etat_terminaison', juste avant le nombre de connexions actives. C'est
|
|
un champ long de 2 caractères en TCP et de 4 caractères en HTTP, chacun ayant
|
|
une signification précise :
|
|
|
|
- sur le premier caractère, un code précisant le premier événement qui a causé
|
|
la terminaison de la session :
|
|
|
|
C : fermeture inattendue de la session TCP de la part du client.
|
|
|
|
S : fermeture inattendue de la session TCP de la part du serveur, ou
|
|
refus explicite de connexion de la part de ce dernier.
|
|
|
|
P : terminaison prématurée des sessions par le proxy, pour cause
|
|
d'imposition d'une limite sur le nombre de connexions, pour cause
|
|
de configuration (ex: filtre d'URL), ou parce qu'un contrôle de
|
|
sécurité a détecté et bloqué une anomalie dans la réponse du
|
|
serveur qui aurait pu causer une fuite d'informations (par exemple,
|
|
un cookie cachable).
|
|
|
|
R : une ressource sur le proxy a été épuisée (mémoire, sockets, ports
|
|
source, ...). Généralement, cela arrive au cours de l'établissement
|
|
d'une connexion, et les logs système doivent contenir une copie de
|
|
l'érreur précise.
|
|
|
|
I : une erreur interne a été identifiée par le proxy à la suite d'un
|
|
auto-contrôle. Ceci ne doit JAMAIS arriver, et vous êtes encouragés
|
|
à remonter n'importe quel log contenant ceci car il s'agira un bug.
|
|
|
|
c : le délai maximal d'attente du client a expiré (clitimeout).
|
|
|
|
s : le délai maximal d'attente du serveur a expiré (srvtimeout et contimeout)
|
|
|
|
- : terminaison normale de session.
|
|
|
|
- sur le second caractère, l'état d'avancement de la session TCP/HTTP lors de
|
|
la fermeture :
|
|
|
|
R : attente d'une REQUETE HTTP complète de la part du client. Rien n'a
|
|
été transmis au serveur.
|
|
|
|
Q : attente en file d'attente (QUEUE) d'une place pour avoir une
|
|
connexion vers un serveur. Ne peut apparaître que sur un serveur
|
|
possédant un paramètre 'maxconn'. Aucune connexion n'a été envoyée
|
|
au serveur.
|
|
|
|
C : attente de l'établissement d'une CONNEXION vers le serveur. Le
|
|
serveur peut au plus avoir vu la tentative de connexion, mais
|
|
aucune donnée n'a été échangée.
|
|
|
|
H : attente, réception ou traitement des en-têtes HTTP ("HEADERS").
|
|
|
|
D : transfert des DONNEES du serveur vers le client.
|
|
|
|
L : transfert des dernières ("LAST") données du proxy vers le client,
|
|
alors que le serveur a déjà fini.
|
|
|
|
T : requête bloquée en mode "tarpit" par le proxy. Elle a été maintenue
|
|
ouverte vers le client pendant toute la durée du contimeout ou
|
|
jusqu'à l'abandon de la part du client.
|
|
|
|
- : terminaison normale, après fin de transfert des données.
|
|
|
|
- le troisième caractère indique l'éventuelle identification d'un cookie de
|
|
persistence (uniquement en mode HTTP) :
|
|
|
|
N : aucun cookie de persistence n'a été présenté. C'est généralement le
|
|
cas sur les NOUVELLES connexions clients.
|
|
|
|
I : le client a présenté un cookie INVALIDE ne correspondant à aucun
|
|
serveur connu. Ceci peut être dû à un changement de configuration
|
|
récent, à des mélanges de noms de cookies entre sites HTTP/HTTPS,
|
|
ou à une attaque.
|
|
|
|
D : le client a présenté un cookie correspondant à un serveur hors
|
|
d'usage ("DOWN"). Suivant l'option 'persist', il a été renvoyé vers
|
|
un autre serveur ou a tout de même tenté de se connecter sur celui
|
|
correspondant au cookie.
|
|
|
|
V : le client a présenté un cookie VALIDE et a pu se connecter au
|
|
serveur correspondant.
|
|
|
|
- : non appliquable (pas de cookie positionné dans la configuration).
|
|
|
|
- le dernier caractère indique l'éventuel traitement effectué sur un cookie de
|
|
persistence retrourné par le serveur (uniquement en mode HTTP) :
|
|
|
|
N : aucun cookie de persistance n'a été fourni par le serveur, et aucun
|
|
n'a été inséré.
|
|
|
|
I : aucun cookie de persistance n'a été fourni par le serveur, et le
|
|
proxy en a INSERE un.
|
|
|
|
P : un cookie de persistence a été fourni par le serveur et transmis
|
|
tel quel ("PASSIF").
|
|
|
|
R : le cookie retourné par le serveur a été REECRIT par le proxy.
|
|
|
|
D : le cookie présenté par le serveur a été DETRUIT par le proxy pour
|
|
ne pas être retourné au client.
|
|
|
|
- : non appliquable
|
|
|
|
|
|
La combinaison des deux premiers indicateurs fournit une grande quantitié
|
|
d'informations sur ce qui se passait lorsque la session s'est terminée. Cela
|
|
peut notamment aider à détecter une saturation de serveur, des troubles réseau,
|
|
des épuisements de ressources système locales, des attaques, etc...
|
|
|
|
Les combinaisons d'indicateurs les plus fréquentes sont énumérées ici.
|
|
|
|
Indic Raison
|
|
CR Le client a abandonné avant d'émettre une requête complète. Il est
|
|
très probable que la requête ait été tapée à la main dans un client
|
|
telnet et abortée trop tôt.
|
|
|
|
cR Le temps imparti au client a expiré avant réception d'une requête
|
|
complète. Ceci est parfois causé par un paramètre TCP MSS trop élevé
|
|
sur le client pour des réseaux PPPoE sur ADSL qui ne peuvent pas
|
|
transporter des paquets entiers, ou par des clients qui énvoient des
|
|
requêtes à la main et ne tapent pas assez vite.
|
|
|
|
SC Le serveur a explicitement refusé la connexion (le proxy a reçu un
|
|
RST TCP ou un message ICMP en retour). Dans certains cas, cela peut
|
|
être la couche réseau qui indique au proxy que le serveur n'est pas
|
|
joignable (p.ex: pas de route, pas de réponse ARP en local, etc...)
|
|
|
|
sC La connexion au serveur n'a pas pu s'établir dans le temps imparti.
|
|
|
|
PC Le proxy a refusé d'établir une connexion au serveur parce que le
|
|
nombre de connexions a atteint la limite 'maxconn' (global ou de
|
|
l'instance). Le paramètre 'maxconn' de l'instance pourrait être
|
|
augmenté, tout comme le paramètre 'maxconn' global.
|
|
|
|
RC Une ressource locale a été épuisée (mémoire, sockets, ports source),
|
|
empêchant la connexion au serveur de s'établir. Les logs d'erreurs
|
|
diront précisément ce qui manquait. Dans tous les cas, le seul remède
|
|
consiste à affiner le paramétrage système.
|
|
|
|
cH Le temps imparti au client a expiré au cours d'une requête POST. Ceci
|
|
est parfois causé par un paramètre TCP MSS trop élevé sur le client
|
|
pour des réseaux PPPoE sur ADSL qui ne peuvent pas transporter des
|
|
paquets entiers.
|
|
|
|
CH Le client a abandonné alors qu'il attendait un début de réponse de la
|
|
part du serveur. Cela peut être causé par le serveur qui mettait trop
|
|
de temps à répondre, ou par un client cliquant précipitamment sur le
|
|
bouton 'Stop'.
|
|
|
|
CQ Le client a abandonné alors que sa session était mise en file
|
|
d'attente pour obtenir un serveur avec suffisamment de connexions
|
|
libres pour l'accepter. Cela signifie soit que l'ensemble des
|
|
serveurs étaient saturés, soit que le serveur assigné a mis trop de
|
|
temps à répondre.
|
|
|
|
CT Le client a abandonné alors que sa session était bloquée en mode
|
|
tarpit.
|
|
|
|
sQ La session a attendu trop longtemps en file d'attente et a été
|
|
expirée.
|
|
|
|
SH Le serveur a aborté brutalement alors qu'il devait envoyer ses
|
|
en-têtes. En général, cela indique qu'il a crashé.
|
|
|
|
sH Le serveur n'a pas pu répondre durant le temps imparti, ce qui montre
|
|
des transactions trop longues, probablement causées par un back-end
|
|
saturé. Les seules solutions sont de corriger le problème sur
|
|
l'application, d'accroître le paramètre 'srvtimeout' pour supporter
|
|
des attentes plus longues au risque que les clients abandonnent à
|
|
leur tour, ou bien d'ajouter des serveurs.
|
|
|
|
PR Le proxy a bloqué une requête du client, soit à cause d'une syntaxe
|
|
HTTP invalide, auquel cas il a renvoyé une erreur HTTP 400 au client,
|
|
soit à cause d'une requête validant un filtre d'interdiction, auquel
|
|
cas le proxy a renvoyé une erreur HTTP 403.
|
|
|
|
PH Le proxy a bloqué la réponse du serveur parce qu'elle était invalide,
|
|
incomplète, dangereuse ('cache control'), ou parce qu'elle validait
|
|
un filtre de sécurité. Dans tous les cas, une erreur HTTP 502 est
|
|
renvoyée au client.
|
|
|
|
PT Le proxy a bloqué une requête du client et a maintenu sa connection
|
|
ouverte avant de lui retourner une erreur "500 server error". Rien
|
|
n'a été envoyé au serveur.
|
|
|
|
cD Le client n'a pas lu de données pendant le temps qui lui était
|
|
imparti. Ceci est souvent causé par des problèmes réseau côté client.
|
|
|
|
CD Le client a aborté sa connection de manière inattendue pendant le
|
|
transfert des données. Ceci est provoqué soit par le crash d'un
|
|
navigateur, ou par une session en HTTP keep-alive entre le serveur
|
|
et le client terminée en premier par le client.
|
|
|
|
sD Le serveur n'a rien fait durant le temps imparti par le paramètre
|
|
'srvtimeout'. Ceci est souvent causé par des timeouts trop courts
|
|
sur des équipements de niveau 4 (firewalls, répartiteurs de charge)
|
|
situés entre le proxy et le serveur.
|
|
|
|
4.2.5) Caractères non-imprimables
|
|
---------------------------------
|
|
Depuis la version 1.1.29, les caractères non-imprimables ne sont plus envoyés
|
|
tels quels dans les lignes de logs, mais inscrits sous la forme de deux chiffres
|
|
hexadécimaux, préfixés du caractère d'échappement '#'. Les seuls caractères
|
|
dorénavant logués tels quels sont compris entre 32 et 126. Bien évidemment, le
|
|
caractère d'échappement '#' est lui-même encodé afin de lever l'ambiguité. Il en
|
|
est de même pour le caractère '"', ainsi que les caractères '{', '|' et '}' pour
|
|
les en-têtes.
|
|
|
|
4.2.6) Capture d'en-têtes HTTP et de cookies
|
|
--------------------------------------------
|
|
La version 1.1.23 a apporté la capture des cookies, et la version 1.1.29 la
|
|
capture d'en-têtes. Tout ceci est effectué en utilisant le mot-clé 'capture'.
|
|
|
|
Les captures de cookies facilitent le suivi et la reconstitution d'une session
|
|
utilisateur. La syntaxe est la suivante :
|
|
|
|
capture cookie <préfixe_cookie> len <longueur_capture>
|
|
|
|
Ceci activera la capture de cookies à la fois dans les requêtes et dans les
|
|
réponses. De cette manière, il devient facile de détecter lorsqu'un utilisateur
|
|
bascule sur une nouvelle session par exemple, car le serveur lui réassignera un
|
|
nouveau cookie.
|
|
|
|
Le premier cookie dont le nom commencera par <préfixe_cookie> sera capturé, et
|
|
transmis sous la forme "NOM=valeur", sans toutefois, excéder <longueur_capture>
|
|
caractères (64 au maximum). Lorsque le nom du cookie est fixe et connu, on peut
|
|
le suffixer du signe "=" pour s'assurer qu'aucun autre cookie ne prendra sa
|
|
place dans les logs.
|
|
|
|
Exemples :
|
|
----------
|
|
# capture du premier cookie dont le nom commence par "ASPSESSION"
|
|
capture cookie ASPSESSION len 32
|
|
|
|
# capture du premier cookie dont le nom est exactement "vgnvisitor"
|
|
capture cookie vgnvisitor= len 32
|
|
|
|
Dans les logs, le champ précédant l'indicateur de complétude contient le cookie
|
|
positionné par le serveur, précédé du cookie positionné par le client. Chacun
|
|
de ces champs est remplacé par le signe "-" lorsqu'aucun cookie n'est fourni
|
|
par le client ou le serveur, ou lorsque l'option est désactivée..
|
|
|
|
Les captures d'en-têtes ont un rôle complètement différent. Elles sont utiles
|
|
pour suivre un identifiant de requête globalement unique positionné par un
|
|
autre proxy en amont, pour journaliser les noms de serveurs virtuels, les types
|
|
de clients web, la longueur des POST, les 'referrers', etc. Dans la réponse, on
|
|
peut chercher des informations relatives à la longueur annoncée de la réponse,
|
|
le fonctionnement attendu du cache, ou encore la localisation d'un objet en cas
|
|
de redirection. Tout comme pour les captures de cookies, il est possible
|
|
d'inclure les en-têtes de requêtes et de réponse simultanément. La syntaxe est
|
|
la suivante :
|
|
|
|
capture request header <nom> len <longueur max>
|
|
capture response header <nom> len <longueur max>
|
|
|
|
Note: Les noms d'en-têtes ne sont pas sensibles à la casse.
|
|
|
|
Exemples:
|
|
---------
|
|
# conserver le nom du serveur virtuel accédé par le client
|
|
capture request header Host len 20
|
|
# noter la longueur des données envoyées dans un POST
|
|
capture request header Content-Length len 10
|
|
|
|
# noter le fonctionnement attendu du cache par le serveur
|
|
capture response header Cache-Control len 8
|
|
# noter l'URL de redirection
|
|
capture response header Location len 20
|
|
|
|
Les en-têtes non trouvés sont logués à vide, et si un en-tête apparait plusieurs
|
|
fois, seule la dernière occurence sera conservée. Les en-têtes de requête sont
|
|
regroupés entre deux accolades '{' et '}' dans l'ordre de leur déclaration, et
|
|
chacun séparés par une barre verticale '|', sans aucun espace. Les en-têtes de
|
|
réponse sont présentés de la même manière, mais après un espace suivant le bloc
|
|
d'en-tête de requête. Le tout précède la requête HTTP. Exemple :
|
|
|
|
Config:
|
|
|
|
capture request header Host len 20
|
|
capture request header Content-Length len 10
|
|
capture request header Referer len 20
|
|
capture response header Server len 20
|
|
capture response header Content-Length len 10
|
|
capture response header Cache-Control len 8
|
|
capture response header Via len 20
|
|
capture response header Location len 20
|
|
|
|
Log :
|
|
|
|
Aug 9 20:26:09 localhost haproxy[2022]: 127.0.0.1:34014 [09/Aug/2004:20:26:09] relais-http netcache 0/0/0/162/+162 200 +350 - - ---- 0/0/0 0/0 {fr.adserver.yahoo.co||http://fr.f416.mail.} {|864|private||} "GET http://fr.adserver.yahoo.com/"
|
|
Aug 9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34020 [09/Aug/2004:20:30:46] relais-http netcache 0/0/0/182/+182 200 +279 - - ---- 0/0/0 0/0 {w.ods.org||} {Formilux/0.1.8|3495|||} "GET http://w.ods.org/sytadin.html HTTP/1.1"
|
|
Aug 9 20:30:46 localhost haproxy[2022]: 127.0.0.1:34028 [09/Aug/2004:20:30:46] relais-http netcache 0/0/2/126/+128 200 +223 - - ---- 0/0/0 0/0 {www.infotrafic.com||http://w.ods.org/syt} {Apache/2.0.40 (Red H|9068|||} "GET http://www.infotrafic.com/images/live/cartesidf/grandes/idf_ne.png HTTP/1.1"
|
|
|
|
4.2.7) Exemples de logs
|
|
-----------------------
|
|
- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/0/7/147/6723 200 243 - - ---- 1/3/5 0/0"HEAD / HTTP/1.0"
|
|
=> requête longue (6.5s) saisie à la main avec un client telnet. Le serveur a
|
|
répondu en 147 ms et la session s'est terminée normalement ('----')
|
|
|
|
- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/1230/7/147/6870 200 243 - - ---- 99/239/324 0/9 "HEAD / HTTP/1.0"
|
|
=> Idem, mais la requête a été mise en attente dans la file globale derrière
|
|
9 autres requêtes déjà présentes, et y a attendu 1230 ms.
|
|
|
|
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/0/7/14/+30 200 +243 - - ---- 1/3/3 0/0 "GET /image.iso HTTP/1.0"
|
|
=> requête pour un long transfert. L'option 'logasap' était spécifiée donc le
|
|
log a été généré juste avant le transfert de données. Le serveur a répondu
|
|
en 14 ms, 243 octets d'en-têtes ont été transférés au client, et le temps
|
|
total entre l'accept() et le premier octet de donnée est de 30 ms.
|
|
|
|
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/0/7/14/30 502 243 - - PH-- 0/2/3 0/0 "GET /cgi-bin/bug.cgi? HTTP/1.0"
|
|
=> le proxy a bloqué une réponse du serveur soit à cause d'un filtre 'rspdeny'
|
|
ou 'rspideny', soit parce qu'il a détecté un risque de fuite sensible
|
|
d'informations risquant d'être cachées. Dans ce cas, la réponse est
|
|
remplacée par '502 bad gateway'.
|
|
|
|
- haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/-1/8490 -1 0 - - CR-- 0/2/2 0/0 ""
|
|
=> Le client n'a pas envoyé sa requête et a refermé la connexion lui-même
|
|
('C---') au bout de 8.5s, alors que le relais attendait l'en-tête ('-R--').
|
|
Aucune connexion n'a été envoyée vers le serveur.
|
|
|
|
- haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/-1/50001 408 0 - - cR-- 0/2/2 0/0 ""
|
|
=> Le client n'a pas envoyé sa requête et son time-out a expiré ('c---') au
|
|
bout de 50s, alors que le relais attendait l'en-tête ('-R--'). Aucune
|
|
connexion n'a été envoyée vers le serveur, mais le relais a tout de même
|
|
pu renvoyer un message 408 au client.
|
|
|
|
- haproxy[18989]: 127.0.0.1:34550 [15/Oct/2003:15:24:28] relais-tcp Srv1 0/5007 0 cD
|
|
=> log en mode 'tcplog'. Expiration du time-out côté client ('cD') au bout de
|
|
5s.
|
|
|
|
- haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/-1/11215 503 0 - - SC-- 115/202/205 0/0 "HEAD / HTTP/1.0"
|
|
=> La requête client met 3s à entrer (peut-être un problème réseau), et la
|
|
connexion ('SC--') vers le serveur échoue au bout de 4 tentatives de 2
|
|
secondes (retries 3 dans la conf), puis un code 503 est retourné au
|
|
client. Il y avait 115 connexions sur ce serveur, 202 connexions sur cette
|
|
instance, et 205 sur l'ensemble des instances pour ce processus. Il est
|
|
possible que le serveur ait refusé la connexion parce qu'il y en avait
|
|
déjà trop d'établies.
|
|
|
|
|
|
4.3) Modification des en-têtes HTTP
|
|
----------------------------------
|
|
En mode HTTP uniquement, il est possible de remplacer certains en-têtes dans la
|
|
requête et/ou la réponse à partir d'expressions régulières. Il est également
|
|
possible de bloquer certaines requêtes en fonction du contenu des en-têtes ou
|
|
de la requête. Une limitation cependant : les en-têtes fournis au milieu de
|
|
connexions persistentes (keep-alive) ne sont pas vus car ils sont considérés
|
|
comme faisant partie des échanges de données consécutifs à la première requête.
|
|
Les données ne sont pas affectées, ceci ne s'applique qu'aux en-têtes.
|
|
|
|
La syntaxe est :
|
|
reqadd <string> pour ajouter un en-tête dans la requête
|
|
reqrep <search> <replace> pour modifier la requête
|
|
reqirep <search> <replace> idem sans distinction majuscules/minuscules
|
|
reqdel <search> pour supprimer un en-tête dans la requête
|
|
reqidel <search> idem sans distinction majuscules/minuscules
|
|
reqallow <search> autoriser la requête si un en-tête valide <search>
|
|
reqiallow <search> idem sans distinction majuscules/minuscules
|
|
reqdeny <search> interdire la requête si un en-tête valide <search>
|
|
reqideny <search> idem sans distinction majuscules/minuscules
|
|
reqpass <search> inhibe ces actions sur les en-têtes validant <search>
|
|
reqipass <search> idem sans distinction majuscules/minuscules
|
|
reqtarpit <search> bloquer et maintenir une request validant <search>
|
|
reqitarpit <search> idem sans distinction majuscules/minuscules
|
|
|
|
rspadd <string> pour ajouter un en-tête dans la réponse
|
|
rsprep <search> <replace> pour modifier la réponse
|
|
rspirep <search> <replace> idem sans distinction majuscules/minuscules
|
|
rspdel <search> pour supprimer un en-tête dans la réponse
|
|
rspidel <search> idem sans distinction majuscules/minuscules
|
|
rspdeny <search> remplace la réponse par un HTTP 502 si un
|
|
en-tête valide <search>
|
|
rspideny <search> idem sans distinction majuscules/minuscules
|
|
|
|
|
|
<search> est une expression régulière compatible POSIX regexp supportant le
|
|
groupage par parenthèses (sans les '\'). Les espaces et autres séparateurs
|
|
doivent êtres précédés d'un '\' pour ne pas être confondus avec la fin de la
|
|
chaîne. De plus, certains caractères spéciaux peuvent être précédés d'un
|
|
backslach ('\') :
|
|
|
|
\t pour une tabulation
|
|
\r pour un retour charriot
|
|
\n pour un saut de ligne
|
|
\ pour différencier un espace d'un séparateur
|
|
\# pour différencier un dièse d'un commentaire
|
|
\\ pour utiliser un backslash dans la regex
|
|
\\\\ pour utiliser un backslash dans le texte
|
|
\xXX pour un caractère spécifique XX (comme en C)
|
|
|
|
|
|
<replace> contient la chaîne remplaçant la portion vérifiée par l'expression.
|
|
Elle peut inclure les caractères spéciaux ci-dessus, faire référence à un
|
|
groupe délimité par des parenthèses dans l'expression régulière, par sa
|
|
position numérale. Les positions vont de 0 à 9, et sont codées par un '\'
|
|
suivi du chiffre désiré (0 désignant la ligne complète). Il est également
|
|
possible d'insérer un caractère non imprimable (utile pour le saut de ligne)
|
|
inscrivant '\x' suivi du code hexadécimal de ce caractère (comme en C).
|
|
|
|
<string> représente une chaîne qui sera ajoutée systématiquement après la
|
|
dernière ligne d'en-tête.
|
|
|
|
Remarques :
|
|
-----------
|
|
- la première ligne de la requête et celle de la réponse sont traitées comme
|
|
des en-têtes, ce qui permet de réécrire des URL et des codes d'erreur.
|
|
- 'reqrep' est l'équivalent de 'cliexp' en version 1.0, et 'rsprep' celui de
|
|
'srvexp'. Ces noms sont toujours supportés mais déconseillés.
|
|
- pour des raisons de performances, le nombre total de caractères ajoutés sur
|
|
une requête ou une réponse est limité à 4096 depuis la version 1.1.5 (cette
|
|
limite était à 256 auparavant). Cette valeur est modifiable dans le code.
|
|
Pour un usage temporaire, on peut gagner de la place en supprimant quelques
|
|
en-têtes inutiles avant les ajouts.
|
|
- une requête bloquée produira une réponse "HTTP 403 forbidden" tandis qu'une
|
|
réponse bloquée produira une réponse "HTTP 502 Bad gateway".
|
|
- une requête bloquée par 'reqtarpit' sera maintenue pendant une durée égale
|
|
au paramètre 'contimeout', ou jusqu'à l'abandon du client. Rien ne sera
|
|
envoyé au serveur. Lorsque le temps alloué expire, le proxy répondra avec
|
|
une réponse "500 server error" de sorte que l'attaquant ne suspecte pas
|
|
qu'il ait été bloqué. Les logs rapporteront aussi ce code 500, mais les
|
|
flags de terminaison indiqueront "PT".
|
|
|
|
Exemples :
|
|
----------
|
|
###### a few examples ######
|
|
|
|
# rewrite 'online.fr' instead of 'free.fr' for GET and POST requests
|
|
reqrep ^(GET\ .*)(.free.fr)(.*) \1.online.fr\3
|
|
reqrep ^(POST\ .*)(.free.fr)(.*) \1.online.fr\3
|
|
|
|
# force proxy connections to close
|
|
reqirep ^Proxy-Connection:.* Proxy-Connection:\ close
|
|
# rewrite locations
|
|
rspirep ^(Location:\ )([^:]*://[^/]*)(.*) \1\3
|
|
|
|
###### A full configuration being used on production ######
|
|
|
|
# Every header should end with a colon followed by one space.
|
|
reqideny ^[^:\ ]*[\ ]*$
|
|
|
|
# block Apache chunk exploit
|
|
reqideny ^Transfer-Encoding:[\ ]*chunked
|
|
reqideny ^Host:\ apache-
|
|
|
|
# block annoying worms that fill the logs...
|
|
reqideny ^[^:\ ]*\ .*(\.|%2e)(\.|%2e)(%2f|%5c|/|\\\\)
|
|
reqideny ^[^:\ ]*\ ([^\ ]*\ [^\ ]*\ |.*%00)
|
|
reqideny ^[^:\ ]*\ .*<script
|
|
reqideny ^[^:\ ]*\ .*/(root\.exe\?|cmd\.exe\?|default\.ida\?)
|
|
|
|
# tarpit attacks on the login page.
|
|
reqtarpit ^[^:\ ]*\ .*\.php?login=[^0-9]
|
|
|
|
# allow other syntactically valid requests, and block any other method
|
|
reqipass ^(GET|POST|HEAD|OPTIONS)\ /.*\ HTTP/1\.[01]$
|
|
reqipass ^OPTIONS\ \\*\ HTTP/1\.[01]$
|
|
reqideny ^[^:\ ]*\
|
|
|
|
# force connection:close, thus disabling HTTP keep-alive
|
|
option httpclos
|
|
|
|
# change the server name
|
|
rspidel ^Server:\
|
|
rspadd Server:\ Formilux/0.1.8
|
|
|
|
|
|
De plus, l'option 'forwardfor' ajoute l'adresse IP du client dans un champ
|
|
'X-Forwarded-For' de la requête, ce qui permet à un serveur web final de
|
|
connaître l'adresse IP du client initial. Depuis la version 1.3.8, il est
|
|
possible de préciser le mot-clé "except" suivi d'une adresse ou un réseau
|
|
IP source pour lequel l'entête ne sera pas ajouté. C'est très pratique dans le
|
|
cas où un autre reverse-proxy ajoutant déjà l'entête est installé sur la même
|
|
machine ou dans une DMZ connue. Le cas le plus fréquent est lié à l'utilisation
|
|
de stunnel en local.
|
|
|
|
Enfin, l'option 'httpclose' apparue dans la version 1.1.28/1.2.1 supprime tout
|
|
en-tête de type 'Connection:' et ajoute 'Connection: close' dans les deux sens.
|
|
Ceci simplifie la désactivation du keep-alive HTTP par rapport à l'ancienne
|
|
méthode impliquant 4 règles.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
log global
|
|
option httplog
|
|
option dontlognull
|
|
option forwardfor except 127.0.0.1/8
|
|
option httpclose
|
|
|
|
Notons que certains serveurs HTTP ne referment pas nécessairement la session
|
|
TCP en fin de traitement lorsqu'ils reçoivent un entête 'Connection: close',
|
|
ce qui se traduit par des grands nombres de sessions établies et des temps
|
|
globaux très longs sur les requêtes. Pour contourner ce problème, la version
|
|
1.2.9 apporte une nouvelle option 'forceclose' qui referme la connexion sortant
|
|
vers le serveur dès qu'il commence à répondre et seulement si le tampon de
|
|
requête est vide. Attention toutefois à ne PAS utiliser cette option si des
|
|
méthodes CONNECT sont attendues entre le client et le serveur. L'option
|
|
'forceclose' implique l'option 'httpclose'.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
log global
|
|
option httplog
|
|
option dontlognull
|
|
option forwardfor
|
|
option forceclose
|
|
|
|
|
|
4.4) Répartition avec persistence
|
|
---------------------------------
|
|
La combinaison de l'insertion de cookie avec la répartition de charge interne
|
|
permet d'assurer une persistence dans les sessions HTTP d'une manière
|
|
pratiquement transparente pour les applications. Le principe est simple :
|
|
- attribuer une valeur d'un cookie à chaque serveur
|
|
- effectuer une répartition interne
|
|
- insérer un cookie dans les réponses issues d'une répartition uniquement,
|
|
et faire en sorte que des caches ne mémorisent pas ce cookie.
|
|
- cacher ce cookie à l'application lors des requêtes ultérieures.
|
|
|
|
Exemple :
|
|
---------
|
|
listen application 0.0.0.0:80
|
|
mode http
|
|
cookie SERVERID insert nocache indirect
|
|
balance roundrobin
|
|
server srv1 192.168.1.1:80 cookie server01 check
|
|
server srv2 192.168.1.2:80 cookie server02 check
|
|
|
|
L'autre solution apportée par les versions 1.1.30 et 1.2.3 est de réutiliser un
|
|
cookie en provenance du serveur et de lui préfixer l'identifiant du serveur.
|
|
Dans ce cas, ne pas oublier de forcer le mode "httpclose" pour empêcher le
|
|
client et le serveur de travailler en mode "keep-alive" afin que le proxy
|
|
puisse corriger le nom du cookie dans toutes les futures requêtes.
|
|
|
|
listen application 0.0.0.0:80
|
|
mode http
|
|
cookie JSESSIONID prefix
|
|
balance roundrobin
|
|
server srv1 192.168.1.1:80 cookie srv1 check
|
|
server srv2 192.168.1.2:80 cookie srv2 check
|
|
option httpclose
|
|
|
|
|
|
4.5) Protection contre les fuites d'informations du serveur
|
|
-----------------------------------------------------------
|
|
Dans les versions 1.1.28 et 1.2.1, une nouvelle option 'checkcache' a été
|
|
créée. Elle sert à inspecter minutieusement les en-têtes 'Cache-control',
|
|
'Pragma', et 'Set-cookie' dans les réponses serveur pour déterminer s'il y a
|
|
un risque de cacher un cookie sur un proxy côté client. Quand cette option est
|
|
activée, les seules réponses qui peuvent être retournées au client sont :
|
|
- toutes celles qui n'ont pas d'en-tête 'Set-cookie' ;
|
|
- toutes celles qui ont un code de retour autre que 200, 203, 206, 300, 301,
|
|
410, sauf si le serveur a positionné un en-tête 'Cache-control: public' ;
|
|
- celles qui font suite à une requête POST, sauf si le serveur a positionné
|
|
un en-tête 'Cache-control: public' ;
|
|
- celles qui ont un en-tête 'Pragma: no-cache' ;
|
|
- celles qui ont un en-tête 'Cache-control: private' ;
|
|
- celles qui ont un en-tête 'Cache-control: no-store' ;
|
|
- celles qui ont un en-tête 'Cache-control: max-age=0' ;
|
|
- celles qui ont un en-tête 'Cache-control: s-maxage=0' ;
|
|
- celles qui ont un en-tête 'Cache-control: no-cache' ;
|
|
- celles qui ont un en-tête 'Cache-control: no-cache="set-cookie"' ;
|
|
- celles qui ont un en-tête 'Cache-control: no-cache="set-cookie,'
|
|
(autorisant d'autres champs après set-cookie).
|
|
|
|
Si une réponse ne respecte pas ces pré-requis, alors elle sera bloquée de la
|
|
même manière que s'il s'agissait d'un filtre 'rspdeny', avec en retour un
|
|
message "HTTP 502 bad gateway". L'état de session montre "PH--" ce qui veut
|
|
dire que c'est le proxy qui a bloqué la réponse durant le traitement des
|
|
en-têtes. De plus, un message d'alerte sera envoyé dans les logs de sorte que
|
|
l'administrateur sache qu'il y a une action correctrice à entreprendre.
|
|
|
|
4.6) Personalisation des erreurs
|
|
--------------------------------
|
|
Certaines situations conduisent à retourner une erreur HTTP au client :
|
|
- requête invalide ou trop longue => code HTTP 400
|
|
- requête mettant trop de temps à venir => code HTTP 408
|
|
- requête interdite (bloquée par un reqideny) => code HTTP 403
|
|
- erreur interne du proxy => code HTTP 500
|
|
- le serveur a retourné une réponse incomplète ou invalide => code HTTP 502
|
|
- aucun serveur disponible pour cette requête => code HTTP 503
|
|
- le serveur n'a pas répondu dans le temps imparti => code HTTP 504
|
|
|
|
Un message d'erreur succint tiré de la RFC accompagne ces codes de retour.
|
|
Cependant, en fonction du type de clientèle, on peut préférer retourner des
|
|
pages personnalisées. Ceci est possible de deux manières, l'une reposant sur
|
|
une redirection vers un serveur connu, et l'autre consistant à retourner un
|
|
fichier local.
|
|
|
|
4.6.1) Redirection
|
|
------------------
|
|
Une redirection d'erreur est assurée par le biais de la commande "errorloc" :
|
|
|
|
errorloc <code_HTTP> <location>
|
|
|
|
Au lieu de générer une erreur HTTP <code_HTTP> parmi les codes cités ci-dessus,
|
|
le proxy génèrera un code de redirection temporaire (HTTP 302) vers l'adresse
|
|
d'une page précisée dans <location>. Cette adresse peut être relative au site,
|
|
ou absolue. Comme cette réponse est traîtée par le navigateur du client
|
|
lui-même, il est indispensable que l'adresse fournie lui soit accessible.
|
|
|
|
Exemple :
|
|
---------
|
|
listen application 0.0.0.0:80
|
|
errorloc 400 /badrequest.html
|
|
errorloc 403 /forbidden.html
|
|
errorloc 408 /toolong.html
|
|
errorloc 500 http://haproxy.domain.net/bugreport.html
|
|
errorloc 502 http://192.168.114.58/error50x.html
|
|
errorloc 503 http://192.168.114.58/error50x.html
|
|
errorloc 504 http://192.168.114.58/error50x.html
|
|
|
|
Note: la RFC2616 stipule qu'un client doit réutiliser la même méthode pour
|
|
accéder à l'URL de redirection que celle qui l'a retournée, ce qui pose des
|
|
problèmes avec les requêtes POST. Le code de retour 303 a été créé exprès pour
|
|
régler ce problème, indiquant au client qu'il doit accéder à l'URL retournée
|
|
dans le champ Location avec la méthode GET uniquement. Seulement, certains
|
|
navigateurs antérieurs à HTTP/1.1 ne connaissent pas ce code de retour. De
|
|
plus, la plupart des navigateurs se comportent déjà avec le code 302 comme ils
|
|
devraient le faire avec le 303. Donc, dans le but de laisser le choix à
|
|
l'utilisateur, les versions 1.1.31 et 1.2.5 apportent deux nouvelles commandes
|
|
visant à remplacer 'errorloc' : 'errorloc302' et 'errorloc303'.
|
|
|
|
Leur usage non ambigü est recommandé à la place de la commande 'errorloc' (qui
|
|
utilise toujours 302). Dans le doute, préférez l'utilisation de 'errorloc303'
|
|
dès que vous savez que vos clients supportent le code de retour HTTP 303.
|
|
|
|
4.6.2) Fichiers locaux
|
|
----------------------
|
|
Parfois il est souhaitable de changer l'erreur retournée sans recourir à des
|
|
redirections. La seconde méthode consiste à charger des fichiers locaux lors
|
|
du démarrage et à les envoyer en guise de pur contenu HTTP en cas d'erreur.
|
|
C'est ce que fait le mot clé 'errorfile'.
|
|
|
|
Attention, il y a des pièges à prendre en compte :
|
|
- les fichiers sont chargés durant l'analyse de la configuration, avant de
|
|
faire le chroot(). Donc ils sont relatifs au système de fichiers réel. Pour
|
|
cette raison, il est recommandé de toujours passer un chemin absolu vers ces
|
|
fichiers.
|
|
|
|
- le contenu de ces fichiers n'est pas du HTML mais vraiment du protocole HTTP
|
|
avec potentiellement un corps HTML. Donc la première ligne et les en-têtes
|
|
sont obligatoires. Idéalement, chaque ligne dans la partie HTTP devrait se
|
|
terminer par un CR-LF pour un maximum de compatibilité.
|
|
|
|
- les réponses sont limitées à une taille de buffer (BUFSIZE), généralement 8
|
|
ou 16 ko.
|
|
|
|
- les réponses ne devraient pas inclure de références aux serveurs locaux,
|
|
afin de ne pas risquer de créer des boucles infinies sur le navigateur dans
|
|
le cas d'une panne locale.
|
|
|
|
Exemple :
|
|
---------
|
|
errorfile 400 /etc/haproxy/errorfiles/400badreq.http
|
|
errorfile 403 /etc/haproxy/errorfiles/403forbid.http
|
|
errorfile 503 /etc/haproxy/errorfiles/503sorry.http
|
|
|
|
|
|
4.7) Changement des valeurs par défaut
|
|
--------------------------------------
|
|
Dans la version 1.1.22 est apparue la notion de valeurs par défaut, ce qui
|
|
évite de répéter des paramètres communs à toutes les instances, tels que les
|
|
timeouts, adresses de log, modes de fonctionnement, etc.
|
|
|
|
Les valeurs par défaut sont positionnées dans la dernière section 'defaults'
|
|
précédent l'instance qui les utilisera. On peut donc mettre autant de sections
|
|
'defaults' que l'on veut. Il faut juste se rappeler que la présence d'une telle
|
|
section implique une annulation de tous les paramètres par défaut positionnés
|
|
précédemment, dans le but de les remplacer.
|
|
|
|
La section 'defaults' utilise la même syntaxe que la section 'listen', aux
|
|
paramètres près qui ne sont pas supportés. Le mot clé 'defaults' peut accepter
|
|
un commentaire en guise paramètre.
|
|
|
|
Dans la version 1.1.28/1.2.1, seuls les paramètres suivants peuvent être
|
|
positionnés dans une section 'defaults' :
|
|
- log (le premier et le second)
|
|
- mode { tcp, http, health }
|
|
- balance { roundrobin }
|
|
- disabled (pour désactiver toutes les instances qui suivent)
|
|
- enabled (pour faire l'opération inverse, mais c'est le cas par défaut)
|
|
- contimeout, clitimeout, srvtimeout, grace, retries, maxconn
|
|
- option { redispatch, transparent, keepalive, forwardfor, logasap, httpclose,
|
|
checkcache, httplog, tcplog, dontlognull, persist, httpchk }
|
|
- redispatch, redisp, transparent, source { addr:port }
|
|
- cookie, capture
|
|
- errorloc
|
|
|
|
Ne sont pas supportés dans cette version, les adresses de dispatch et les
|
|
configurations de serveurs, ainsi que tous les filtres basés sur les
|
|
expressions régulières :
|
|
- dispatch, server,
|
|
- req*, rsp*
|
|
|
|
Enfin, il n'y a pas le moyen, pour le moment, d'invalider un paramètre booléen
|
|
positionné par défaut. Donc si une option est spécifiée dans les paramètres par
|
|
défaut, le seul moyen de la désactiver pour une instance, c'est de changer les
|
|
paramètres par défaut avant la déclaration de l'instance.
|
|
|
|
Exemples :
|
|
----------
|
|
defaults applications TCP
|
|
log global
|
|
mode tcp
|
|
balance roundrobin
|
|
clitimeout 180000
|
|
srvtimeout 180000
|
|
contimeout 4000
|
|
retries 3
|
|
redispatch
|
|
|
|
listen app_tcp1 10.0.0.1:6000-6063
|
|
server srv1 192.168.1.1 check port 6000 inter 10000
|
|
server srv2 192.168.1.2 backup
|
|
|
|
listen app_tcp2 10.0.0.2:6000-6063
|
|
server srv1 192.168.2.1 check port 6000 inter 10000
|
|
server srv2 192.168.2.2 backup
|
|
|
|
defaults applications HTTP
|
|
log global
|
|
mode http
|
|
option httplog
|
|
option forwardfor
|
|
option dontlognull
|
|
balance roundrobin
|
|
clitimeout 20000
|
|
srvtimeout 20000
|
|
contimeout 4000
|
|
retries 3
|
|
|
|
listen app_http1 10.0.0.1:80-81
|
|
cookie SERVERID postonly insert indirect
|
|
capture cookie userid= len 10
|
|
server srv1 192.168.1.1:+8000 cookie srv1 check port 8080 inter 1000
|
|
server srv1 192.168.1.2:+8000 cookie srv2 check port 8080 inter 1000
|
|
|
|
defaults
|
|
# section vide qui annule tous les paramètes par défaut.
|
|
|
|
|
|
4.8) Rapport d'état sous forme de page HTML
|
|
-------------------------------------------
|
|
Avec la version 1.2.14, il devient possible pour haproxy d'interceptre des
|
|
requêtes pour une URI particulière et de retourner un rapport complet d'état de
|
|
l'activité du proxy, et des statistiques sur les serveurs. Ceci est disponible
|
|
via le mot clé "stats" associé à n'importe laquelle de ces options :
|
|
|
|
- stats enable
|
|
- stats uri <uri prefix>
|
|
- stats realm <authentication realm>
|
|
- stats auth <user:password>
|
|
- stats scope <proxy_id> | '.'
|
|
|
|
|
|
Par défaut, le rapport est désactivé. Le fait de spécifier une des combinaision
|
|
ci-dessus active le rapport pour l'instance de proxy qui le référence. La
|
|
solution la plus simple est d'utiliser "stats enable" qui activera le rapport
|
|
avec les paramètres par défaut suivant :
|
|
|
|
- default URI : "/haproxy?stats" (CONFIG_STATS_DEFAULT_URI)
|
|
- default auth : non spécifié (pas d'authentication)
|
|
- default realm : "HAProxy Statistics" (CONFIG_STATS_DEFAULT_REALM)
|
|
- default scope : non specifié (accès à toutes les instances)
|
|
|
|
L'option "stats uri <uri_prefix>" permet d'intercepter un autre préfixe d'URI
|
|
que celui par défaut. Noter que n'importe quelle URI qui COMMENCE avec cette
|
|
chaîne sera validée. Par exemple, une instance pourrait être dédiée à la page
|
|
d'état seulement et répondre à toute URI.
|
|
|
|
Example :
|
|
---------
|
|
# intercepte n'importe quelle URI et retourne la page d'état.
|
|
listen stats :8080
|
|
mode http
|
|
stats uri /
|
|
|
|
|
|
L'option "stats auth <user:password>" active l'authentification "Basic" et
|
|
ajoute un couple "user:password" valide à la liste des comptes autorisés.
|
|
L'utilisateur <user> et le mot de passe <password> doivent être précisés
|
|
en clair dans le fichier de configuration, et comme ceci est de
|
|
l'authentification HTTP "Basic", il faut être conscient qu'ils transitent en
|
|
clair sur le réseau, donc il ne faut pas utiliser de compte sensible. La liste
|
|
est illimitée dans le but de pouvoir fournir des accès facilement à des
|
|
développeurs ou à des clients.
|
|
|
|
L'option "stats realm <realm>" définit le "domaine" ("realm") de validité du
|
|
mot de passe qui sera présenté dans la boîte de dialogue du navigateur
|
|
lorsqu'il demandera un compte utilisateur et un mot de passe. Il est important
|
|
de s'assurer que celui-ci soit différent de ceux utilisés par l'application,
|
|
autrement le navigateur tentera d'en utiliser un caché depuis l'application.
|
|
Noter que les espaces dans le nom de "realm" doivent être protégés par un
|
|
backslash ('\').
|
|
|
|
L'option "stats scope <proxy_id>" limite la portée du rapport d'état. Par
|
|
défaut, toutes les instances proxy sont listées. Mais dans certaines
|
|
circonstances, il serait préférable de ne lister que certains proxies ou
|
|
simplement le proxy courant. C'est ce que fait cette option. Le nom spécial "."
|
|
(un simple point) référence le proxy courant. Cette option peut être répétée
|
|
autant de fois que nécessaire pour autoriser d'autres proxies, même pour des
|
|
noms référencés plus loin dans la configuration ou bien des noms qui n'existent
|
|
pas encore. Le nom précisé est celui qui apparait après le mot clé "listen".
|
|
|
|
Exemple :
|
|
---------
|
|
# simple application embarquant la page d'état authentifiée
|
|
listen app1 192.168.1.100:80
|
|
mode http
|
|
option httpclose
|
|
balance roundrobin
|
|
cookie SERVERID postonly insert indirect
|
|
server srv1 192.168.1.1:8080 cookie srv1 check inter 1000
|
|
server srv1 192.168.1.2:8080 cookie srv2 check inter 1000
|
|
stats uri /my_stats
|
|
stats realm Statistics\ for\ MyApp1-2
|
|
stats auth guest:guest
|
|
stats auth admin:AdMiN123
|
|
stats scope .
|
|
stats scope app2
|
|
|
|
# simple application embarquant la page d'état sans authentification
|
|
listen app2 192.168.2.100:80
|
|
mode http
|
|
option httpclose
|
|
balance roundrobin
|
|
cookie SERVERID postonly insert indirect
|
|
server srv1 192.168.2.1:8080 cookie srv1 check inter 1000
|
|
server srv1 192.168.2.2:8080 cookie srv2 check inter 1000
|
|
stats uri /my_stats
|
|
stats realm Statistics\ for\ MyApp2
|
|
stats scope .
|
|
|
|
listen admin_page :8080
|
|
mode http
|
|
stats uri /my_stats
|
|
stats realm Global\ statistics
|
|
stats auth admin:AdMiN123
|
|
|
|
Notes :
|
|
-------
|
|
- les options "stats" peuvent aussi être spécifiées dans une section
|
|
"defaults", auquel cas la même configuration exactement sera fournie à
|
|
toutes les instances suivantes, d'où l'utilité du scope ".". Toutefois, si
|
|
une instance redéfinit n'importe quel paramètre "stats", alors les défauts
|
|
ne lui seront pas appliqués.
|
|
|
|
- l'authentification "Basic" est très simpliste et non sécurisée contre la
|
|
capture réseau. Aucun mot de passe sensible ne doit être utilisé, et il
|
|
est bon de savoir qu'il n'existe pas de moyen de le supprimer du navigateur
|
|
après usage, donc il sera envoyé tel quel à l'application au cours des
|
|
accès successifs.
|
|
|
|
- Il est très important de préciser l'option "httpclose", sinon le proxy ne
|
|
sera pas en mesure de détecter les URI dans les sessions keep-alive
|
|
maintenues entre le navigateur et les serveurs, donc les URI de stats
|
|
seront transmises telles quelles aux serveurs comme si l'option n'était
|
|
pas précisée.
|
|
|
|
|
|
5) Listes d'accès
|
|
=================
|
|
|
|
Avec la version 1.3.10, un nouveau concept de listes d'accès (ACL) a vu le
|
|
jour. Comme il n'était pas nécessaire de réinventer la roue, et du fait que
|
|
toutes les réflexions passées aboutissaient à des propositions non
|
|
satisfaisantes, il a finalement été décidé que quelque chose de proche de ce
|
|
que Squid offre serait un bon compromis entre une richesse fonctionnelle et une
|
|
facilité d'utilisation
|
|
|
|
Le principe est très simple : les ACLs sont déclarées avec un nom, un test et
|
|
une liste de valeurs valides à tester. Des conditions sont appliquées sur
|
|
diverses actions, et ces conditions effectuent un ET logique entre les ACLs. La
|
|
condition n'est donc validée que si toutes les ACLs sont vraies.
|
|
|
|
Il est également possible d'utiliser le mot réservé "OR" dans les conditions,
|
|
et il est possible pour une ACL d'être spécifiée plusieurs fois, même avec des
|
|
tests différents, auquel cas le premier test réussi validera l'ACL.
|
|
|
|
Au stade de la version 1.3.12, seuls les tests suivants ont été implémentés :
|
|
|
|
Niveaux 3/4 :
|
|
src <ipv4_address>[/mask] ... : match IPv4 source address
|
|
dst <ipv4_address>[/mask] ... : match IPv4 destination address
|
|
src_port <range> ... : match source port range
|
|
dst_port <range> ... : match destination port range
|
|
dst_conn <range> ... : match #connections on frontend
|
|
|
|
Niveau 7 :
|
|
method <HTTP method> ... : match HTTP method
|
|
req_ver <1.0|1.1> ... : match HTTP request version
|
|
resp_ver <1.0|1.1> ... : match HTTP response version
|
|
status <range> ... : match HTTP response status code in range
|
|
url <string> ... : exact string match on URI
|
|
url_reg <regex> ... : regex string match on URI
|
|
url_beg <string> ... : true if URI begins with <string>
|
|
url_end <string> ... : true if URI ends with <string>
|
|
url_sub <string> ... : true if URI contains <string>
|
|
url_dir <string> ... : true if URI contains <string> between slashes
|
|
url_dom <string> ... : true if URI contains <string> between slashes or dots
|
|
|
|
Une plage ('range') est constituée d'un ou deux entiers qui peuvent être
|
|
préfixés d'un opérateur. La syntaxe est :
|
|
|
|
[<op>] <min>[:<max>]
|
|
|
|
Avec <op> pouvant être :
|
|
'eq' : la valeur doit égaler <min> ou être comprise entre <min> et <max>
|
|
'le' : la valeur doit être inférieure ou égale à <min>
|
|
'lt' : la valeur doit être strictement inférieure à <min>
|
|
'ge' : la valeur doit être supérieure ou égale à <min>
|
|
'gt' : la valeur doit être strictement supérieure à <min>
|
|
|
|
Lorsqu'aucun opérateur n'est défini, 'eq' est employé. Noter que lorsqu'un
|
|
opérateur est spécifié, il s'applique à toutes les plages de valeurs suivantes
|
|
jusqu'à la fin de la ligne ou bien jusqu'à ce qu'un nouvel opérateur soit
|
|
précisé. Exemple :
|
|
|
|
acl status_error status 400:599
|
|
acl saturated_frt dst_conn ge 1000
|
|
acl invalid_ports src_port lt 512 ge 65535
|
|
|
|
D'autres tests arrivent (entêtes, cookies, heure, authentification), c'est
|
|
juste une question de temps. Il est aussi prévu de permettre de lire les
|
|
valeurs depuis un fichier, ainsi que d'ignorer la casse pour certains tests.
|
|
|
|
La seule commande supportant les conditions d'ACL à ce jour est la nouvelle
|
|
commande "block" qui bloque une requête et retourne un statut 403 si sa
|
|
condition est validée (cas du "if") ou invalidée (cas du "unless").
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
acl options_uris url *
|
|
acl meth_option method OPTIONS
|
|
acl http_1.1 req_ver 1.1
|
|
acl allowed_meth method GET HEAD POST OPTIONS CONNECT
|
|
acl connect_meth method CONNECT
|
|
acl proxy_url url_beg http://
|
|
|
|
# block if reserved URI "*" used with a method other than "OPTIONS"
|
|
block if options_uris !meth_option
|
|
|
|
# block if the OPTIONS method is used with HTTP 1.0
|
|
block if meth_option !http_1.1
|
|
|
|
# allow non-proxy url with anything but the CONNECT method
|
|
block if !connect_meth !proxy_url
|
|
|
|
# block all unknown methods
|
|
block unless allowed_meth
|
|
|
|
Note: Cette documentation est embryonnaire mais doit permettre de démarrer et
|
|
surtout d'avancer sur le projet sans être trop ralenti par la documentation.
|
|
|
|
|
|
=======================
|
|
| Paramétrage système |
|
|
=======================
|
|
|
|
Sous Linux 2.4
|
|
==============
|
|
|
|
-- cut here --
|
|
#!/bin/sh
|
|
# set this to about 256/4M (16384 for 256M machine)
|
|
MAXFILES=16384
|
|
echo $MAXFILES > /proc/sys/fs/file-max
|
|
ulimit -n $MAXFILES
|
|
|
|
if [ -e /proc/sys/net/ipv4/ip_conntrack_max ]; then
|
|
echo 65536 > /proc/sys/net/ipv4/ip_conntrack_max
|
|
fi
|
|
|
|
if [ -e /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_fin_wait ]; then
|
|
# 30 seconds for fin, 15 for time wait
|
|
echo 3000 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_fin_wait
|
|
echo 1500 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_timeout_time_wait
|
|
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_invalid_scale
|
|
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
|
|
fi
|
|
|
|
echo 1024 60999 > /proc/sys/net/ipv4/ip_local_port_range
|
|
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
|
|
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
|
|
echo 262144 > /proc/sys/net/ipv4/tcp_max_tw_buckets
|
|
echo 262144 > /proc/sys/net/ipv4/tcp_max_orphans
|
|
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
|
|
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
|
|
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
|
|
echo 0 > /proc/sys/net/ipv4/tcp_ecn
|
|
echo 1 > /proc/sys/net/ipv4/tcp_sack
|
|
echo 0 > /proc/sys/net/ipv4/tcp_dsack
|
|
|
|
# auto-tuned on 2.4
|
|
#echo 262143 > /proc/sys/net/core/rmem_max
|
|
#echo 262143 > /proc/sys/net/core/rmem_default
|
|
|
|
echo 16384 65536 524288 > /proc/sys/net/ipv4/tcp_rmem
|
|
echo 16384 349520 699040 > /proc/sys/net/ipv4/tcp_wmem
|
|
|
|
-- cut here --
|
|
|
|
Sous FreeBSD
|
|
============
|
|
|
|
Un port de HA-Proxy sous FreeBSD est désormais disponible, grâce à
|
|
Clement Laforet <sheepkiller@cultdeadsheep.org>.
|
|
|
|
Pour plus d'informations :
|
|
http://www.freebsd.org/cgi/url.cgi?ports/net/haproxy/pkg-descr
|
|
http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/haproxy/
|
|
http://www.freshports.org/net/haproxy
|
|
|
|
|
|
-- fin --
|