2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
H A - P r o x y
|
|
|
|
|
---------------
|
2005-12-17 23:57:06 +00:00
|
|
|
|
version 1.2.1
|
2005-12-17 11:21:26 +00:00
|
|
|
|
willy tarreau
|
2005-12-17 23:57:06 +00:00
|
|
|
|
2004/06/06
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 11:55:07 +00:00
|
|
|
|
================
|
|
|
|
|
| Introduction |
|
|
|
|
|
================
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
HA-Proxy est un relais TCP/HTTP offrant des facilit<69>s d'int<6E>gration en
|
|
|
|
|
environnement hautement disponible. En effet, il est capable de :
|
2005-12-17 12:10:27 +00:00
|
|
|
|
- effectuer un aiguillage statique d<>fini par des cookies ;
|
|
|
|
|
- effectuer une r<>partition de charge avec cr<63>ation de cookies pour assurer la
|
2005-12-17 12:08:06 +00:00
|
|
|
|
persistence de session ;
|
2005-12-17 11:21:26 +00:00
|
|
|
|
- fournir une visibilit<69> externe de son <20>tat de sant<6E> ;
|
2005-12-17 12:41:01 +00:00
|
|
|
|
- s'arr<72>ter en douceur sans perte brutale de service ;
|
|
|
|
|
- modifier/ajouter/supprimer des ent<6E>tes dans la requ<71>te et la r<>ponse ;
|
|
|
|
|
- interdire des requ<71>tes qui v<>rifient certaines conditions ;
|
|
|
|
|
- utiliser des serveurs de secours lorsque les serveurs principaux sont hors
|
|
|
|
|
d'usage.
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Il requiert peu de ressources, et son architecture <20>v<EFBFBD>nementielle mono-processus
|
|
|
|
|
lui permet facilement de g<>rer plusieurs milliers de connexions simultan<61>es sur
|
|
|
|
|
plusieurs relais sans effondrer le syst<73>me.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
===========================
|
|
|
|
|
| Param<61>tres de lancement |
|
|
|
|
|
===========================
|
|
|
|
|
|
|
|
|
|
Les options de lancement sont peu nombreuses :
|
|
|
|
|
|
|
|
|
|
-f <fichier de configuration>
|
|
|
|
|
-n <nombre maximal total de connexions simultan<61>es>
|
|
|
|
|
-N <nombre maximal de connexions simultan<61>es par proxy>
|
|
|
|
|
-d active le mode debug
|
|
|
|
|
-D passe en daemon
|
2005-12-17 23:57:06 +00:00
|
|
|
|
-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<73>cifi<66>s.
|
|
|
|
|
-c v<>rifie le fichier de configuration puis quitte avec un code de retour 0
|
|
|
|
|
si aucune erreur n'a <20>t<EFBFBD> trouv<75>e, ou 1 si une erreur de syntaxe a <20>t<EFBFBD>
|
|
|
|
|
d<>tect<63>e.
|
2005-12-17 13:14:34 +00:00
|
|
|
|
-p <fichier> indique au processus p<>re qu'il doit <20>crire les PIDs de ses
|
|
|
|
|
fils dans ce fichier en mode d<>mon.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
-s affiche les statistiques (si option compil<69>e)
|
|
|
|
|
-l ajoute des informations aux statistiques
|
|
|
|
|
|
2005-12-17 12:08:06 +00:00
|
|
|
|
Le nombre maximal de connexion simultan<61>es par proxy est le param<61>tre par d<>faut
|
|
|
|
|
pour les proxies pour lesquels ce param<61>tre n'est pas pr<70>cis<69> dans le fichier de
|
|
|
|
|
configuration. Il s'agit du param<61>tre 'maxconn' dans les sections 'listen'.
|
|
|
|
|
|
|
|
|
|
Le nombre maximal total de connexions simultan<61>es limite le nombre de connexions
|
2005-12-17 12:10:27 +00:00
|
|
|
|
TCP utilisables <20> un instant donn<6E> par le processus, tous proxies confondus. Ce
|
2005-12-17 12:08:06 +00:00
|
|
|
|
param<EFBFBD>tre remplace le param<61>tre 'maxconn' de la section 'global'.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Le mode debug correspond <20> l'option 'debug' de la section 'global'. Dans ce
|
|
|
|
|
mode, toutes les connexions, d<>connexions, et tous les <20>changes d'ent<6E>tes HTTP
|
|
|
|
|
sont affich<63>s.
|
|
|
|
|
|
|
|
|
|
Les statistiques ne sont disponibles que si le programme a <20>t<EFBFBD> compil<69> avec
|
|
|
|
|
l'option "STATTIME". Il s'agit principalement de donn<6E>es brutes n'ayant
|
|
|
|
|
d'utilit<69> que lors de benchmarks par exemple.
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
============================
|
|
|
|
|
| Fichier de configuration |
|
|
|
|
|
============================
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Structure
|
|
|
|
|
=========
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:08:06 +00:00
|
|
|
|
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
|
2005-12-17 12:10:27 +00:00
|
|
|
|
pr<EFBFBD>c<EFBFBD>d<EFBFBD> d'un '\'), et la fin de la ligne, ce qui constitue un commentaire.
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Le fichier de configuration est d<>coup<75> en sections r<>p<EFBFBD>r<EFBFBD>es par des mots cl<63>s
|
|
|
|
|
tels que :
|
|
|
|
|
|
|
|
|
|
- 'global'
|
|
|
|
|
- 'listen'
|
2005-12-17 13:02:24 +00:00
|
|
|
|
- 'defaults'
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Tous les param<61>tres font r<>f<EFBFBD>rence <20> la section d<>finie par le dernier mot cl<63>
|
|
|
|
|
reconnu.
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
1) Param<61>tres globaux
|
|
|
|
|
=====================
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Il s'agit des param<61>tres agissant sur le processus, ou bien sur l'ensemble des
|
|
|
|
|
proxies. Ils sont tous sp<73>cifi<66>s dans la section 'global'. Les param<61>tres
|
|
|
|
|
support<EFBFBD>s sont :
|
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
- log <adresse> <cat<61>gorie> [niveau_max]
|
2005-12-17 12:08:06 +00:00
|
|
|
|
- maxconn <nombre>
|
|
|
|
|
- uid <identifiant>
|
|
|
|
|
- gid <identifiant>
|
|
|
|
|
- chroot <r<>pertoire>
|
|
|
|
|
- nbproc <nombre>
|
|
|
|
|
- daemon
|
|
|
|
|
- debug
|
|
|
|
|
- quiet
|
2005-12-17 13:14:34 +00:00
|
|
|
|
- pidfile <fichier>
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
1.1) Journalisation des <20>v<EFBFBD>nements
|
|
|
|
|
----------------------------------
|
|
|
|
|
La plupart des <20>v<EFBFBD>nements sont journalis<69>s : d<>marrages, arr<72>ts, disparition et
|
|
|
|
|
apparition de serveurs, connexions, erreurs. Tous les messages sont envoy<6F>s en
|
|
|
|
|
syslog vers un ou deux serveurs. La syntaxe est la suivante :
|
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
log <adresse_ip> <cat<61>gorie> [niveau_max]
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Les connexions sont envoy<6F>es en niveau "info". Les d<>marrages de service et de
|
|
|
|
|
serveurs seront envoy<6F>s en "notice", les signaux d'arr<72>ts en "warning" et les
|
|
|
|
|
arr<EFBFBD>ts d<>finitifs de services et de serveurs en "alert". Ceci est valable aussi
|
2005-12-17 12:41:01 +00:00
|
|
|
|
bien pour les proxies que pour les serveurs test<73>s par les proxies. Le param<61>tre
|
|
|
|
|
optionnel <niveau_max> d<>finit le niveau maximal de traces <20>mises parmi les 8
|
|
|
|
|
valeurs suivantes :
|
|
|
|
|
emerg, alert, crit, err, warning, notice, info, debug
|
|
|
|
|
|
2005-12-17 13:08:03 +00:00
|
|
|
|
Par compatibilit<69> avec les versions 1.1.16 et ant<6E>rieures, la valeur par d<>faut
|
2005-12-17 12:41:01 +00:00
|
|
|
|
est "debug" si l'option n'est pas pr<70>cis<69>e.
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
Les cat<61>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
|
|
|
|
|
|
2005-12-17 12:46:33 +00:00
|
|
|
|
Conform<EFBFBD>ment <20> la RFC3164, les messages <20>mis sont limit<69>s <20> 1024 caract<63>res.
|
|
|
|
|
|
2005-12-17 12:08:06 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
global
|
|
|
|
|
log 192.168.2.200 local3
|
2005-12-17 12:41:01 +00:00
|
|
|
|
log 127.0.0.1 local4 notice
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
|
|
|
|
1.2) limitation du nombre de connexions
|
|
|
|
|
---------------------------------------
|
|
|
|
|
Il est possible et conseill<6C> 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<EFBFBD>ral <20> avoir un peu plus du double de
|
|
|
|
|
sessions TCP que le maximum de connexions fix<69>. C'est important pour fixer le
|
|
|
|
|
param<EFBFBD>tre 'ulimit -n' avant de lancer le proxy. Pour comptabiliser le nombre
|
|
|
|
|
de sockets n<>cessaires, il faut prendre en compte ces param<61>tres :
|
|
|
|
|
- 1 socket par connexion entrante
|
|
|
|
|
- 1 socket par connexion sortante
|
2005-12-17 13:08:03 +00:00
|
|
|
|
- 1 socket par couple adresse/port d'<27>coute par proxy
|
2005-12-17 12:08:06 +00:00
|
|
|
|
- 1 socket pour chaque serveur en cours de health-check
|
2005-12-17 12:10:27 +00:00
|
|
|
|
- 1 socket pour les logs (tous serveurs confondus)
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
2005-12-17 13:08:03 +00:00
|
|
|
|
Dans le cas o<> chaque proxy n'<27>coute que sur un couple adresse/port, positionner
|
|
|
|
|
la limite du nombre de descripteurs de fichiers (ulimit -n) <20>
|
|
|
|
|
(2 * maxconn + nbproxy + nbserveurs + 1). Dans une future version, haproxy sera
|
2005-12-17 12:10:27 +00:00
|
|
|
|
capable de positionner lui-m<>me cette limite.
|
|
|
|
|
|
|
|
|
|
1.3) Diminution des privil<69>ges
|
|
|
|
|
------------------------------
|
|
|
|
|
Afin de r<>duire les risques d'attaques dans le cas o<> une faille non identifi<66>e
|
|
|
|
|
serait exploit<69>e, il est possible de diminuer les privil<69>ges du processus, et
|
2005-12-17 12:41:01 +00:00
|
|
|
|
de l'isoler dans un r<>pertoire sans risque.
|
2005-12-17 12:10:27 +00:00
|
|
|
|
|
|
|
|
|
Dans la section 'global', le param<61>tre 'uid' permet de sp<73>cifier un identifiant
|
|
|
|
|
num<EFBFBD>rique d'utilisateur. La valeur 0, correspondant normalement au super-
|
|
|
|
|
utilisateur, poss<73>de ici une signification particuli<6C>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<6E>re, le param<61>tre 'gid' correspond <20>
|
|
|
|
|
un identifiant de groupe, et utilise par d<>faut la valeur 0 pour ne rien
|
|
|
|
|
changer. Il est particuli<6C>rement d<>conseill<6C> d'utiliser des comptes g<>n<EFBFBD>riques
|
|
|
|
|
tels que 'nobody' car cette pratique revient <20> utiliser 'root' si d'autres
|
|
|
|
|
processus utilisent les m<>mes identifiants.
|
|
|
|
|
|
|
|
|
|
Le param<61>tre 'chroot' autorise <20> changer la racine du processus une fois le
|
|
|
|
|
programme lanc<6E>, de sorte que ni le processus, ni l'un de ses descendants ne
|
2005-12-17 12:41:01 +00:00
|
|
|
|
puissent remonter de nouveau <20> la racine. Ce type de cloisonnement (chroot) est
|
2005-12-17 13:08:03 +00:00
|
|
|
|
g<EFBFBD>n<EFBFBD>ralement contournable sur certains OS (Linux, Solaris) pour peu que
|
|
|
|
|
l'attaquant poss<73>de des droits 'root' et soit en mesure d'utiliser ou de cr<63>er
|
|
|
|
|
un r<>pertoire. Aussi, il est important d'utiliser un r<>pertoire sp<73>cifique au
|
|
|
|
|
service pour cet usage, et de ne pas mutualiser un m<>me r<>pertoire pour
|
|
|
|
|
plusieurs services de nature diff<66>rente. Pour rendre l'isolement plus robuste,
|
|
|
|
|
il est conseill<6C> 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.
|
2005-12-17 12:10:27 +00:00
|
|
|
|
|
|
|
|
|
Remarque: dans le cas o<> une telle faille serait mise en <20>vidence, il est fort
|
|
|
|
|
probable que les premi<6D>res tentatives de son exploitation provoquent un arr<72>t du
|
|
|
|
|
programme, <20> 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<69> r<>duit les risques d'intrusion, il est parfois bien utile
|
|
|
|
|
dans ces circonstances de conna<6E>tre les conditions d'apparition du probl<62>me, via
|
|
|
|
|
l'obtention d'un fichier 'core'. La plupart des syst<73>mes, pour des raisons de
|
|
|
|
|
s<EFBFBD>curit<EFBFBD>, d<>sactivent la g<>n<EFBFBD>ration du fichier 'core' apr<70>s un changement
|
|
|
|
|
d'identifiant pour le processus. Il faudra donc soit lancer le processus <20>
|
|
|
|
|
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<EFBFBD>pertoire sp<73>cifi<66> apr<70>s l'option 'chroot'. Ne pas oublier la commande suivante
|
|
|
|
|
pour autoriser la g<>n<EFBFBD>ration du fichier avant de lancer le programme :
|
|
|
|
|
|
|
|
|
|
# ulimit -c unlimited
|
|
|
|
|
|
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
global
|
|
|
|
|
uid 30000
|
|
|
|
|
gid 30000
|
|
|
|
|
chroot /var/chroot/haproxy
|
|
|
|
|
|
2005-12-17 13:14:34 +00:00
|
|
|
|
1.4) Modes de fonctionnement
|
2005-12-17 12:10:27 +00:00
|
|
|
|
----------------------------
|
|
|
|
|
Le service peut fonctionner dans plusieurs modes :
|
|
|
|
|
- avant- / arri<72>re-plan
|
|
|
|
|
- silencieux / normal / debug
|
|
|
|
|
|
|
|
|
|
Le mode par d<>faut est normal, avant-plan, c'est <20> dire que le programme ne rend
|
|
|
|
|
pas la main une fois lanc<6E>. Il ne faut surtout pas le lancer comme ceci dans un
|
|
|
|
|
script de d<>marrage du syst<73>me, sinon le syst<73>me ne finirait pas son
|
|
|
|
|
initialisation. Il faut le mettre en arri<72>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'<27>quivalent du param<61>tre '-D' de la ligne de commande.
|
|
|
|
|
|
|
|
|
|
Par ailleurs, certains messages d'alerte sont toujours envoy<6F>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'<27>quivalent en ligne de commande.
|
|
|
|
|
|
|
|
|
|
Enfin, le mode 'debug' permet de diagnostiquer les origines de certains
|
|
|
|
|
probl<EFBFBD>mes en affichant les connexions, d<>connexions et <20>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.
|
|
|
|
|
|
2005-12-17 13:14:34 +00:00
|
|
|
|
1.5) Accroissement de la capacit<69> de traitement
|
2005-12-17 12:10:27 +00:00
|
|
|
|
-----------------------------------------------
|
|
|
|
|
Sur des machines multi-processeurs, il peut sembler g<>ch<63> de n'utiliser qu'un
|
|
|
|
|
processeur pour effectuer les t<>ches de relayage, m<>me si les charges
|
|
|
|
|
n<EFBFBD>cessaires <20> saturer un processeur actuel sont bien au-del<65> des ordres de
|
|
|
|
|
grandeur couramment rencontr<74>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<73>cifi<66> par le param<61>tre 'nbproc' de la
|
|
|
|
|
section 'global'. Sa valeur par d<>faut est naturellement 1. Ceci ne fonctionne
|
|
|
|
|
qu'en mode 'daemon'.
|
2005-12-17 12:08:06 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
|
|
|
|
|
global
|
|
|
|
|
daemon
|
|
|
|
|
quiet
|
|
|
|
|
nbproc 2
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:14:34 +00:00
|
|
|
|
1.6) Simplification de la gestion des processus
|
|
|
|
|
-----------------------------------------------
|
|
|
|
|
Haproxy supporte dor<6F>navant la notion de fichiers de pid (-> pidfiles). Si le
|
|
|
|
|
param<EFBFBD>tre '-p' de ligne de commande, ou l'option globale 'pidfile' sont suivis
|
|
|
|
|
d'un nom de fichier, alors ce fichier sera supprim<69> puis recr<63><72> et contiendra
|
|
|
|
|
le num<75>ro de PID des processus fils, <20> 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<6F>g<EFBFBD> en lecture seule. Il
|
|
|
|
|
appartiendra <20> l'utilisateur ayant lanc<6E> 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)
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2) D<>finition d'un service en <20>coute
|
|
|
|
|
====================================
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Les sections de service d<>butent par le mot cl<63> "listen" :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen <nom_instance> [ <adresse_IP>:<plage_ports>[,...] ]
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
- <nom_instance> est le nom de l'instance d<>crite. Ce nom sera envoy<6F> dans les
|
|
|
|
|
logs, donc il est souhaitable d'utiliser un nom relatif au service relay<61>. Aucun
|
|
|
|
|
test n'est effectu<74> concernant l'unicit<69> de ce nom, qui n'est pas obligatoire,
|
2005-12-17 13:02:24 +00:00
|
|
|
|
mais fortement recommand<6E>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 <20> un port, soit <20> une plage de ports sur
|
|
|
|
|
lesquels le relais acceptera des connexions pour l'adresse IP sp<73>cifi<66>e.
|
|
|
|
|
Cette plage peut <20>tre :
|
|
|
|
|
- soit un port num<75>rique (ex: '80')
|
|
|
|
|
- soit une plage constitu<74>e de deux valeurs s<>par<61>es par un tiret
|
|
|
|
|
(ex: '2000-2100') repr<70>sentant les extr<74>mit<69>s incluses dans la
|
|
|
|
|
plage.
|
|
|
|
|
Il faut faire attention <20> l'usage des plages, car chaque combinaison
|
|
|
|
|
<adresse_IP>:<port> consomme une socket, donc un descripteur de fichier.
|
|
|
|
|
Le couple <adresse_IP>:<port> doit <20>tre unique pour toutes les instances
|
|
|
|
|
d'une m<>me machine. L'attachement <20> un port inf<6E>rieur <20> 1024 n<>cessite un
|
|
|
|
|
niveau de privil<69>ge particulier lors du lancement du programme (ind<6E>pendamment
|
|
|
|
|
du param<61>tre 'uid' de la section 'global').
|
|
|
|
|
|
|
|
|
|
- le couple <adresse_IP>:<plage_ports> peut <20>tre r<>p<EFBFBD>t<EFBFBD> ind<6E>finiment pour
|
|
|
|
|
demander au relais d'<27>couter <20>galement sur d'autres adresses et/ou d'autres
|
|
|
|
|
plages de ports. Pour cela, il suffit de s<>parer les couples par une virgule.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
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
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Si toutes les adresses ne tiennent pas sur une ligne, il est possible d'en
|
|
|
|
|
rajouter <20> l'aide du mot cl<63> 'bind'. Dans ce cas, il n'est m<>me pas n<>cessaire
|
|
|
|
|
de sp<73>cifier la premi<6D>re adresse sur la ligne listen, ce qui facilite parfois
|
|
|
|
|
l'<27>criture de configurations :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
bind [ <adresse_IP>:<plage_ports>[,...] ]
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Exemples :
|
|
|
|
|
----------
|
|
|
|
|
listen http_proxy
|
|
|
|
|
bind :80,:443
|
|
|
|
|
bind 10.0.0.1:10080,10.0.0.1:10443
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2.1) Inhibition d'un service
|
|
|
|
|
----------------------------
|
2005-12-17 13:08:03 +00:00
|
|
|
|
Un service peut <20>tre d<>sactiv<69> pour des besoins de maintenance, sans avoir <20>
|
2005-12-17 12:10:27 +00:00
|
|
|
|
commenter toute une partie du fichier. Il suffit de positionner le mot cl<63>
|
|
|
|
|
"disabled" dans sa section :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
listen smtp_proxy 0.0.0.0:25
|
|
|
|
|
disabled
|
|
|
|
|
|
2005-12-17 13:08:03 +00:00
|
|
|
|
Remarque: le mot cl<63> 'enabled' permet de r<>activer un service pr<70>alablement
|
|
|
|
|
d<>sactiv<69> par le mot cl<63> 'disabled', par exemple <20> cause d'une
|
|
|
|
|
configuration par d<>faut.
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2.2) Mode de fonctionnement
|
|
|
|
|
---------------------------
|
2005-12-17 13:08:03 +00:00
|
|
|
|
Un service peut fonctionner dans trois modes diff<66>rents :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
- TCP
|
|
|
|
|
- HTTP
|
|
|
|
|
- supervision
|
|
|
|
|
|
|
|
|
|
Mode TCP
|
|
|
|
|
--------
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Dans ce mode, le service relaye, d<>s leur <20>tablissement, les connexions TCP vers
|
|
|
|
|
un ou plusieurs serveurs. Aucun traitement n'est effectu<74> sur le flux. Il s'agit
|
|
|
|
|
simplement d'une association source<adresse:port> -> destination<adresse:port>.
|
|
|
|
|
Pour l'utiliser, pr<70>ciser le mode TCP sous la d<>claration du relais.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
listen smtp_proxy 0.0.0.0:25
|
|
|
|
|
mode tcp
|
|
|
|
|
|
|
|
|
|
Mode HTTP
|
|
|
|
|
---------
|
2005-12-17 12:10:27 +00:00
|
|
|
|
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<EFBFBD>cision. Les ent<6E>tes HTTP sont analys<79>s pour y trouver un <20>ventuel cookie, et
|
|
|
|
|
certains d'entre-eux peuvent <20>tre modifi<66>s par le biais d'expressions
|
|
|
|
|
r<EFBFBD>guli<EFBFBD>res. Pour activer ce mode, pr<70>ciser le mode HTTP sous la d<>claration du
|
|
|
|
|
relais.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
|
|
|
|
|
Mode supervision
|
|
|
|
|
----------------
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Il s'agit d'un mode offrant <20> un composant externe une visibilit<69> de l'<27>tat de
|
|
|
|
|
sant<EFBFBD> du service. Il se contente de retourner "OK" <20> tout client se connectant
|
|
|
|
|
sur son port. Il peut <20>tre utilis<69> avec des r<>partiteurs de charge <20>volu<6C>s pour
|
2005-12-17 13:10:59 +00:00
|
|
|
|
d<EFBFBD>terminer quels sont les services utilisables. Si l'option 'httpchk' est
|
|
|
|
|
activ<EFBFBD>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<70>ciser
|
2005-12-17 12:10:27 +00:00
|
|
|
|
le mode HEALTH sous la d<>claration du relais.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 13:10:59 +00:00
|
|
|
|
# r<>ponse simple : 'OK'
|
2005-12-17 11:21:26 +00:00
|
|
|
|
listen health_check 0.0.0.0:60000
|
|
|
|
|
mode health
|
|
|
|
|
|
2005-12-17 13:10:59 +00:00
|
|
|
|
# r<>ponse HTTP : 'HTTP/1.0 200 OK'
|
|
|
|
|
listen http_health_check 0.0.0.0:60001
|
|
|
|
|
mode health
|
|
|
|
|
option httpchk
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2.3) Limitation du nombre de connexions simultan<61>es
|
|
|
|
|
---------------------------------------------------
|
|
|
|
|
Le param<61>tre "maxconn" permet de fixer la limite acceptable en nombre de
|
|
|
|
|
connexions simultan<61>es par proxy. Chaque proxy qui atteint cette valeur cesse
|
|
|
|
|
d'<27>couter jusqu'<27> lib<69>ration d'une connexion. Voir plus loin concernant les
|
|
|
|
|
limitations li<6C>es au syst<73>me.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 12:10:27 +00:00
|
|
|
|
listen tiny_server 0.0.0.0:80
|
|
|
|
|
maxconn 10
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.4) Arr<72>t en douceur
|
|
|
|
|
---------------------
|
|
|
|
|
Il est possible d'arr<72>ter les services en douceur en envoyant un signal SIG_USR1
|
|
|
|
|
au processus relais. Tous les services seront alors mis en phase d'arr<72>t, mais
|
|
|
|
|
pourront continuer d'accepter des connexions pendant un temps d<>fini par le
|
|
|
|
|
param<EFBFBD>tre 'grace' (en millisecondes). Cela permet par exemple, de faire savoir
|
|
|
|
|
rapidement <20> 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<73>es. Dans le pire des cas,
|
|
|
|
|
il faudra attendre en plus leur expiration avant l'arr<72>t total du processus. La
|
|
|
|
|
valeur par d<>faut est 0 (pas de gr<67>ce, arr<72>t imm<6D>diat de l'<27>coute).
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
# arr<72>ter en douceur par 'killall -USR1 haproxy'
|
2005-12-17 11:21:26 +00:00
|
|
|
|
# le service tournera encore 10 secondes apr<70>s la demande d'arr<72>t
|
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
grace 10000
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
# ce port n'est test<73> que par un r<>partiteur de charge.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
listen health_check 0.0.0.0:60000
|
|
|
|
|
mode health
|
|
|
|
|
grace 0
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2.5) Temps d'expiration des connexions
|
|
|
|
|
--------------------------------------
|
|
|
|
|
Il est possible de param<61>trer certaines dur<75>es d'expiration au niveau des
|
|
|
|
|
connexions TCP. Trois temps ind<6E>pendants sont configurables et acceptent des
|
|
|
|
|
valeurs en millisecondes. Si l'une de ces trois temporisations est d<>pass<73>e, la
|
|
|
|
|
session est termin<69>e <20> chaque extr<74>mit<69>.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
- temps d'attente d'une donn<6E>e de la part du client, ou de la
|
|
|
|
|
possibilit<69> de lui envoyer des donn<6E>es : "clitimeout" :
|
|
|
|
|
|
|
|
|
|
# time-out client <20> 2mn30.
|
|
|
|
|
clitimeout 150000
|
|
|
|
|
|
|
|
|
|
- temps d'attente d'une donn<6E>e de la part du serveur, ou de la
|
|
|
|
|
possibilit<69> de lui envoyer des donn<6E>es : "srvtimeout" :
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
# time-out serveur <20> 30s.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
srvtimeout 30000
|
|
|
|
|
|
|
|
|
|
- temps d'attente de l'<27>tablissement d'une connexion vers un serveur
|
|
|
|
|
"contimeout" :
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
# on abandonne si la connexion n'est pas <20>tablie apr<70>s 4 secondes
|
|
|
|
|
contimeout 4000
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Remarques :
|
|
|
|
|
-----------
|
|
|
|
|
- "contimeout" et "srvtimeout" n'ont pas d'utilit<69> dans le cas du serveur de
|
|
|
|
|
type "health".
|
|
|
|
|
- sous de fortes charges, ou sur un r<>seau satur<75> ou d<>fectueux, il est
|
|
|
|
|
possible de perdre des paquets. Du fait que la premi<6D>re retransmission TCP
|
|
|
|
|
n'ait lieu qu'au bout de 3 secoudes, fixer un timeout de connexion inf<6E>rieur
|
|
|
|
|
<20> 3 secondes ne permet pas de se rattraper sur la perte de paquets car la
|
|
|
|
|
session aura <20>t<EFBFBD> abandonn<6E>e avant la premi<6D>re retransmission. Une valeur de
|
|
|
|
|
4 secondes r<>duira consid<69>rablement le nombre d'<27>checs de connexion.
|
|
|
|
|
|
|
|
|
|
2.6) Tentatives de reconnexion
|
|
|
|
|
------------------------------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
Lors d'un <20>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
|
2005-12-17 12:10:27 +00:00
|
|
|
|
abandon est fourni par le param<61>tre "retries".
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
# on essaie encore trois fois maxi
|
|
|
|
|
retries 3
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
2.7) Adresse du serveur
|
|
|
|
|
-----------------------
|
|
|
|
|
Le serveur vers lequel sont redirig<69>es les nouvelles connexions est d<>fini par
|
|
|
|
|
le param<61>tre "dispatch" sous la forme <adresse_ip>:<port>. Il correspond <20> un
|
|
|
|
|
serveur d'assignation de cookie dans le cas o<> le service consiste <20> assurer
|
|
|
|
|
uniquement une persistence HTTP, ou bien simplement au serveur destination dans
|
2005-12-17 13:02:24 +00:00
|
|
|
|
le cas de relayage TCP simple. Cet ancien mode ne permet pas de tester l'<27>tat
|
|
|
|
|
du serveur distant, et il est maintenant recommand<6E> d'utiliser de pr<70>f<EFBFBD>rence
|
|
|
|
|
le mode 'balance'.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
# on envoie toutes les nouvelles connexions ici
|
|
|
|
|
dispatch 192.168.1.2:80
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Remarque :
|
|
|
|
|
----------
|
|
|
|
|
Ce param<61>tre n'a pas d'utilit<69> pour un serveur en mode 'health', ni en mode
|
|
|
|
|
'balance'.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
|
2005-12-17 12:14:35 +00:00
|
|
|
|
2.8) Adresse de sortie
|
|
|
|
|
----------------------
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Il est possible de forcer l'adresse utilis<69>e pour <20>tablir les connexions vers
|
|
|
|
|
les serveurs <20> l'aide du param<61>tre "source". Il est m<>me possible de forcer le
|
|
|
|
|
port, bien que cette fonctionnalit<69> se limite <20> des usages tr<74>s sp<73>cifiques.
|
|
|
|
|
C'est particuli<6C>rement utile en cas d'adressage multiple, et plus g<>n<EFBFBD>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<73>me. Il est <20> noter que depuis la version 1.1.18, les tests de bon
|
2005-12-17 13:08:03 +00:00
|
|
|
|
fonctionnement des serveurs seront aussi effectu<74>s <20> partir de la source
|
2005-12-17 13:02:24 +00:00
|
|
|
|
sp<EFBFBD>cifi<EFBFBD>e par ce param<61>tre.
|
2005-12-17 12:14:35 +00:00
|
|
|
|
|
|
|
|
|
Exemples :
|
|
|
|
|
----------
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen http_proxy *:80
|
2005-12-17 12:14:35 +00:00
|
|
|
|
# toutes les connexions prennent l'adresse 192.168.1.200
|
|
|
|
|
source 192.168.1.200:0
|
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen rlogin_proxy *:513
|
2005-12-17 12:14:35 +00:00
|
|
|
|
# utiliser l'adresse 192.168.1.200 et le port r<>serv<72> 900
|
|
|
|
|
source 192.168.1.200:900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.9) D<>finition du nom du cookie
|
2005-12-17 12:10:27 +00:00
|
|
|
|
--------------------------------
|
|
|
|
|
En mode HTTP, il est possible de rechercher la valeur d'un cookie pour savoir
|
|
|
|
|
vers quel serveur aiguiller la requ<71>te utilisateur. Le nom du cookie est donn<6E>
|
|
|
|
|
par le param<61>tre "cookie".
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen http_proxy :80
|
2005-12-17 11:21:26 +00:00
|
|
|
|
mode http
|
|
|
|
|
cookie SERVERID
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
On peut modifier l'utilisation du cookie pour la rendre plus intelligente
|
|
|
|
|
vis-<2D>-vis des applications relay<61>es. Il est possible, notamment de supprimer ou
|
|
|
|
|
r<EFBFBD><EFBFBD>crire un cookie retourn<72> par un serveur acc<63>d<EFBFBD> en direct, et d'ins<6E>rer un
|
|
|
|
|
cookie dans une r<>ponse HTTP adress<73>e <20> un serveur s<>lectionn<6E> en r<>partition
|
2005-12-17 12:14:35 +00:00
|
|
|
|
de charge, et m<>me de signaler aux proxies amont de ne pas cacher le cookie
|
|
|
|
|
ins<EFBFBD>r<EFBFBD>.
|
2005-12-17 12:10:27 +00:00
|
|
|
|
|
|
|
|
|
Exemples :
|
|
|
|
|
----------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
Pour ne conserver le cookie qu'en acc<63>s indirect, donc <20> travers le
|
2005-12-17 12:10:27 +00:00
|
|
|
|
dispatcheur, et supprimer toutes ses <20>ventuelles occurences lors des acc<63>s
|
|
|
|
|
directs :
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
cookie SERVERID indirect
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Pour remplacer la valeur d'un cookie existant par celle attribu<62>e <20> un serveur,
|
|
|
|
|
lors d'un acc<63>s direct :
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
cookie SERVERID rewrite
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Pour cr<63>er un cookie comportant la valeur attribu<62>e <20> un serveur lors d'un acc<63>s
|
2005-12-17 12:41:01 +00:00
|
|
|
|
en r<>partition de charge interne. Dans ce cas, il est souhaitable que tous les
|
|
|
|
|
serveurs aient un cookie renseign<67>. Un serveur non assign<67> d'un cookie
|
|
|
|
|
retournera un cookie vide (cookie de suppression) :
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
cookie SERVERID insert
|
|
|
|
|
|
2005-12-17 12:14:35 +00:00
|
|
|
|
Pour ins<6E>rer un cookie, en s'assurant qu'un cache en amont ne le stockera pas,
|
|
|
|
|
ajouter le mot cl<63> 'nocache' apr<70>s 'insert' :
|
|
|
|
|
|
|
|
|
|
cookie SERVERID insert nocache
|
|
|
|
|
|
2005-12-17 12:27:43 +00:00
|
|
|
|
Pour ins<6E>rer un cookie seulement suite aux requ<71>tes de type POST, ajouter le mot
|
|
|
|
|
cl<EFBFBD> 'postonly' apr<70>s 'insert' :
|
|
|
|
|
|
|
|
|
|
cookie SERVERID insert postonly
|
|
|
|
|
|
2005-12-17 12:14:35 +00:00
|
|
|
|
|
2005-12-17 12:11:56 +00:00
|
|
|
|
Remarques :
|
|
|
|
|
-----------
|
|
|
|
|
- Il est possible de combiner 'insert' avec 'indirect' ou 'rewrite' pour s'adapter
|
|
|
|
|
<20> des applications g<>n<EFBFBD>rant d<>j<EFBFBD> le cookie, avec un contenu invalide. Il suffit
|
|
|
|
|
pour cela de les sp<73>cifier sur la m<>me ligne.
|
2005-12-17 13:08:03 +00:00
|
|
|
|
|
2005-12-17 12:11:56 +00:00
|
|
|
|
- dans le cas o<> 'insert' et 'indirect' sont sp<73>cifi<66>s, le cookie n'est jamais
|
|
|
|
|
transmis au serveur vu qu'il n'en a pas connaissance et ne pourrait pas le
|
|
|
|
|
comprendre.
|
2005-12-17 13:08:03 +00:00
|
|
|
|
|
2005-12-17 12:14:35 +00:00
|
|
|
|
- il est particuli<6C>rement recommand<6E> 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<6E>r<EFBFBD>, donc provoquer des changements de serveurs pour
|
|
|
|
|
des clients partageant le m<>me cache.
|
2005-12-17 13:08:03 +00:00
|
|
|
|
|
2005-12-17 12:27:43 +00:00
|
|
|
|
- lorsque l'application est bien connue, et que les parties n<>cessitant de la
|
|
|
|
|
persistence sont syst<73>matiquement acc<63>d<EFBFBD>es par un formulaire en mode POST,
|
|
|
|
|
il est plus efficace encore de combiner le mot cl<63> "postonly" avec "insert"
|
|
|
|
|
et "indirect", car la page d'accueil reste cachable, et c'est l'application
|
|
|
|
|
qui g<>re le 'cache-control'.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:14:35 +00:00
|
|
|
|
2.10) Assignation d'un serveur <20> une valeur de cookie
|
2005-12-17 12:10:27 +00:00
|
|
|
|
----------------------------------------------------
|
2005-12-17 12:41:01 +00:00
|
|
|
|
En mode HTTP, il est possible d'associer des valeurs de cookie <20> des serveurs
|
|
|
|
|
par le param<61>tre 'server'. La syntaxe est :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 11:48:26 +00:00
|
|
|
|
server <identifiant> <adresse_ip>:<port> cookie <valeur>
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
- <identifiant> est un nom quelconque de serveur utilis<69> pour l'identifier dans la
|
|
|
|
|
configuration et les logs.
|
|
|
|
|
- <adresse_ip>:<port> est le couple adresse-port sur lequel le serveur <20>coute.
|
|
|
|
|
- <valeur> est la valeur <20> reconna<6E>tre ou positionner dans le cookie.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple : le cookie SERVERID peut contenir server01 ou server02
|
2005-12-17 12:10:27 +00:00
|
|
|
|
---------
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen http_proxy :80
|
2005-12-17 11:21:26 +00:00
|
|
|
|
mode http
|
|
|
|
|
cookie SERVERID
|
|
|
|
|
dispatch 192.168.1.100:80
|
2005-12-17 11:48:26 +00:00
|
|
|
|
server web1 192.168.1.1:80 cookie server01
|
|
|
|
|
server web2 192.168.1.2:80 cookie server02
|
|
|
|
|
|
|
|
|
|
Attention : la syntaxe a chang<6E> depuis la version 1.0.
|
2005-12-17 12:10:27 +00:00
|
|
|
|
-----------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
3) R<>partiteur de charge autonome
|
2005-12-17 12:10:27 +00:00
|
|
|
|
=================================
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Le relais peut effectuer lui-m<>me la r<>partition de charge entre les diff<66>rents
|
|
|
|
|
serveurs d<>finis pour un service donn<6E>, en mode TCP comme en mode HTTP. Pour
|
|
|
|
|
cela, on pr<70>cise le mot cl<63> 'balance' dans la d<>finition du service,
|
|
|
|
|
<EFBFBD>ventuellement suivi du nom d'un algorithme de r<>partition. En version 1.1.9,
|
|
|
|
|
seul 'roundrobin' est g<>r<EFBFBD>, et c'est aussi la valeur implicite par d<>faut. Il
|
|
|
|
|
est <20>vident qu'en cas d'utilisation du r<>partiteur interne, il ne faudra pas
|
|
|
|
|
sp<EFBFBD>cifier d'adresse de dispatch, et qu'il faudra au moins un serveur.
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple : m<>me que pr<70>c<EFBFBD>demment en r<>partition interne
|
2005-12-17 12:10:27 +00:00
|
|
|
|
---------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
listen http_proxy :80
|
2005-12-17 11:48:26 +00:00
|
|
|
|
mode http
|
|
|
|
|
cookie SERVERID
|
|
|
|
|
balance roundrobin
|
|
|
|
|
server web1 192.168.1.1:80 cookie server01
|
|
|
|
|
server web2 192.168.1.2:80 cookie server02
|
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Depuis la version 1.1.22, il est possible de d<>terminer automatiquement le port
|
|
|
|
|
du serveur vers lequel sera envoy<6F>e la connexion, en fonction du port d'<27>coute
|
|
|
|
|
sur lequel le client s'est connect<63>. En effet, il y a 4 possibilit<69>s pour le
|
|
|
|
|
champ <port> de l'adresse serveur :
|
|
|
|
|
|
|
|
|
|
- non sp<73>cifi<66> ou nul :
|
|
|
|
|
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
|
|
|
|
|
lequel le relais a re<72>u la connexion.
|
|
|
|
|
|
|
|
|
|
- valeur num<75>rique (seul cas support<72> pour les versions ant<6E>rieures) :
|
|
|
|
|
le serveur recevra la connexion sur le port d<>sign<67>.
|
|
|
|
|
|
|
|
|
|
- valeur num<75>rique pr<70>c<EFBFBD>d<EFBFBD>e d'un signe '+' :
|
|
|
|
|
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
|
|
|
|
|
lequel le relais a re<72>u la connexion, auquel on ajoute la valeur d<>sign<67>e.
|
|
|
|
|
|
|
|
|
|
- valeur num<75>rique pr<70>c<EFBFBD>d<EFBFBD>e d'un signe '-' :
|
|
|
|
|
la connexion sera envoy<6F>e au serveur sur le m<>me port que celui sur
|
|
|
|
|
lequel le relais a re<72>u la connexion, duquel on soustrait la valeur
|
|
|
|
|
d<>sign<67>e.
|
|
|
|
|
|
|
|
|
|
Exemples :
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
# m<>me que pr<70>c<EFBFBD>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<61> 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
|
|
|
|
|
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
3.1) Surveillance des serveurs
|
|
|
|
|
------------------------------
|
2005-12-17 12:32:07 +00:00
|
|
|
|
Il est possible de tester l'<27>tat des serveurs par <20>tablissement de connexion TCP
|
|
|
|
|
ou par envoi d'une requ<71>te HTTP. Un serveur hors d'usage ne sera pas utilis<69>
|
2005-12-17 12:41:01 +00:00
|
|
|
|
dans le processus de r<>partition de charge interne. Pour activer la surveillance,
|
2005-12-17 12:10:27 +00:00
|
|
|
|
ajouter le mot cl<63> 'check' <20> la fin de la d<>claration du serveur. Il est
|
|
|
|
|
possible de sp<73>cifier l'intervalle (en millisecondes) s<>parant deux tests du
|
|
|
|
|
serveur par le param<61>tre "inter", le nombre d'<27>checs accept<70>s par le param<61>tre
|
|
|
|
|
"fall", et le nombre de succ<63>s avant reprise par le param<61>tre "rise". Les
|
|
|
|
|
param<EFBFBD>tres non pr<70>cis<69>s prennent les valeurs suivantes par d<>faut :
|
2005-12-17 11:55:52 +00:00
|
|
|
|
- inter : 2000
|
|
|
|
|
- rise : 2
|
|
|
|
|
- fall : 3
|
2005-12-17 13:02:24 +00:00
|
|
|
|
- port : port de connexion du serveur
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:32:07 +00:00
|
|
|
|
Le mode par d<>faut consiste <20> <20>tablir des connexions TCP uniquement. Dans
|
|
|
|
|
certains cas de pannes, des serveurs peuvent continuer <20> accepter les connexions
|
|
|
|
|
sans les traiter. Depuis la version 1.1.16, haproxy est en mesure d'envoyer des
|
2005-12-17 12:46:33 +00:00
|
|
|
|
requ<EFBFBD>tes HTTP courtes et tr<74>s peu co<63>teuses. Les versions 1.1.16 et 1.1.17
|
2005-12-17 12:57:42 +00:00
|
|
|
|
utilisent "OPTIONS / HTTP/1.0". Dans les versions 1.1.18 <20> 1.1.20, les requ<71>tes
|
|
|
|
|
ont <20>t<EFBFBD> chang<6E>es en "OPTIONS * HTTP/1.0" pour des raisons de contr<74>le d'acc<63>s aux
|
|
|
|
|
ressources. Cependant, cette requ<71>te document<6E>e dans la RFC2068 n'est pas
|
|
|
|
|
comprise par tous les serveurs. Donc <20> partir de la version 1.1.21, la requ<71>te
|
|
|
|
|
par d<>faut est revenue <20> "OPTIONS / HTTP/1.0", mais il est possible de
|
|
|
|
|
param<EFBFBD>trer la partie URI. Les requ<71>tes OPTIONS pr<70>sentent l'avantage d'<27>tre
|
|
|
|
|
facilement extractibles des logs, et de ne pas induire d'acc<63>s aux fichiers c<>t<EFBFBD>
|
|
|
|
|
serveur. Seules les r<>ponses 2xx et 3xx sont consid<69>r<EFBFBD>es valides, les autres (y
|
|
|
|
|
compris non-r<>ponses) aboutissent <20> un <20>chec. Le temps maximal imparti pour une
|
|
|
|
|
r<EFBFBD>ponse est <20>gal <20> l'intervalle entre deux tests (param<61>tre "inter"). Pour
|
|
|
|
|
activer ce mode, sp<73>cifier l'option "httpchk", <20>ventuellement suivie d'une
|
2005-12-17 13:08:03 +00:00
|
|
|
|
m<EFBFBD>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<70>s.
|
2005-12-17 12:32:07 +00:00
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
Depuis la version 1.1.17, il est possible de d<>finir des serveurs de secours,
|
|
|
|
|
utilis<EFBFBD>s uniquement lorsqu'aucun des autres serveurs ne fonctionne. Pour cela,
|
|
|
|
|
ajouter le mot cl<63> "backup" sur la ligne de d<>finition du serveur. Un serveur
|
|
|
|
|
de secours n'est appel<65> que lorsque tous les serveurs normaux, ainsi que tous
|
|
|
|
|
les serveurs de secours qui le pr<70>c<EFBFBD>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 <20> retourner des pages d'indisponibilit<69> de service. Dans ce cas,
|
|
|
|
|
il est pr<70>f<EFBFBD>rable de ne pas affecter de cookie, afin que les clients qui le
|
|
|
|
|
rencontrent n'y soient pas affect<63>s d<>finitivement. Le fait de ne pas mettre
|
|
|
|
|
de cookie envoie un cookie vide, ce qui a pour effet de supprimer un <20>ventuel
|
|
|
|
|
cookie affect<63> pr<70>c<EFBFBD>demment.
|
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Depuis la version 1.1.22, il est possible d'envoyer les tests de fonctionnement
|
|
|
|
|
vers un port diff<66>rent de celui de service. C'est n<>cessaire principalement
|
|
|
|
|
pour les configurations o<> le serveur n'a pas de port pr<70>d<EFBFBD>fini, par exemple
|
|
|
|
|
lorsqu'il est d<>duit du port d'acceptation de la connexion. Pour cela, utiliser
|
|
|
|
|
le param<61>tre 'port' suivi du num<75>ro de port devant r<>pondre aux requ<71>tes.
|
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
Enfin, depuis la version 1.1.17, il est possible de visualiser rapidement l'<27>tat
|
|
|
|
|
courant de tous les serveurs. Pour cela, il suffit d'envoyer un signal SIGHUP au
|
|
|
|
|
processus proxy. L'<27>tat de tous les serveurs de tous les proxies est envoy<6F> 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.
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
Depuis la version 1.1.18 (et 1.2.1), un message d'urgence est envoy<6F> dans les
|
|
|
|
|
logs en niveau 'emerg' si tous les serveurs d'une m<>me instance sont tomb<6D>s,
|
|
|
|
|
afin de notifier l'administrateur qu'il faut prendre une action imm<6D>diate.
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Exemples :
|
|
|
|
|
----------
|
2005-12-17 13:02:24 +00:00
|
|
|
|
# conf du paragraphe 3) avec surveillance TCP
|
2005-12-17 12:32:07 +00:00
|
|
|
|
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
|
|
|
|
|
|
2005-12-17 12:57:42 +00:00
|
|
|
|
# m<>me que pr<70>c<EFBFBD>demment avec surveillance HTTP par 'OPTIONS / HTTP/1.0'
|
2005-12-17 11:48:26 +00:00
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
cookie SERVERID
|
|
|
|
|
balance roundrobin
|
2005-12-17 12:32:07 +00:00
|
|
|
|
option httpchk
|
2005-12-17 11:48:26 +00:00
|
|
|
|
server web1 192.168.1.1:80 cookie server01 check
|
2005-12-17 12:10:27 +00:00
|
|
|
|
server web2 192.168.1.2:80 cookie server02 check inter 500 rise 1 fall 2
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 12:57:42 +00:00
|
|
|
|
# m<>me que pr<70>c<EFBFBD>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
|
|
|
|
|
|
2005-12-17 13:08:03 +00:00
|
|
|
|
# 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
|
|
|
|
|
|
2005-12-17 12:11:56 +00:00
|
|
|
|
# Insertion automatique de cookie dans la r<>ponse du serveur, et suppression
|
2005-12-17 12:14:35 +00:00
|
|
|
|
# automatique dans la requ<71>te, tout en indiquant aux caches de ne pas garder
|
|
|
|
|
# ce cookie.
|
2005-12-17 12:10:27 +00:00
|
|
|
|
listen web_appl 0.0.0.0:80
|
|
|
|
|
mode http
|
2005-12-17 12:14:35 +00:00
|
|
|
|
cookie SERVERID insert nocache indirect
|
2005-12-17 12:10:27 +00:00
|
|
|
|
balance roundrobin
|
|
|
|
|
server web1 192.168.1.1:80 cookie server01 check
|
|
|
|
|
server web2 192.168.1.2:80 cookie server02 check
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 13:08:03 +00:00
|
|
|
|
# idem avec serveur applicatif de secours sur autre site, et serveur de pages d'erreurs
|
2005-12-17 12:41:01 +00:00
|
|
|
|
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
|
2005-12-17 13:08:03 +00:00
|
|
|
|
server web-backup 192.168.2.1:80 cookie server03 check backup
|
|
|
|
|
server web-excuse 192.168.3.1:80 check backup
|
2005-12-17 12:41:01 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
# 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
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
3.2) Reconnexion vers un r<>partiteur en cas d'<27>chec direct
|
|
|
|
|
----------------------------------------------------------
|
|
|
|
|
En mode HTTP, si un serveur d<>fini par un cookie ne r<>pond plus, les clients
|
|
|
|
|
seront d<>finitivement aiguill<6C>s dessus <20> cause de leur cookie, et de ce fait,
|
|
|
|
|
d<EFBFBD>finitivement priv<69>s de service. La sp<73>cification du param<61>tre 'redispatch'
|
|
|
|
|
autorise dans ce cas <20> renvoyer les connexions <20>chou<6F>es vers le r<>partiteur
|
|
|
|
|
(externe ou interne) afin d'assigner un nouveau serveur <20> ces clients.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple :
|
2005-12-17 12:10:27 +00:00
|
|
|
|
---------
|
2005-12-17 11:21:26 +00:00
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
cookie SERVERID
|
|
|
|
|
dispatch 192.168.1.100:80
|
2005-12-17 11:48:26 +00:00
|
|
|
|
server web1 192.168.1.1:80 cookie server01
|
|
|
|
|
server web2 192.168.1.2:80 cookie server02
|
2005-12-17 12:41:01 +00:00
|
|
|
|
redispatch # renvoyer vers dispatch si refus de connexion.
|
|
|
|
|
|
|
|
|
|
Par d<>faut (et dans les versions 1.1.16 et ant<6E>rieures), le param<61>tre redispatch
|
|
|
|
|
ne s'applique qu'aux <20>checs de connexion au serveur. Depuis la version 1.1.17,
|
|
|
|
|
il s'applique aussi aux connexions destin<69>es <20> des serveurs identifi<66>s comme
|
|
|
|
|
hors d'usage par la surveillance. Si l'on souhaite malgr<67> tout qu'un client
|
|
|
|
|
disposant d'un cookie correspondant <20> un serveur d<>fectueux tente de s'y
|
|
|
|
|
connecter, il faut pr<70>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
|
2005-12-17 11:48:26 +00:00
|
|
|
|
redispatch # renvoyer vers dispatch si serveur HS.
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
4) Fonctionnalit<69>s additionnelles
|
|
|
|
|
=================================
|
|
|
|
|
|
|
|
|
|
D'autres fonctionnalit<69>s d'usage moins courant sont disponibles. Il s'agit
|
|
|
|
|
principalement du mode transparent, de la journalisation des connexions, et de
|
|
|
|
|
la r<><72>criture des ent<6E>tes.
|
|
|
|
|
|
|
|
|
|
4.1) Fonctionnement en mode transparent
|
|
|
|
|
---------------------------------------
|
|
|
|
|
En mode HTTP, le mot cl<63> 'transparent' permet d'intercepter des sessions rout<75>es
|
|
|
|
|
<EFBFBD> travers la machine h<>bergeant le proxy. Dans ce mode, on ne pr<70>cise pas
|
|
|
|
|
l'adresse de r<>partition 'dispatch', car celle-ci est tir<69>e de l'adresse
|
|
|
|
|
destination de la session d<>tourn<72>e. Le syst<73>me doit permettre de rediriger les
|
|
|
|
|
paquets vers un processus local.
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple :
|
2005-12-17 12:10:27 +00:00
|
|
|
|
---------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
listen http_proxy 0.0.0.0:65000
|
|
|
|
|
mode http
|
|
|
|
|
transparent
|
|
|
|
|
cookie SERVERID
|
2005-12-17 11:21:26 +00:00
|
|
|
|
server server01 192.168.1.1:80
|
|
|
|
|
server server02 192.168.1.2:80
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
# iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.100 \
|
|
|
|
|
--dport 80 -j REDIRECT --to-ports 65000
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:02:24 +00:00
|
|
|
|
Remarque :
|
|
|
|
|
----------
|
|
|
|
|
Si le port n'est pas sp<73>cifi<66> sur le serveur, c'est le port auquel s'est adress<73>
|
|
|
|
|
le client qui sera utilis<69>. 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
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
4.2) Journalisation des connexions
|
|
|
|
|
----------------------------------
|
2005-12-17 13:12:23 +00:00
|
|
|
|
4.2.1) Niveaux de log
|
|
|
|
|
---------------------
|
2005-12-17 12:10:27 +00:00
|
|
|
|
Les connexions TCP et HTTP peuvent donner lieu <20> une journalisation sommaire ou
|
|
|
|
|
d<EFBFBD>taill<EFBFBD>e indiquant, pour chaque connexion, la date, l'heure, l'adresse IP
|
|
|
|
|
source, le serveur destination, la dur<75>e de la connexion, les temps de r<>ponse,
|
2005-12-17 12:41:01 +00:00
|
|
|
|
la requ<71>te HTTP, le code de retour, la quantit<69> de donn<6E>es transmises, et m<>me
|
|
|
|
|
dans certains cas, la valeur d'un cookie permettant de suivre les sessions.
|
|
|
|
|
Tous les messages sont envoy<6F>s en syslog vers un ou deux serveurs. Se r<>f<EFBFBD>rer <20>
|
|
|
|
|
la section 1.1 pour plus d'information sur les cat<61>gories de logs. La syntaxe
|
2005-12-17 12:10:27 +00:00
|
|
|
|
est la suivante :
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
log <adresse_ip_1> <cat<61>gorie_1> [niveau_max_1]
|
|
|
|
|
log <adresse_ip_2> <cat<61>gorie_2> [niveau_max_2]
|
2005-12-17 12:10:27 +00:00
|
|
|
|
ou
|
|
|
|
|
log global
|
|
|
|
|
|
|
|
|
|
Remarque :
|
|
|
|
|
----------
|
|
|
|
|
La syntaxe sp<73>cifique 'log global' indique que l'on souhaite utiliser les
|
|
|
|
|
param<EFBFBD>tres de journalisation d<>finis dans la section 'global'.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
log 192.168.2.200 local3
|
|
|
|
|
log 192.168.2.201 local4
|
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
4.2.2) Format des logs
|
|
|
|
|
----------------------
|
|
|
|
|
Par d<>faut, les connexions sont journalis<69>es au niveau TCP d<>s l'<27>tablissement
|
|
|
|
|
de la session entre le client et le relais. En pr<70>cisant l'option 'tcplog',
|
|
|
|
|
la connexion ne sera journalis<69>e qu'en fin de session, ajoutant des pr<70>cisions
|
|
|
|
|
sur son <20>tat lors de la d<>connexion, ainsi que le temps de connexion et la
|
|
|
|
|
dur<EFBFBD>e totale de la session.
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
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/5007 0 --
|
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
Une autre option, 'httplog', fournit plus de d<>tails sur le protocole HTTP,
|
|
|
|
|
notamment la requ<71>te et l'<27>tat des cookies. Dans les cas o<> un m<>canisme de
|
|
|
|
|
surveillance effectuant des connexions et d<>connexions fr<66>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<6E> lieu <20> un <20>change de donn<6E>es
|
|
|
|
|
(requ<71>te ou r<>ponse).
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:46:33 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
option httplog
|
|
|
|
|
option dontlognull
|
|
|
|
|
log 192.168.2.200 local3
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
>>> haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 9/7/147/723 200 243 - - ---- "HEAD / HTTP/1.0"
|
|
|
|
|
|
|
|
|
|
Le probl<62>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 <20> ce probl<62>me, une nouvelle option 'logasap' a <20>t<EFBFBD> introduite dans
|
|
|
|
|
la version 1.1.28 (1.2.1). Lorsqu'elle est activ<69>e, le proxy loguera le plus t<>t
|
|
|
|
|
possible, c'est <20> dire juste avant que ne d<>butent les transferts de donn<6E>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 ent<6E>tes de la r<>ponse du serveur, auquel cas le nombre d'octets
|
|
|
|
|
repr<EFBFBD>sentera la taille des ent<6E>tes retourn<72>s au client.
|
|
|
|
|
|
|
|
|
|
Afin d'<27>viter toute confusion avec les logs normaux, le temps total de transfert
|
|
|
|
|
et le nombre d'octets transf<73>r<EFBFBD>s sont pr<70>fix<69>s d'un signe '+' rappeleant que les
|
|
|
|
|
valeurs r<>elles sont certainement plus <20>lev<65>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 - - ---- "GET /image.iso HTTP/1.0"
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
4.2.3) Chronom<6F>trage des <20>v<EFBFBD>nements
|
|
|
|
|
-----------------------------------
|
|
|
|
|
Pour d<>celer des probl<62>mes r<>seau, les mesures du temps <20>coul<75> entre certains
|
|
|
|
|
<EFBFBD>v<EFBFBD>nements sont d'une tr<74>s grande utilit<69>. Tous les temps sont mesur<75>s en
|
|
|
|
|
millisecondes (ms). En mode HTTP, quatre points de mesure sont rapport<72>s sous
|
|
|
|
|
la forme Tq/Tc/Tr/Tt :
|
|
|
|
|
|
|
|
|
|
- Tq: temps total de r<>ception de la requ<71>te HTTP de la part du client.
|
|
|
|
|
C'est le temps qui s'est <20>coul<75> entre le moment o<> le client a <20>tabli
|
|
|
|
|
sa connexion vers le relais, et le moment o<> ce dernier a re<72>u le dernier
|
|
|
|
|
en-t<>te HTTP validant la fin de la requ<71>te. Une valeur '-1' ici indique
|
|
|
|
|
que la requ<71>te compl<70>te n'a jamais <20>t<EFBFBD> re<72>ue.
|
|
|
|
|
|
|
|
|
|
- Tc: temps d'<27>tablissement de la connexion TCP du relais vers le serveur.
|
|
|
|
|
C'est le temps <20>coul<75> entre le moment ou le relais a initi<74> la demande de
|
|
|
|
|
connexion vers le serveur, et le moment o<> ce dernier l'a acquitt<74>e, c'est
|
|
|
|
|
<20> 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 <20>tre <20>tablie
|
|
|
|
|
vers le serveur.
|
|
|
|
|
|
|
|
|
|
- Tr: temps de r<>ponse du serveur. C'est le temps que le serveur a mis pour
|
|
|
|
|
renvoyer la totalit<69> des ent<6E>tes HTTP <20> partir du moment o<> il a acquitt<74>
|
|
|
|
|
la connexion. Ca repr<70>sente exactement le temps de traitement de la
|
|
|
|
|
transaction sans le transfert des donn<6E>es associ<63>es. Une valeur '-1'
|
|
|
|
|
indique que le serveur n'a pas envoy<6F> la totalit<69> de l'ent<6E>te HTTP.
|
|
|
|
|
|
|
|
|
|
- Tt: dur<75>e de vie totale de la session, entre le moment o<> la demande de
|
|
|
|
|
connexion du client a <20>t<EFBFBD> acquitt<74>e et le moment o<> la connexion a <20>t<EFBFBD>
|
2005-12-17 23:57:06 +00:00
|
|
|
|
referm<72>e aux deux extr<74>mit<69>s (client et serveur). La signification change
|
|
|
|
|
un peu si l'option 'logasap' est pr<70>sente. Dans ce cas, le temps correspond
|
|
|
|
|
uniquement <20> (Tq + Tc + Tr), et se trouve pr<70>fix<69> d'un signe '+'. On peut
|
|
|
|
|
donc d<>duire Td, le temps de transfert des donn<6E>es, en excluant les autres
|
|
|
|
|
temps :
|
2005-12-17 13:12:23 +00:00
|
|
|
|
|
|
|
|
|
Td = Tt - (Tq + Tc + Tr)
|
|
|
|
|
|
|
|
|
|
Les temps rapport<72>s <20> '-1' sont simplement <20> <20>liminer de cette <20>quation.
|
|
|
|
|
|
|
|
|
|
En mode TCP ('option tcplog'), seuls les deux indicateurs Tc et Tt sont
|
|
|
|
|
rapport<EFBFBD>s.
|
|
|
|
|
|
|
|
|
|
Ces temps fournissent de pr<70>cieux renseignement sur des causes probables de
|
|
|
|
|
probl<EFBFBD>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<6C>s <20> un
|
|
|
|
|
probl<EFBFBD>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 <20>t<EFBFBD>
|
|
|
|
|
abandonn<EFBFBD>e sur expiration d'un time-out.
|
|
|
|
|
|
|
|
|
|
Cas les plus fr<66>quents :
|
|
|
|
|
|
|
|
|
|
- Si Tq est proche de 3000, un paquet a tr<74>s certainement <20>t<EFBFBD> perdu entre
|
|
|
|
|
le client et le relais.
|
|
|
|
|
- Si Tc est proche de 3000, un paquet a tr<74>s certainement <20>t<EFBFBD> perdu entre
|
|
|
|
|
le relais et le serveur durant la phase de connexion. Cet indicateur
|
|
|
|
|
devrait normalement toujours <20>tre tr<74>s bas (moins de quelques dizaines).
|
|
|
|
|
- Si Tr est presque toujours inf<6E>rieur <20> 3000, et que certaines valeurs
|
|
|
|
|
semblent proches de la valeur moyenne major<6F>e de 3000, il y a peut-<2D>tre
|
|
|
|
|
de pertes entre le relais et le serveur.
|
|
|
|
|
- Si Tt est l<>g<EFBFBD>rement sup<75>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<70>s la fin des <20>changes. Voir plus loin pour
|
|
|
|
|
savoir comment d<>sactiver le keep-alive HTTP.
|
|
|
|
|
|
|
|
|
|
Autres cas ('xx' repr<70>sentant une valeur quelconque <20> ignorer) :
|
|
|
|
|
-1/xx/xx/Tt : le client n'a pas envoy<6F> sa requ<71>te dans le temps imparti ou
|
|
|
|
|
a referm<72> sa connexion sans compl<70>ter la requ<71>te.
|
|
|
|
|
Tq/-1/xx/Tt : la connexion n'a pas pu s'<27>tablir vers le serveur (refus ou
|
|
|
|
|
time-out au bout de Tt-Tq ms).
|
|
|
|
|
Tq/Tc/-1/Tt : le serveur a accept<70> la connexion mais n'a pas r<>pondu dans
|
|
|
|
|
les temps ou bien a referm<72> sa connexion trop t<>t, au bout
|
|
|
|
|
de Tt-(Tq+Tc) ms.
|
|
|
|
|
|
|
|
|
|
4.2.4) Conditions de d<>connexion
|
|
|
|
|
--------------------------------
|
|
|
|
|
Les logs TCP et HTTP fournissent un indicateur de compl<70>tude de la session.
|
|
|
|
|
C'est un champ de 4 caract<63>res (2 en TCP) pr<70>c<EFBFBD>dant la requ<71>te HTTP, indiquant :
|
2005-12-17 12:46:33 +00:00
|
|
|
|
- sur le premier caract<63>re, un code pr<70>cisant le premier <20>v<EFBFBD>nement qui a caus<75>
|
|
|
|
|
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<70>matur<75>e des sessions par le proxy, pour cas d'erreur
|
2005-12-17 23:57:06 +00:00
|
|
|
|
interne, de configuration (ex: filtre d'URL), ou parce qu'un
|
|
|
|
|
contr<74>le de s<>curit<69> a d<>tect<63> une anomalie dans la r<>ponse du
|
|
|
|
|
serveur.
|
2005-12-17 12:46:33 +00:00
|
|
|
|
c : expiration du d<>lai d'attente c<>t<EFBFBD> client : clitimeout
|
|
|
|
|
s : expiration du d<>lai d'attente c<>t<EFBFBD> serveur: srvtimeout et contimeout
|
|
|
|
|
- : terminaison normale.
|
|
|
|
|
|
|
|
|
|
- sur le second caract<63>re, l'<27>tat d'avancement de la session HTTP lors de la
|
|
|
|
|
fermeture :
|
|
|
|
|
|
|
|
|
|
R : terminaison en attendant la r<>ception totale de la requ<71>te du client
|
|
|
|
|
C : terminaison en attendant la connexion vers le serveur
|
2005-12-17 23:57:06 +00:00
|
|
|
|
H : terminaison en traitant les ent<6E>tes du serveur
|
2005-12-17 12:46:33 +00:00
|
|
|
|
D : terminaison durant le transfert des donn<6E>es du serveur vers le client
|
|
|
|
|
L : terminaison durant le transfert des derni<6E>res donn<6E>es du proxy vers
|
|
|
|
|
le client, alors que le serveur a d<>j<EFBFBD> fini.
|
|
|
|
|
- : terminaison normale, apr<70>s fin de transfert des donn<6E>es
|
|
|
|
|
|
|
|
|
|
- le troisi<73>me caract<63>re indique l'<27>ventuelle identification d'un cookie de
|
2005-12-17 13:12:23 +00:00
|
|
|
|
persistence (uniquement en mode HTTP) :
|
2005-12-17 12:46:33 +00:00
|
|
|
|
|
|
|
|
|
N : aucun cookie de persistence n'a <20>t<EFBFBD> pr<70>sent<6E>.
|
|
|
|
|
I : le client a pr<70>sent<6E> un cookie ne correspondant <20> aucun serveur
|
|
|
|
|
connu.
|
|
|
|
|
D : le client a pr<70>sent<6E> un cookie correspondant <20> un serveur hors
|
|
|
|
|
d'usage. Suivant l'option 'persist', il a <20>t<EFBFBD> renvoy<6F> vers un
|
|
|
|
|
autre serveur ou a tout de m<>me tent<6E> de se connecter sur celui
|
|
|
|
|
correspondant au cookie.
|
|
|
|
|
V : le client a pr<70>sent<6E> un cookie valide et a pu se connecter au
|
|
|
|
|
serveur correspondant.
|
|
|
|
|
- : non appliquable
|
|
|
|
|
|
|
|
|
|
- le dernier caract<63>re indique l'<27>ventuel traitement effectu<74> sur un cookie de
|
2005-12-17 13:12:23 +00:00
|
|
|
|
persistence retrourn<72> par le serveur (uniquement en mode HTTP) :
|
2005-12-17 12:46:33 +00:00
|
|
|
|
|
|
|
|
|
N : aucun cookie de persistence n'a <20>t<EFBFBD> fourni par le serveur.
|
2005-12-17 13:10:59 +00:00
|
|
|
|
P : un cookie de persistence a <20>t<EFBFBD> fourni par le serveur et transmis
|
|
|
|
|
tel quel.
|
2005-12-17 12:46:33 +00:00
|
|
|
|
I : aucun cookie n'a <20>t<EFBFBD> fourni par le serveur, il a <20>t<EFBFBD> ins<6E>r<EFBFBD> par le
|
|
|
|
|
proxy.
|
|
|
|
|
D : le cookie pr<70>sent<6E> par le serveur a <20>t<EFBFBD> supprim<69> par le proxy pour
|
|
|
|
|
ne pas <20>tre retourn<72> au client.
|
|
|
|
|
R : le cookie retourn<72> par le serveur a <20>t<EFBFBD> modifi<66> par le proxy.
|
|
|
|
|
- : non appliquable
|
|
|
|
|
|
2005-12-17 12:41:01 +00:00
|
|
|
|
Le mot cl<63> "capture" permet d'ajouter dans des logs HTTP des informations
|
|
|
|
|
captur<EFBFBD>es dans les <20>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<70>fixe_cookie> len <longueur_capture>
|
|
|
|
|
|
|
|
|
|
Le premier cookie dont le nom commencera par <pr<70>fixe_cookie> sera captur<75>, et
|
|
|
|
|
transmis sous la forme "NOM=valeur", sans toutefois, exc<78>der <longueur_capture>
|
|
|
|
|
caract<EFBFBD>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
|
|
|
|
|
|
2005-12-17 12:46:33 +00:00
|
|
|
|
Dans les logs, le champ pr<70>c<EFBFBD>dant l'indicateur de compl<70>tude contient le cookie
|
|
|
|
|
positionn<EFBFBD> par le serveur, pr<70>c<EFBFBD>d<EFBFBD> du cookie positionn<6E> par le client. Chacun de
|
|
|
|
|
ces champs est remplac<61> par le signe "-" lorsqu'aucun cookie n'est fourni par le
|
|
|
|
|
client ou le serveur.
|
2005-12-17 12:41:01 +00:00
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
4.2.5) Exemples de logs
|
|
|
|
|
-----------------------
|
|
|
|
|
- haproxy[674]: 127.0.0.1:33319 [15/Oct/2003:08:31:57] relais-http Srv1 6559/7/147/6723 200 243 - - ---- "HEAD / HTTP/1.0"
|
|
|
|
|
=> requ<71>te longue (6.5s) saisie <20> la main avec un client telnet. Le serveur a
|
|
|
|
|
r<>pondu en 147 ms et la session s'est termin<69>e normalement ('----')
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/+30 200 +243 - - ---- "GET /image.iso HTTP/1.0"
|
|
|
|
|
=> requ<71>te pour un long transfert. L'option 'logasap' <20>tait sp<73>cifi<66>e donc le
|
|
|
|
|
log a <20>t<EFBFBD> g<>n<EFBFBD>r<EFBFBD> juste avant le transfert de donn<6E>es. Le serveur a r<>pondu
|
|
|
|
|
en 14 ms, 243 octets d'ent<6E>tes ont <20>t<EFBFBD> transf<73>r<EFBFBD>s au client, et le temps
|
|
|
|
|
total entre l'accept() et le premier octet de donn<6E>e est de 30 ms.
|
|
|
|
|
|
|
|
|
|
- haproxy[674]: 127.0.0.1:33320 [15/Oct/2003:08:32:17] relais-http Srv1 9/7/14/30 502 243 - - PH-- "GET /cgi-bin/bug.cgi? HTTP/1.0"
|
|
|
|
|
=> le proxy a bloqu<71> une r<>ponse du serveur soit <20> cause d'un filtre 'rspdeny'
|
|
|
|
|
ou 'rspideny', soit parce qu'il a d<>tect<63> un risque de fuite sensible
|
|
|
|
|
d'informations risquant d'<27>tre cach<63>es. Dans ce cas, la r<>ponse est
|
|
|
|
|
remplac<61>e par '502 bad gateway'.
|
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
- haproxy[18113]: 127.0.0.1:34548 [15/Oct/2003:15:18:55] relais-http <NOSRV> -1/-1/-1/8490 -1 0 - - CR-- ""
|
|
|
|
|
=> Le client n'a pas envoy<6F> sa requ<71>te et a referm<72> la connexion lui-m<>me
|
|
|
|
|
('C---') au bout de 8.5s, alors que le relais attendait l'ent<6E>te ('-R--').
|
|
|
|
|
Aucune connexion n'a <20>t<EFBFBD> envoy<6F>e vers le serveur.
|
|
|
|
|
|
|
|
|
|
- haproxy[18113]: 127.0.0.1:34549 [15/Oct/2003:15:19:06] relais-http <NOSRV> -1/-1/-1/50001 408 0 - - cR-- ""
|
|
|
|
|
=> Le client n'a pas envoy<6F> sa requ<71>te et son time-out a expir<69> ('c---') au
|
|
|
|
|
bout de 50s, alors que le relais attendait l'ent<6E>te ('-R--'). Aucune
|
|
|
|
|
connexion n'a <20>t<EFBFBD> envoy<6F>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<EFBFBD> client ('c----') au bout
|
|
|
|
|
de 5s.
|
|
|
|
|
|
|
|
|
|
- haproxy[18989]: 10.0.0.1:34552 [15/Oct/2003:15:26:31] relais-http Srv1 3183/-1/-1/11215 503 0 - - SC-- "HEAD / HTTP/1.0"
|
|
|
|
|
=> La requ<71>te client met 3s <20> entrer (peut-<2D>tre un probl<62>me r<>seau), et la
|
|
|
|
|
connexion ('SC--') vers le serveur <20>choue au bout de 4 tentatives de 2
|
|
|
|
|
secondes (retries 3 dans la conf), puis un code 503 est retourn<72> au client.
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
4.3) Modification des ent<6E>tes HTTP
|
|
|
|
|
----------------------------------
|
|
|
|
|
En mode HTTP uniquement, il est possible de remplacer certains en-t<>tes dans la
|
|
|
|
|
requ<EFBFBD>te et/ou la r<>ponse <20> partir d'expressions r<>guli<6C>res. Il est <20>galement
|
|
|
|
|
possible de bloquer certaines requ<71>tes en fonction du contenu des en-t<>tes ou de
|
|
|
|
|
la requ<71>te. Une limitation cependant : les en-t<>tes fournis au milieu de
|
|
|
|
|
connexions persistentes (keep-alive) ne sont pas vus car ils sont consid<69>r<EFBFBD>s
|
|
|
|
|
comme faisant partie des <20>changes de donn<6E>es cons<6E>cutifs <20> la premi<6D>re requ<71>te.
|
|
|
|
|
Les donn<6E>es ne sont pas affect<63>es, ceci ne s'applique qu'aux en-t<>tes.
|
|
|
|
|
|
|
|
|
|
La syntaxe est :
|
|
|
|
|
reqadd <string> pour ajouter un en-t<>te dans la requ<71>te
|
|
|
|
|
reqrep <search> <replace> pour modifier la requ<71>te
|
|
|
|
|
reqirep <search> <replace> idem sans distinction majuscules/minuscules
|
|
|
|
|
reqdel <search> pour supprimer un en-t<>te dans la requ<71>te
|
|
|
|
|
reqidel <search> idem sans distinction majuscules/minuscules
|
2005-12-17 12:46:33 +00:00
|
|
|
|
reqallow <search> autoriser la requ<71>te si un ent<6E>te valide <search>
|
2005-12-17 12:10:27 +00:00
|
|
|
|
reqiallow <search> idem sans distinction majuscules/minuscules
|
2005-12-17 12:46:33 +00:00
|
|
|
|
reqdeny <search> interdire la requ<71>te si un ent<6E>te valide <search>
|
2005-12-17 12:14:35 +00:00
|
|
|
|
reqideny <search> idem sans distinction majuscules/minuscules
|
2005-12-17 12:46:33 +00:00
|
|
|
|
reqpass <search> inhibe ces actions sur les ent<6E>tes validant <search>
|
|
|
|
|
reqipass <search> idem sans distinction majuscules/minuscules
|
2005-12-17 12:10:27 +00:00
|
|
|
|
|
2005-12-17 12:46:33 +00:00
|
|
|
|
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
|
2005-12-17 23:57:06 +00:00
|
|
|
|
rspdeny <search> remplace la r<>ponse par un HTTP 502 si un
|
|
|
|
|
ent<6E>te valide <search>
|
|
|
|
|
rspideny <search> idem sans distinction majuscules/minuscules
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 12:46:33 +00:00
|
|
|
|
<search> est une expression r<>guli<6C>re compatible POSIX regexp supportant le
|
|
|
|
|
groupage par parenth<74>ses (sans les '\'). Les espaces et autres s<>parateurs
|
|
|
|
|
doivent <20>tres pr<70>c<EFBFBD>d<EFBFBD>s d'un '\' pour ne pas <20>tre confondus avec la fin de la
|
|
|
|
|
cha<EFBFBD>ne. De plus, certains caract<63>res sp<73>ciaux peuvent <20>tre pr<70>c<EFBFBD>d<EFBFBD>s d'un
|
|
|
|
|
backslach ('\') :
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
\t pour une tabulation
|
|
|
|
|
\r pour un retour charriot
|
|
|
|
|
\n pour un saut de ligne
|
|
|
|
|
\ pour diff<66>rencier un espace d'un s<>parateur
|
|
|
|
|
\# pour diff<66>rencier un di<64>se d'un commentaire
|
2005-12-17 12:46:33 +00:00
|
|
|
|
\\ pour utiliser un backslash dans la regex
|
|
|
|
|
\\\\ pour utiliser un backslash dans le texte
|
2005-12-17 11:48:26 +00:00
|
|
|
|
\xXX pour un caract<63>re sp<73>cifique XX (comme en C)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<replace> contient la cha<68>ne rempla<6C>ant la portion v<>rifi<66>e par l'expression.
|
|
|
|
|
Elle peut inclure les caract<63>res sp<73>ciaux ci-dessus, faire r<>f<EFBFBD>rence <20> un
|
|
|
|
|
groupe d<>limit<69> par des parenth<74>ses dans l'expression r<>guli<6C>re, par sa
|
|
|
|
|
position num<75>rale. Les positions vont de 1 <20> 9, et sont cod<6F>es par un '\'
|
|
|
|
|
suivi du chiffre d<>sir<69>. Il est <20>galement possible d'ins<6E>rer un caract<63>re non
|
|
|
|
|
imprimable (utile pour le saut de ligne) inscrivant '\x' suivi du code
|
|
|
|
|
hexad<EFBFBD>cimal de ce caract<63>re (comme en C).
|
|
|
|
|
|
|
|
|
|
<string> repr<70>sente une cha<68>ne qui sera ajout<75>e syst<73>matiquement apr<70>s la
|
2005-12-17 12:10:27 +00:00
|
|
|
|
derni<EFBFBD>re ligne d'en-t<>te.
|
2005-12-17 11:48:26 +00:00
|
|
|
|
|
|
|
|
|
Remarques :
|
2005-12-17 13:10:59 +00:00
|
|
|
|
-----------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
- la premi<6D>re ligne de la requ<71>te et celle de la r<>ponse sont trait<69>es comme
|
2005-12-17 12:10:27 +00:00
|
|
|
|
des en-t<>tes, ce qui permet de r<><72>crire des URL et des codes d'erreur.
|
2005-12-17 11:48:26 +00:00
|
|
|
|
- 'reqrep' est l'<27>quivalent de 'cliexp' en version 1.0, et 'rsprep' celui de
|
|
|
|
|
'srvexp'. Ces noms sont toujours support<72>s mais d<>conseill<6C>s.
|
|
|
|
|
- pour des raisons de performances, le nombre total de caract<63>res ajout<75>s sur
|
2005-12-17 11:58:00 +00:00
|
|
|
|
une requ<71>te ou une r<>ponse est limit<69> <20> 4096 depuis la version 1.1.5 (cette
|
|
|
|
|
limite <20>tait <20> 256 auparavant). Cette valeur est modifiable dans le code.
|
|
|
|
|
Pour un usage temporaire, on peut gagner de la place en supprimant quelques
|
|
|
|
|
ent<6E>tes inutiles avant les ajouts.
|
2005-12-17 23:57:06 +00:00
|
|
|
|
- une requ<71>te bloqu<71>e produira une r<>ponse "HTTP 403 forbidden" tandis qu'une
|
|
|
|
|
r<>ponse bloqu<71>e produira une r<>ponse "HTTP 502 Bad gateway".
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 11:48:26 +00:00
|
|
|
|
Exemples :
|
2005-12-17 13:10:59 +00:00
|
|
|
|
----------
|
|
|
|
|
###### 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
|
2005-12-17 12:10:27 +00:00
|
|
|
|
reqirep ^Proxy-Connection:.* Proxy-Connection:\ close
|
2005-12-17 13:10:59 +00:00
|
|
|
|
# rewrite locations
|
2005-12-17 12:10:27 +00:00
|
|
|
|
rspirep ^(Location:\ )([^:]*://[^/]*)(.*) \1\3
|
2005-12-17 13:10:59 +00:00
|
|
|
|
|
|
|
|
|
###### 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\?)
|
|
|
|
|
|
|
|
|
|
# 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
|
2005-12-17 23:57:06 +00:00
|
|
|
|
option httpclos
|
2005-12-17 13:10:59 +00:00
|
|
|
|
|
|
|
|
|
# change the server name
|
|
|
|
|
rspidel ^Server:\
|
|
|
|
|
rspadd Server:\ Formilux/0.1.8
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
De plus, l'option 'forwardfor' ajoute l'adresse IP du client dans un champ
|
2005-12-17 13:12:23 +00:00
|
|
|
|
'X-Forwarded-For' de la requ<71>te, ce qui permet <20> un serveur web final de
|
|
|
|
|
conna<EFBFBD>tre l'adresse IP du client initial.
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
Enfin, l'option 'httpclose' apparue dans la version 1.1.28/1.2.1 supprime tout
|
|
|
|
|
ent<EFBFBD>te de type 'Connection:' et ajoute 'Connection: close' dans les deux sens.
|
|
|
|
|
Ceci simplifie la d<>sactivation du keep-alive HTTP par rapport <20> l'ancienne
|
|
|
|
|
m<EFBFBD>thode impliquant 4 r<>gles.
|
|
|
|
|
|
2005-12-17 13:12:23 +00:00
|
|
|
|
Exemple :
|
|
|
|
|
---------
|
|
|
|
|
listen http_proxy 0.0.0.0:80
|
|
|
|
|
mode http
|
|
|
|
|
log global
|
|
|
|
|
option httplog
|
|
|
|
|
option dontlognull
|
|
|
|
|
option forwardfor
|
2005-12-17 23:57:06 +00:00
|
|
|
|
option httpclose
|
2005-12-17 13:12:23 +00:00
|
|
|
|
|
2005-12-17 12:10:27 +00:00
|
|
|
|
4.4) R<>partition avec persistence
|
|
|
|
|
---------------------------------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
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<6E>re
|
|
|
|
|
pratiquement transparente pour les applications. Le principe est simple :
|
2005-12-17 12:11:56 +00:00
|
|
|
|
- attribuer une valeur d'un cookie <20> chaque serveur
|
2005-12-17 11:48:26 +00:00
|
|
|
|
- effectuer une r<>partition interne
|
2005-12-17 12:14:35 +00:00
|
|
|
|
- ins<6E>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 <20> l'application lors des requ<71>tes ult<6C>rieures.
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 11:48:26 +00:00
|
|
|
|
Exemple :
|
2005-12-17 12:41:01 +00:00
|
|
|
|
---------
|
2005-12-17 11:48:26 +00:00
|
|
|
|
listen application 0.0.0.0:80
|
|
|
|
|
mode http
|
2005-12-17 12:14:35 +00:00
|
|
|
|
cookie SERVERID insert nocache indirect
|
2005-12-17 11:48:26 +00:00
|
|
|
|
balance roundrobin
|
|
|
|
|
server 192.168.1.1:80 cookie server01 check
|
|
|
|
|
server 192.168.1.2:80 cookie server02 check
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
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 <20>t<EFBFBD> cr<63><72>e.
|
|
|
|
|
Elle sert <20> inspecter minutieusement les ent<6E>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<EFBFBD> client. Quand cette option est activ<69>e, les
|
|
|
|
|
seules r<>ponses qui peuvent <20>tre retourn<72>es au client sont :
|
|
|
|
|
- toutes celles qui n'ont pas d'ent<6E>te 'Set-cookie' ;
|
|
|
|
|
- toutes celles qui ont un code de retour autre que 200, 203, 206, 300, 301,
|
|
|
|
|
410, sauf si le server a positionn<6E> un ent<6E>te 'Cache-control: public' ;
|
|
|
|
|
- celles qui font suite <20> une requ<71>te POST, sauf si le serveur a positionn<6E>
|
|
|
|
|
un ent<6E>te 'Cache-control: public' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Pragma: no-cache' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: private' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: no-store' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: max-age=0' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: s-maxage=0' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: no-cache' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: no-cache="set-cookie"' ;
|
|
|
|
|
- celles qui ont un ent<6E>te 'Cache-control: no-cache="set-cookie,'
|
|
|
|
|
(autorisant d'autres champs apr<70>s set-cookie).
|
|
|
|
|
|
|
|
|
|
Si une r<>ponse ne respecte pas ces pr<70>-requis, alors elle sera bloqu<71>e de la
|
|
|
|
|
m<EFBFBD>me mani<6E>re que s'il s'agissait d'un filtre 'rspdeny', avec en retour un
|
|
|
|
|
message "HTTP 502 bad gateway". L'<27>tat de session montre "PH--" ce qui veut
|
|
|
|
|
dire que c'est le proxy qui a bloqu<71> la r<>ponse durant le traitement des
|
|
|
|
|
ent<EFBFBD>tes. De plus, un message d'alerte sera envoy<6F> dans les logs de sorte que
|
|
|
|
|
l'administrateur sache qu'il y a une action correctrice <20> entreprendre.
|
|
|
|
|
|
|
|
|
|
4.6) Personalisation des erreurs
|
2005-12-17 12:41:01 +00:00
|
|
|
|
--------------------------------
|
|
|
|
|
Certaines situations conduisent <20> retourner une erreur HTTP au client :
|
|
|
|
|
- requ<71>te invalide ou trop longue => code HTTP 400
|
|
|
|
|
- requ<71>te mettant trop de temps <20> venir => code HTTP 408
|
|
|
|
|
- requ<71>te interdite (bloqu<71>e par un reqideny) => code HTTP 403
|
|
|
|
|
- erreur interne du proxy => code HTTP 500
|
|
|
|
|
- le serveur a retourn<72> une r<>ponse incompl<70>te ou invalide => code HTTP 502
|
|
|
|
|
- aucun serveur disponible pour cette requ<71>te => code HTTP 503
|
|
|
|
|
- le serveur n'a pas r<>pondu dans le temps imparti => code HTTP 504
|
|
|
|
|
|
|
|
|
|
Un message d'erreur succint tir<69> de la RFC accompagne ces codes de retour.
|
|
|
|
|
Cependant, en fonction du type de client<6E>le, on peut pr<70>f<EFBFBD>rer retourner des
|
|
|
|
|
pages personnalis<69>es. Ceci est possible par le biais de la commande "errorloc" :
|
|
|
|
|
|
|
|
|
|
errorloc <code_HTTP> <location>
|
|
|
|
|
|
|
|
|
|
Au lieu de g<>n<EFBFBD>rer une erreur HTTP <code_HTTP> parmi les codes cit<69>s ci-dessus,
|
|
|
|
|
le proxy g<>n<EFBFBD>rera un code de redirection temporaire (HTTP 302) vers l'adresse
|
|
|
|
|
d'une page pr<70>cis<69>e dans <location>. Cette adresse peut <20>tre relative au site,
|
|
|
|
|
ou absolue. Comme cette r<>ponse est tra<72>t<EFBFBD>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
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
4.7) Changement des valeurs par d<>faut
|
2005-12-17 13:02:24 +00:00
|
|
|
|
--------------------------------------
|
|
|
|
|
Dans la version 1.1.22 est apparue la notion de valeurs par d<>faut, ce qui <20>vite
|
|
|
|
|
de r<>p<EFBFBD>ter des param<61>tres communs <20> toutes les instances, tels que les timeouts,
|
|
|
|
|
adresses de log, modes de fonctionnement, etc.
|
|
|
|
|
|
|
|
|
|
Les valeurs par d<>faut sont positionn<6E>es dans la derni<6E>re section 'defaults'
|
|
|
|
|
pr<EFBFBD>c<EFBFBD>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<70>sence d'une telle
|
|
|
|
|
section implique une annulation de tous les param<61>tres par d<>faut positionn<6E>s
|
|
|
|
|
pr<EFBFBD>c<EFBFBD>demment, dans le but de les remplacer.
|
|
|
|
|
|
|
|
|
|
La section 'defaults' utilise la m<>me syntaxe que la section 'listen', aux
|
|
|
|
|
param<EFBFBD>tres pr<70>s qui ne sont pas support<72>s. Le mot cl<63> 'defaults' peut accepter
|
|
|
|
|
un commentaire en guise param<61>tre.
|
|
|
|
|
|
2005-12-17 23:57:06 +00:00
|
|
|
|
Dans la version 1.1.28/1.2.1, seuls les param<61>tres suivants peuvent <20>tre
|
|
|
|
|
positionn<EFBFBD>s dans une section 'defaults' :
|
2005-12-17 13:02:24 +00:00
|
|
|
|
- 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<6F>ration inverse, mais c'est le cas par d<>faut)
|
|
|
|
|
- contimeout, clitimeout, srvtimeout, grace, retries, maxconn
|
2005-12-17 23:57:06 +00:00
|
|
|
|
- option { redispatch, transparent, keepalive, forwardfor, logasap, httpclose,
|
|
|
|
|
checkcache, httplog, tcplog, dontlognull, persist, httpchk }
|
2005-12-17 13:02:24 +00:00
|
|
|
|
- redispatch, redisp, transparent, source { addr:port }
|
|
|
|
|
- cookie, capture
|
|
|
|
|
- errorloc
|
2005-12-17 13:08:03 +00:00
|
|
|
|
|
|
|
|
|
Ne sont pas support<72>s dans cette version, les adresses de dispatch et les
|
|
|
|
|
configurations de serveurs, ainsi que tous les filtres bas<61>s sur les
|
|
|
|
|
expressions r<>guli<6C>res :
|
|
|
|
|
- dispatch, server,
|
2005-12-17 13:10:59 +00:00
|
|
|
|
- req*, rsp*
|
2005-12-17 13:02:24 +00:00
|
|
|
|
|
|
|
|
|
Enfin, il n'y a pas le moyen, pour le moment, d'invalider un param<61>tre bool<6F>en
|
|
|
|
|
positionn<EFBFBD> par d<>faut. Donc si une option est sp<73>cifi<66>e dans les param<61>tres par
|
|
|
|
|
d<EFBFBD>faut, le seul moyen de la d<>sactiver pour une instance, c'est de changer les
|
|
|
|
|
param<EFBFBD>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<61>tes par d<>faut.
|
2005-12-17 12:41:01 +00:00
|
|
|
|
|
2005-12-17 11:55:07 +00:00
|
|
|
|
=======================
|
|
|
|
|
| Param<61>trage syst<73>me |
|
|
|
|
|
=======================
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
|
|
|
|
Sous Linux 2.4
|
|
|
|
|
==============
|
|
|
|
|
|
2005-12-17 11:55:07 +00:00
|
|
|
|
-- 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
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
echo 1024 60999 > /proc/sys/net/ipv4/ip_local_port_range
|
2005-12-17 11:55:07 +00:00
|
|
|
|
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
|
|
|
|
|
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
|
2005-12-17 11:21:26 +00:00
|
|
|
|
echo 262144 > /proc/sys/net/ipv4/tcp_max_tw_buckets
|
2005-12-17 11:55:07 +00:00
|
|
|
|
echo 262144 > /proc/sys/net/ipv4/tcp_max_orphans
|
|
|
|
|
echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time
|
2005-12-17 11:21:26 +00:00
|
|
|
|
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
|
|
|
|
|
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
|
2005-12-17 11:48:26 +00:00
|
|
|
|
echo 0 > /proc/sys/net/ipv4/tcp_ecn
|
2005-12-17 11:55:07 +00:00
|
|
|
|
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 --
|
2005-12-17 11:21:26 +00:00
|
|
|
|
|
2005-12-17 13:10:59 +00:00
|
|
|
|
Sous FreeBSD
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
Un port de HA-Proxy sous FreeBSD est d<>sormais disponible, gr<67>ce <20>
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
2005-12-17 11:21:26 +00:00
|
|
|
|
-- fin --
|