[Précédent : Gestion de La Bande Passante] [Index] [Suivant : Balisage de Paquets]

Pools d'Adresses et Partage de Charge

Table des Matières

• Introduction
• Pools d'Adresses NAT
• Partage de Charge Des Connexions Entrantes
• Partage de Charge Des Connexions Sortantes
  • Exemple de Base de Règles

Introduction

Il existe quatre méthodes pour utiliser un pool d'adresses :

• bitmask - supprime la partie réseau d'une adresse IP (adresse utilisée comme adresse source dans des règles nat ou adresse destination dans des règles rdr) et la remplace avec la partie réseau de l'adresse correspondante du pool d'adresses. Exemple : si l'adresse du pool est 192.0.2.1/24 et l'adresse à modifier est la 10.0.0.50, l'adresse correspondante au niveau du pool est la 192.0.2.50. Si le pool d'adresses est le bloc 192.0.2.1/25 et l'adresse à modifier est la 10.0.0.130, alors l'adresse correspondante au niveau du pool est la 192.0.2.2.
• random - sélectionne aléatoirement une adresse du pool.
• source-hash - utilise un hash de l'adresse source pour choisir l'adresse du pool à utiliser. Cette méthode permet de garantir qu'une adresse source donnée sera toujours associée avec la même adresse du pool. La clé avec laquelle est alimenté l'algorithme de hachage peut être spécifiée en option après le mot-clé source-hash au format hex ou chaîne de caractères. Par défaut, pfctl(8) va générer une clé aléatoire à chaque fois que la base de règles est chargée.
• round-robin - attribue les adresses du pool séquentiellement. C'est la méthode par défaut et c'est aussi la seule méthode autorisée lorsque le pool d'adresses est spécifié en utilisant une table.

Dans tous les cas, à l'exception notable de la méthode round-robin, le pool d'adresses doit être spécifié sous forme d'un bloc réseau en notation CIDR (Classless Inter-Domain Routing). La méthode round-robin accepte des adresses individuelles à partir d'une liste ou d'une table.

L'option sticky-address peut être utilisée conjointement avec les types de pool random et round- robin afin de s'assurer qu'à une adresse source donnée corresponde toujours la même adresse de redirection.

Pools d'Adresses NAT

Dans l'exemple suivant, un pool de deux adresses est utilisé pour traduire les paquets sortants. Pour chaque connexion sortante, PF fera une attribution séquentielle avec rotation selon la méthode round-robin.

nat on $ext_if inet from any to any -> { 192.0.2.5, 192.0.2.10 }

Cependant, cette méthode a un inconvénient. En effet, des connexions successives à partir de la même adresse interne ne seront pas toujours traduites avec la même adresse de traduction. Ceci peut causer des interférences lors, par exemple, de la navigation sur des sites web qui utilisent les adresses IP comme éléments d'identification des utilisateurs. Une approche alternative consiste à utiliser la méthode source- hash. Ainsi, chaque adresse interne est toujours traduite avec la même adresse de traduction. Dans ce cas, le pool d'adresses doit être obligatoirement un bloc réseau en notation CIDR.

nat on $ext_if inet from any to any -> 192.0.2.4/31 source-hash

Cette règle de nat utilise le pool d'adresses 192.0.2.4/31 (192.0.2.4 - 192.0.2.5) comme adresse de traduction de paquets sortants. Chaque adresse interne sera toujours traduite avec la même adresse de traduction grâce au mot-clé source-hash.

Partage de Charge Des Connexions Entrantes

web_servers = "{ 10.0.0.10, 10.0.0.11, 10.0.0.13 }"

rdr on $ext_if proto tcp from any to any port 80 -> $web_servers \
    round-robin sticky-address

Les connexions successives seront redirigées vers les serveurs web selon la méthode round-robin : les connexions à partir de la même adresse source seront toujours envoyés au même serveur web. Cette connexion "collante" ("sticky") existera aussi longtemps qu'il y aura des états faisant référence à cette connexion. Une fois les états expirés, la connexion collante expirera aussi. Les futures connexions à partir de ce hôte seront redirigés vers le prochain serveur dans le round robin.

Partage de Charge Des Connexions Sortantes

Pour que le partage de charge fonctionne, il faut aussi connaître l'adresse IP du routeur adjacent sur chaque connexion Internet. Ces informations sont données à l'option route-to afin de contrôler la destination des paquets sortants.

L'exemple suivant partage le trafic sortant entre deux connexions Internet :

lan_net = "192.168.0.0/24"
int_if  = "dc0"
ext_if1 = "fxp0"
ext_if2 = "fxp1"
ext_gw1 = "68.146.224.1"
ext_gw2 = "142.59.76.1"

pass in on $int_if route-to \
   { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
   from $lan_net to any keep state

L'option route-to est utilisée pour le trafic entrant sur l'interface interne afin de spécifier les interfaces réseau sur lesquelles le trafic sortant doit être partagé ainsi que les passerelles respectives de chaque interface réseau. Il est à noter que l'option route-to doit être présente dans chaque règle de filtrage pour laquelle le trafic doit être équilibré. Les paquets de retour seront acheminés vers la même interface externe à partir de laquelle les paquets d'origine sont ressortis (c'est ce qui est effectué par les FAIs). Ces paquets de retour seront ensuite acheminés vers l'interface du réseau interne normalement.

Pour s'assurer que les paquets avec une adresse source appartenant à $ext_if1 sont toujours acheminés vers $ext_gw1 (et, de même, pour $ext_if2 et $ext_gw2), les deux lignes suivantes doivent être incluses dans le jeu de règles :

pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \
   to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \
   to any

Enfin, la NAT peut aussi être utilisée sur chaque interface de sortie :

nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

Voici un exemple complet d'équilibrage de charge du trafic sortant :

[Précédent : Mise en Queue des Paquets et Gestion des Priorités] [Index] [Suivant : Balisage de Paquets]