mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-13 15:04:42 +00:00
eedaa9f220
* fixed a stupid bug introduced in 1.1.22 which caused second and subsequent 'default' sections to keep previous parameters, and not initialize logs correctly. * fixed a second stupid bug introduced in 1.1.22 which caused configurations relying on 'dispatch' mode to segfault at the first connection. * 'option httpchk' now supports method, HTTP version and a few headers. * now, 'option httpchk', 'cookie' and 'capture' can be specified in 'defaults' section * a fresh new english documentation * large Makefile cleanup for increased portability * new build script 'build.cfg' for Formilux-0.1.8 * new startup script 'init.haproxy.flx0' for Formilux-0.1.8
1270 lines
50 KiB
Plaintext
1270 lines
50 KiB
Plaintext
|
|
H A - P r o x y
|
|
---------------
|
|
version 1.1.23
|
|
willy tarreau
|
|
2003/09/20
|
|
|
|
================
|
|
| Introduction |
|
|
================
|
|
|
|
HA-Proxy 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 entê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.
|
|
|
|
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>
|
|
-N <nombre maximal de connexions simultanées par proxy>
|
|
-d active le mode debug
|
|
-D passe en daemon
|
|
-s affiche les statistiques (si option compilée)
|
|
-l ajoute des informations aux statistiques
|
|
|
|
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'entêtes HTTP
|
|
sont affichés.
|
|
|
|
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.
|
|
|
|
|
|
============================
|
|
| 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>
|
|
- chroot <répertoire>
|
|
- nbproc <nombre>
|
|
- daemon
|
|
- debug
|
|
- quiet
|
|
|
|
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. 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). Dans une future version, haproxy sera
|
|
capable de positionner lui-même cette limite.
|
|
|
|
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. 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: 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 :
|
|
---------
|
|
|
|
global
|
|
uid 30000
|
|
gid 30000
|
|
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.
|
|
|
|
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'.
|
|
|
|
Exemple :
|
|
---------
|
|
|
|
global
|
|
daemon
|
|
quiet
|
|
nbproc 2
|
|
|
|
|
|
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
|
|
- supervision
|
|
|
|
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 entê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. Pour activer ce mode, préciser
|
|
le mode HEALTH sous la déclaration du relais.
|
|
|
|
Exemple :
|
|
---------
|
|
listen health_check 0.0.0.0:60000
|
|
mode health
|
|
|
|
|
|
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 SIG_USR1
|
|
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. La
|
|
valeur par défaut 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
|
|
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
|
|
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 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.
|
|
|
|
- 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. En version 1.1.9,
|
|
seul 'roundrobin' est géré, et c'est aussi la valeur implicite par défaut. 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
|
|
|
|
|
|
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
|
|
|
|
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>
|
|
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. 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.
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
# 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
|
|
|
|
|
|
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.
|
|
|
|
|
|
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, et de
|
|
la réécriture des entêtes.
|
|
|
|
4.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.2) Journalisation des connexions
|
|
----------------------------------
|
|
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
|
|
|
|
Par défaut, les informations contenues dans les logs se situent au niveau TCP
|
|
uniquement. Il faut préciser l'option 'httplog' pour obtenir les détails du
|
|
protocole HTTP. 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 :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
option httplog
|
|
option dontlognull
|
|
log 192.168.2.200 local3
|
|
|
|
Depuis la version 1.1.18, un indicateur de complétude de la session a été ajouté
|
|
dans les logs HTTP. C'est un champ de 4 caractères précédant la requête HTTP,
|
|
indiquant :
|
|
- sur le premier caractère, un code précisant le premier événement qui a causé
|
|
la terminaison de la session :
|
|
|
|
C : fermeture de la session TCP de la part du client
|
|
S : fermeture de la session TCP de la part du serveur, ou refus de connexion
|
|
P : terminaison prématurée des sessions par le proxy, pour cas d'erreur
|
|
interne ou de configuration (ex: filtre d'URL)
|
|
c : expiration du délai d'attente côté client : clitimeout
|
|
s : expiration du délai d'attente côté serveur: srvtimeout et contimeout
|
|
- : terminaison normale.
|
|
|
|
- sur le second caractère, l'état d'avancement de la session HTTP lors de la
|
|
fermeture :
|
|
|
|
R : terminaison en attendant la réception totale de la requête du client
|
|
C : terminaison en attendant la connexion vers le serveur
|
|
H : terminaison en attendant la réception totale des entêtes du serveur
|
|
D : terminaison durant le transfert des données du serveur vers le client
|
|
L : terminaison durant le transfert des dernières données du proxy vers
|
|
le client, alors que le serveur a déjà fini.
|
|
- : terminaison normale, après fin de transfert des données
|
|
|
|
- le troisième caractère indique l'éventuelle identification d'un cookie de
|
|
persistence :
|
|
|
|
N : aucun cookie de persistence n'a été présenté.
|
|
I : le client a présenté un cookie ne correspondant à aucun serveur
|
|
connu.
|
|
D : le client a présenté un cookie correspondant à un serveur hors
|
|
d'usage. 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
|
|
|
|
- le dernier caractère indique l'éventuel traitement effectué sur un cookie de
|
|
persistence retrourné par le serveur :
|
|
|
|
N : aucun cookie de persistence n'a été fourni par le serveur.
|
|
P : un cookie cookie de persistence n'a été fourni par le serveur.
|
|
I : aucun cookie n'a été fourni par le serveur, il a été inséré par le
|
|
proxy.
|
|
D : le cookie présenté par le serveur a été supprimé par le proxy pour
|
|
ne pas être retourné au client.
|
|
R : le cookie retourné par le serveur a été modifié par le proxy.
|
|
- : non appliquable
|
|
|
|
Le mot clé "capture" permet d'ajouter dans des logs HTTP des informations
|
|
capturées dans les échanges. La version 1.1.17 supporte uniquement une capture
|
|
de cookies client et serveur, ce qui permet dans bien des cas, de reconstituer
|
|
la session d'un utilisateur. La syntaxe est la suivante :
|
|
|
|
capture cookie <préfixe_cookie> len <longueur_capture>
|
|
|
|
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.
|
|
|
|
Enfin, 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.
|
|
|
|
Exemple :
|
|
---------
|
|
listen http_proxy 0.0.0.0:80
|
|
mode http
|
|
log global
|
|
option httplog
|
|
option dontlognull
|
|
option forwardfor
|
|
capture cookie userid= len 20
|
|
|
|
|
|
4.3) Modification des entê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 entête valide <search>
|
|
reqiallow <search> idem sans distinction majuscules/minuscules
|
|
reqdeny <search> interdire la requête si un entête valide <search>
|
|
reqideny <search> idem sans distinction majuscules/minuscules
|
|
reqpass <search> inhibe ces actions sur les entêtes validant <search>
|
|
reqipass <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
|
|
|
|
|
|
<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 1 à 9, et sont codées par un '\'
|
|
suivi du chiffre désiré. 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
|
|
entêtes inutiles avant les ajouts.
|
|
|
|
Exemples :
|
|
--------
|
|
reqrep ^(GET.*)(.free.fr)(.*) \1.online.fr\3
|
|
reqrep ^(POST.*)(.free.fr)(.*) \1.online.fr\3
|
|
reqirep ^Proxy-Connection:.* Proxy-Connection:\ close
|
|
rspirep ^Server:.* Server:\ Tux-2.0
|
|
rspirep ^(Location:\ )([^:]*://[^/]*)(.*) \1\3
|
|
rspidel ^Connection:
|
|
rspadd Connection:\ close
|
|
|
|
|
|
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 192.168.1.1:80 cookie server01 check
|
|
server 192.168.1.2:80 cookie server02 check
|
|
|
|
4.5) 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 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
|
|
|
|
4.6) 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.22, 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, httplog,
|
|
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.
|
|
|
|
=======================
|
|
| 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 0 > /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 --
|
|
|
|
-- fin --
|