GuiguiAbloc

Outch, la, on cumule

Dans les précédentes aventures du Blog, je vous avais fait part de mon “acquisition” de 2 routeurs Cisco 3620.

Après avoir fait un peu “mumuse” avec (ah la la, les geeks et leurs joujoux…) il était temps de les racker dans ma baie et surtout de repenser un peu l’architecture de mon LAN.

Je vous propose donc aujourd’hui un billet un peu “rigolo” sur les technos Cisco mais surtout, comment appliquer en quelques minutes des configurations que vous avez de très fortes chances de rencontrer dans un réseau d’entreprise.

Je ne détaillerais pas en nombreuses lignes le principe de fonctionnement des technologies mises en oeuvre (je vous laisse surfer sur le Nain Ternet pour plus de détails, ou, si vous le souhaitez, je pourrais m’attarder sur l’une d’entre elles sur un autre billet), mais je vous expliquerais l’essentiel (je pense) pour les utiliser.

D’ailleurs, je vous invite à farfouiller cet excellent site qui regorge de détails sur les technologies Cisco :

http://cisco.goffinet.org/

Bon, une tasse de café/guronsan/doliprane prête ? Les onglets sur YouPorn YouTube, P0rno.org AFP.com fermés ? On se concentre, et on y va.

(<privatejoke> Fred me susurre de se détendre avant l’effort, donc, oui, Fred, un peu de Karen Cheryl avant tout </privatejoke>)

• Etats des lieux

Le rackage est achevé et la baie réseau de la maison ressemble à cela actuellement :

Baie Guiguiabloc

Donc une architecture normale de particulier…

Mon switch Cisco Catalyst commencant a être saturé, il est temps de mettre en fonction le catalyst 2950 qui me servait de Spare en cas de panne.

Pour schématiser ce que nous allons mettre en place, voici a quoi ressemble les branchements dans la baie (provisoirement il s’entend )

La liaison entre les deux switchs se fait par câbles réseaux croisés (dans mon cas, j’en utilise deux), que je vais agréger dans un etherchannel.

• ETHERCHANNEL

L’etherchannel est une technique d’interconnexion LAN entre switches (ou routeurs bien sûr) pour offrir sur un seul lien logique, plusieurs ports Fast ou Gigabit Ethernert.

Non seulement cela vous permet de créer une redondance en cas de panne d’une interface mais également d’agréger le débit disponible et/ou de faire de l’équilibrage de charge.

Sous Linux, vous trouverez cette technique sous le nom de “Channel Bonding” ou “Teaming” sous l’OS SALE.

La syntaxe entre le 2924 et le 2950 est différente, donc adaptons nous :

sw-2924 :

interface FastEthernet0/21
description --- portchannel sw-2950 fa 0/21 ---
duplex full
speed 100
port group 1 distribution destination
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface FastEthernet0/22
description --- portchannel sw-2950 fa 0/22 ---
duplex full
speed 100
port group 1 distribution destination
switchport trunk encapsulation dot1q
switchport mode trunk
 
sw-2924#sh port group 1
Group  Interface              Transmit Distribution
-----  ---------------------  ---------------------
1  FastEthernet0/21       destination address
1  FastEthernet0/22       destination address

sw-2950 :

interface Port-channel1
switchport mode trunk
speed 100
duplex full
flowcontrol send off
 
interface FastEthernet0/21
description --- port-channel sw-2924 fa 0/21 ---
switchport mode trunk
speed 100
duplex full
no cdp enable
channel-group 1 mode on
!
interface FastEthernet0/22
description --- portchannel sw-2924 fa 0/22 ---
switchport mode trunk
speed 100
duplex full
no cdp enable
channel-group 1 mode on
 
sw-2950#sh interfaces port-channel 1 status
 
Port      Name               Status       Vlan       Duplex  Speed Type
Po1                          connected    trunk        full    100
 
sw-2950#sh interfaces port-channel 1 etherchannel
Age of the Port-channel   = 0d:00h:21m:02s
Logical slot/port   = 1/0          Number of ports = 2
GC                  = 0x00000000      HotStandBy port = null
Port state          = Port-channel Ag-Inuse
Protocol            =    -
 
Ports in the Port-channel:
 
Index   Load   Port     EC state        No of bits
------+------+------+------------------+-----------
0     00     Fa0/21   On/FEC             0
0     00     Fa0/22   On/FEC             0

Voila pour la partie liaison redondante des deux switches.

NB: Pour les puristes, je suis en mode “on” (etherchannel) car c’est le seul mode que comprend le 2924, bien évidemment, sur des gammes supérieures, essayez le mode active/passive/auto ou desirable suivant le protocole que vous souhaitez utiliser (LACP ou PAgP).

• VTP

Comme je l’avais expliqué dans un précédent billet , j’utilise les Vlans dans mon réseau. Afin d’éviter de devoir renseigner les vlans dans chaque switches, nous allons utiliser VTP (Vlan Trunking Procotol), toujours en niveau 2, qui permet de centraliser la base de données des Vlans sur un switch et de le diffuser aux autres du même domaine.

Très pratique mais aussi très dangereux si vous y aller a la légère .

Sur le 2924, je le définis comme “Server” :

sw-2924# vlan database
 
sw-2924# vtp server
 
sw-2924# vtp domain GUIGUIABLOCVTP
 
sw-2924# vtp password weshjesuislepatron
 
sw-2924# sh vtp status
VTP Version                     : 2
Configuration Revision          : 2
Maximum VLANs supported locally : 68
Number of existing VLANs        : 19
VTP Operating Mode              : Server
VTP Domain Name                 : GUIGUIABLOCVTP

Sur le 2950, il va falloir définir VTP en mode client (il existe 3 modes, serveur, client et transparent (ou autonome)).

ATTENTION : le champ “Configuration Revision” du futur client est très important, il faut absolument que sa valeur soit inférieure au “Server” sinon vous risquez de perdre vos vlans ! (expérience connue….).

Donc, première chose à faire, sauvegarder votre vlan.dat :

sw-2924#copy flash:vlan.dat tftp://10.154.12.1
Address or name of remote host [10.154.12.1]?
Destination filename [vlan.dat]?
!!
1396 bytes copied in 0.57 secs

Le plus simple étant de passer le client en mode “Transparent” d’abord, puis “Client” après, ce qui remettra a zéro le numéro de révision.

sw-2950(config)#vtp mode transparent
 
sw-2950#sh vtp status
VTP Version                     : 2
Configuration Revision          : 0
 
sw-2950(config)#vtp mode client
 
sw-2950(config)# vtp domain GUIGUIABLOCVTP
 
sw-2950(config)# vtp password weshjesuislepatron

Après quelques secondes, vous devriez voir les VLANs appris par le client :

sw-2950#sh vtp status
VTP Version                     : 2
Configuration Revision          : 2
Maximum VLANs supported locally : 128
Number of existing VLANs        : 19
VTP Operating Mode              : Client
VTP Domain Name                 : GUIGUIABLOCVTP

Désormais, les ajouts, suppressions, modifications de VLANs ne se feront que sur le 2924, qui les répercuteras sur le 2950.

• OSPF

Ah, ah, ah. Alors là il faudrait quelques heures pour en faire le tour c’est pourquoi je ne vais pas m’attarder en détails. Surtout qu’il existe un excellent article de “Monsieur” hr du GCU-SQUAD dans le Jardin qui vous expliquera tout en détails :

http://www.unixgarden.com/index.php/administration-systeme/routage-dynamique-et-haute-disponibilite-partie-2

Pour résumer très basiquement, OSPF est un protocole de routage IP interne. Chaque routeur communique a ses voisins les réseaux auxquels il est directement connecté. Cette base connue de tous permet ensuite a chaque routeur de déterminer la route la plus courte vers chacun des réseaux. Ce protocole étant dynamique, un changement de route, une perte de lien est apprise en quelques secondes par les autres routeurs qui se chargeront ou de l’assimiler ou de trouver un autre chemin pour se rendre dans le réseau impacté.

Sur mon routeur principal, le 2611, on prépare la conf (les chiffres entre parenthèses vous amènent a l’explication) :

router ospf 1
log-adjacency-changes
area 0 authentication message-digest
redistribute connected metric-type 1 subnets (1)
redistribute static subnets (1)
passive-interface default (2)
no passive-interface FastEthernet0/0.100 (3)
network 10.154.100.0 0.0.0.255 area 0 (4)

(1) J’annonce tous les réseaux sur lesquels je suis directement connecté (également les subnets)

(2) Je désactive OSPF sur toutes les interfaces sauf celles explicitement nommées

(3) Je parle OSPF sur la sub-interface fa 0/0.100

(4) J’annonce le réseau 10.154.100.0/24 en tant qu’area0, réseau qui correspond a mon backbone.

On prépare les deux routeurs 3620 :

rt-3620-a

interface Loopback1
ip address 10.154.13.8 255.255.255.255
 
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
redistribute connected subnets
passive-interface default
no passive-interface FastEthernet0/0.100
network 10.154.100.248 0.0.0.0 area 0

rt-3620-b

interface Loopback1
ip address 10.154.13.9 255.255.255.255
 
router ospf 1
log-adjacency-changes
area 0 authentication message-digest
redistribute connected subnets
passive-interface default
no passive-interface FastEthernet0/0.100
network 10.154.100.249 0.0.0.0 area 0

Roulez jeunesse, le temps que ca converge (quelques secondes) et les routes sont apprises de partout :

rt-2611#sh ip ospf neighbor
 
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.154.13.8       1   FULL/DROTHER    00:00:33    10.154.100.248  FastEthernet0/0.100
10.154.13.9       1   FULL/BDR        00:00:33    10.154.100.249  FastEthernet0/0.100

FULL = nous sommes voisins et échangeons les routes

DROTHER = nous ne sommes ni DR (designated router) ni BDR (backup designated router)

BDR = nous sommes le “backup designated router” de ce réseau

rt-2611# sh ip route
 
...
 
O E2    10.154.13.9/32
[110/20] via 10.154.100.249, 00:00:05, FastEthernet0/0.100
O E2    10.154.13.8/32
[110/20] via 10.154.100.248, 00:00:05, FastEthernet0/0.100
...
 
rt-3620-b#sh ip route
...
 
C       10.154.13.9/32 is directly connected, Loopback1
O E2    10.154.13.8/32
[110/20] via 10.154.100.248, 00:00:40, FastEthernet0/0.100
O E1    10.154.13.1/32
[110/21] via 10.154.100.253, 00:00:40, FastEthernet0/0.100
...

Mouahhh c’est beau

• HSRP

Dernière étape et non la moindre, mise en place d’HSRP.

Le Hot Standby Router Protocol est un protocole propriétaire de Cisco que vous connaissez sûrement sous d’autres noms dans d’autres environnements comme VRRP ou (et surtout), CARP sous *BSD dont je vous ai souvent parler. (ICI ou LA)

Ce protocole permet de “partager” une IP Virtuelle qui sera affectée au routeur “Maitre”. En cas de panne de ce routeur, le routeur “Esclave” s’approprie cette adresse IP et reprend donc la continuité de service.

Pour une solution de continuité de service, c’est quand même ce qu’il se fait de mieux (qui a dit VSS au fond ? :-) )

Nous allons configuré une interface de routage pour le Vlan 600, en 10.154.60.254 que se partageront le rt-3620-a, le Maître en 10.154.60.248 et le rt-3620-b, l’Esclave en 10.154.60.249 dans le groupe 10 (ce n’est qu’un identifiant pour HSRP et ses membres)

rt-3620-a(config)#int fa 0/0.600
rt-3620-a(config-subif)#encapsulation dot1Q 600
rt-3620-a(config-subif)#ip address 10.154.60.248 255.255.255.0
rt-3620-a(config-subif)#standby 10 priority 100
rt-3620-a(config-subif)#standby 10 ip 10.154.60.254
rt-3620-b(config)#int fa 0/0.600
rt-3620-b(config-subif)#encapsulation dot1Q 600
rt-3620-b(config-subif)#ip address 10.154.60.249 255.255.255.0
rt-3620-b(config-subif)#standby 10 priority 80
rt-3620-b(config-subif)#standby ip 10.154.60.254

On vérifie que ca ping :

Guiguiabloc-a:~# ping 10.154.60.254
PING 10.154.60.254 (10.154.60.254) 56(84) bytes of data.
64 bytes from 10.154.60.254: icmp_seq=1 ttl=255 time=1.44 ms
64 bytes from 10.154.60.254: icmp_seq=2 ttl=255 time=1.69 ms

Le traceroute me confirme le routeur Maître :

Guiguiabloc-a:~# traceroute 10.154.60.254
traceroute to 10.154.60.254 (10.154.60.254), 30 hops max, 40 byte packets
1  *
2  10.154.100.248 (10.154.100.248)  7.797 ms * *

Sur le rt-3620-b, on voit que l’interface est en attente :

FastEthernet0/0.600 is up, line protocol is up
Internet protocol processing disabled

Ne reste qu’a couper l’interface pour avoir une bascule transparente

rt-3620-a(config)#int fa 0/0.600
rt-3620-a(config-subif)#shut
Guiguiabloc-a:~# traceroute 10.154.60.254
traceroute to 10.154.60.254 (10.154.60.254), 30 hops max, 40 byte packets
1  *
2  10.154.100.249 (10.154.100.249)  7.705 ms

Magique

Voila donc en “quelques” lignes une approche de diverses techonologies que vous croiserez sûrement dans un LAN d’entreprise.

Il est évident qu’a petite échelle c’est un régal a mettre en place, sur une grosse infra, on est beaucoup plus enclin a réfléchir avant d’appuyer sur la touche “entrée”…

Espérant avoir titiller votre fibre réseau, amusez vous bien

Ah décidément, j’adore faire le tour des bennes à ordures…

C’est quand même fou tout ce que les entreprises jettent. En même temps, je ne vais sûrement pas m’en plaindre

Et donc, pour rejoindre les quelques U restants de ma baie, j’ai récupéré 2 Cisco 3620

Cisco 3620

A moi les joies du HSRP à la maison et autres joyeusetés

En relisant quelques anciens billets, je me suis rendu compte que je n’avais pas abordé précisément la notion de vlan et de trunk dans une architecture réseau.

Corrigeons donc cela rapidement.

Un VLAN est un réseau Virtuel. Dans un réseau local physique, vous pouvez donc mettre en place des réseaux logiques, séparés les uns de autres, on parle alors de “segmentation”.

Pour pouvoir mettre cela en place, il vous faut donc un switch qui supporte cette fonctionnalité.

Si maintenant vous désirez propager plusieurs VLANs sur un même lien physique, il faut configurer un “trunk” et la norme établie est la 802.1q aussi appelé couramment : dot1q.

Pour cela, il faudra que vos paquets soit “taggués”, c’est à dire qu’ils contiennent dans leurs en-têtes le numéro du vlan (VLAN ID) pour lequel ils sont destinés.

(Cisco supporte bien évidemment cette norme sur ses équipements, mais également sa propre norme propriétaire, ISL “Inter Swtich Link”, dont je ne parlerais pas ici).

En situation, nous aurons quelque chose de ressemblant a ceci :

Outre un switch supportant les VLANs, il vous faudra bien évidemment un routeur pour les routages inter-vlan (ou un pc faisant office de routeur).

Bref, a la fin, vous risquez de vous retrouvez avec cela (vous avez de la chance, je vous ouvre les arcanes de mon installation personnelle )

Réseau Perso Guiguiabloc

(Vous trouverez un billet sur la naissance de cette baie ICI )

Les exemples suivants se basent sur un Switch Catalyst 2924 XL et un Routeur 2611-XM, mais ils restent standard pour tout IOS récent (comprendre qui n’a pas 10 ans…)

La création d’un VLAN sur le switch est très simple :

catalyst#vlan database
catalyst(vlan)#vlan 2 name vlan_base_de_donnees
VLAN 2 added:
Name: vlan_base_de_donnees

Sur l’interface du switch où est branché votre pc/serveur, vous définissez alors sur quel VLAN il est relié :

catalyst#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
catalyst(config)#int fastEthernet 0/1
catalyst(config-if)# switchport mode access
catalyst(config-if)# switchport access vlan 2
 
Ce qui donne :
 
interface FastEthernet0/1
 description serveur Mysql
 port block multicast
 switchport access vlan 2
 spanning-tree portfast
 no cdp enable

La variable “switchport access” définit le droit d’accès au VLAN.

Attention : Il existe un VLAN un peu particulier, le VLAN 1, qui est le VLAN de Management des équipements Cisco. Eviter donc d’y mettre des machines accessibles par tous.

Certains recommandent de déplacer le VLAN 1 sur un autre VLAN, personnellement, ça ne m’a pas porté chance de jouer à cela, donc un peu de rigueur suffit en changeant les vlans natifs sur les interfaces.

Sachez que sur le Catalyst 2924, il existe une petite commande sympa et peu documentée :

switchport mode multi
swichport multi vlan 1,2,3

Cela permet a une machine d’accéder à plusieurs VLANs sans avoir à tagguer ses trames.

Dans ce mode de configuration, les machines connectées aux interfaces du switch n’ont pas besoin de tagguer leurs paquets, donc une configuration réseau toute basique (avec en passerelle l’interface définit dans votre routeur par exemple).

La connectivité entre notre routeur et notre switch par contre sera différente.

Nous avons 1 (voire 2) interfaces physiques sur le Cisco 2600 et c’est sur cette interface que nous allons faire passer l’ensemble des VLANs afin de permettre au routeur de… router

Coté Switch :

interface FastEthernet0/2
description Trunk fastEthernet 0/0 rt-2611
duplex full
speed 100
switchport trunk encapsulation dot1q
switchport mode trunk
spanning-tree portfast
no cdp enable

Ici, le mode du switch est “trunk” et l’encapsulation, 802.1q.
Sans spécifications particulières, nous passons l’intégralité des VLANs définis sur le switch sur cette interface.

Vous pouvez bien sur être plus restrictif sur cette configuration :

switchport trunk allowed vlan 2,3   # autorise que l'accès aux VLANS 2 et 3

Attention : Dans ce genre de configuration, un paquet non taggué partira dans le vlan par défaut qui est le VLAN 1.

N’oubliez donc pas d’indiquer explicitement le VLAN par défaut en cas de trames non tagguées :

switchport trunk native vlan 2     # on envoie sur le vlan 2 si pas de tag

Côté Routeur 2600 :

interface FastEthernet0/0.1
encapsulation dot1Q 1 native
ip address 192.168.0.254 255.255.255.0
ip virtual-reassembly
no cdp enable

Il ne vous reste plus qu’a définir vos interfaces “virtuelles” sur votre routeur Cisco :

Pour le VLAN 2 par exemple :

interface FastEthernet0/0.2
encapsulation dot1Q 2
ip address 192.168.2.254 255.255.255.0
no cdp enable

NB : Si vous voulez faire sortir vos machines par votre passerelle générale (exemple le pix :-p) n’oubliez pas les nat inside/outside sur vos interfaces, ainsi que des ACL bien placées.

Côté Linux :

Si vous voulez faire du trunk sur Linux, il suffit d’activer le support 802.1q dans le noyau.

Sous Debian, apt-get install vlan
Sous RedHat, le support est natif

Création de l’interface :

Debian :

vconfig add eth0 2 (pourt créer le VLAN 2)

Modification du fichier /etc/network/interfaces :

 auto eth0.2
 iface eth0.2 inet static
 address 192.168.2.254
 netmask 255.255.255.0
 network 192.168.2.0
 broadcast 192.168.2.255
 vlan_raw_device eth0

RedHat :

Création du fichier /etc/sysconfig/network-scripts/ifcfg-eth0.2

DEVICE=eth0.2
BOOTPROTO=static
HWADDR=XX:XX:XX:XX:XX:XX
IPADDR=192.168.2.254
NETMASK=255.255.255.0
NETWORK=192.168.2.0
ONBOOT=yes
TYPE=Ethernet
VLAN=yes

Rédémarrage des services réseaux bien entendu.

Dans les 2 cas, pour supprimer l’interface, il faudra passer un :

vconfig rem eth0.2

(ps: l’écriture d’un alias d’une interface “vlan” se note : eth0.2:1 par exemple)

Côté OpenBSD :

création du fichier /etc/hostname.vlan2 (vlandev étant votre interface réseau physique)

inet 192.168.2.254 255.255.255.0 vlan 2 vlandev sis0

Sous Windows, ce n’est absolument pas natif, tout dépend de la carte réseau et du pilote du fabricant fourni… (en même temps, qui voudrait faire un routeur avec windows )

Voilà, j’espère que ces explications vous aideront a mettre en oeuvre des VLANs chez vous, et surtout à l’utiliser car en cloisonnement, c’est quand même l’idéal.

Dans une infrastructure informatique sensible, la disponiblité des applicatifs est primordiale.

Pour répondre à cette exigence, les solutions mises en oeuvre se basent donc sur de la haute-disponibilité et de l’équilibrage de charge (communément appelé LoadBalancing).

J’avais déjà évoquer la haute-disponibilité sous Linux dans ce billet et abordé ce type d’architecture dans celui ci.

Je vais donc aller un peu plus loin dans ce concept et tenter de mettre en oeuvre un équivalent “open-source” d’un produit commercial.

Ceux qui d’entre vous travaillent ou ont travaillé dans ce genre d’environnement, doivent avoir de fortes chances d’avoir croiser dans les baies des boitiers “Alteons”.

(merci à Morgan pour les Altéons :-)))

Alteon WebSytems est une société américaine spécialisée dans la haute-disponibilité et rachetée par Nortel fin 2000.

Les produits s’appellent désormais AS (pour Application Switch) et vous trouverez un comparatif des boiboites ICI, mais par facilité, le terme “Alteon” est toujours employé.

Sachez que chez CISCO également il existe ce genre de solution (ACE).

Je ne rentrerais pas dans les arcanes d’un altéon mais en voir rapidement le principe et d’en construire un équivalent chez soi.

Globalement, le principe est le suivant :

(source image IBM)

La configuration se fait sur 4 points principaux donc je vais vous détailler la configuration ci-dessous.

Il s’agit d’une configuration de base pour un loadbalancing en haute-dispo sur 2 serveurs web.

Spécial grand Merci à Steven pour son aide sur l’Alteon

1 - Les serveurs réels

Il s’agit des applications à “load balancer”.

/cfg/slb/real 1
enable
rip aa.bb.cc.dd     #l'ip du serveur réel 1
retry 2     #nombre d'essai avant de considérer le serveur comme down
restr 2     #nombre d'essai avant de considérer le serveur comme up
inter 15     #intervalle entre 2 checks en secondes
name lenom
/cfg/slb/real 2
enable
rip aa.bb.cc.ee
retry 2
restr 2
inter 15
name lenom

2 - Le groupe

On regroupe ensuite les applications à “load balancer” au sein d’un même groupe. Le groupe comprend les Real Servers ainsi que le “jeu” de test permettant de vérifier leur bon état.

cfg/slb/group 1
health http     #service concernée, ici http mais peut être : link|arp|icmp|tcp|http|httphead|dns|pop3|smtp|
nntp|ftp|imap|sslh|radius-auth|radius-acc|radius-aa|script|udpdns|wsp|wtp|wtls|ldap|snmp|tftp|rtsp|sip|wts|dhcp
viphl disable     #désactive le check VIP lié au DSR (Direct Server Return)
content "/status.html"     #la page a checker
add 1     #ajout du serveur réel 1 dans le groupe
add 2     #ajout serveur 2 dans le groupe
name lenomdugroupe

3 - Le virtual server

Un Virtual Server se caractérise par son adresse virtuelle (VIP), son port d’écoute virtuel (service), le groupe de Real server auquel il est associé et les ports d’écoute des Real Servers

/cfg/slb/virt 1
enable
vip 10.1.1.1
 
/cfg/slb/virt 1/service 80
group 1
hname lenom
epip ena     #on force la sélection par egress ou VLAN

4 - le virtual router

Le routeur virtuel qui contient la VIP, le groupe, l’interface physique et la priorité par rapport à son “voisin”.

/cfg/l3/vrrp/vr 1 (avec le chiffre égale au virt associé)
ena
vrid n     # le numero du Virtual Routeur
if 1     # l'interface
prio 99     #la priorité (plus le chiffre est haut plus l'atéon est prioritaire par rapport a l'altéon de backup)
addr 10.1.1.1     #la VIP
share dis     #on désactive l'extension Nortel VRRP

Un dessin valant toujours mieux qu’un long discours , nous allons imaginer l’architecture suivante :

• 2 Altéons
• 1 VLAN dédié aux IP loadbalancées en 10.0.0.0/24
• 1 VLAN dédié aux serveurs Web en 192.168.1.1/24
• 2 serveurs Web

C’est forcément simplifié au maximum mais cela donne une idée de ce que nous allons mettre en place.

Avec des “Altéons”, nous aurions donc ce genre de schéma :

Shématisation Alteon

Le but étant de reproduire a peu près la même chose chez soi, il y a un système d’exploitation qui contient déjà tout ce qu’il faut pour cela : OpenBSD.

Alors, oui, on pourrait faire la même chose avec Linux, en se tapant l’installation d’Ucarp, Balance, LVS et/ou autres joyeusetés, mais personnellement, je préfère laisser cela a OpenBSD qui peut le faire nativement et qui a fait ses preuves en environnement réseau critique.

Après tout, OpenBSD est amour, avec du poil autour, et c’est tout.

Reprenons notre schéma et adaptons le à une solution basée sur 2 serveurs sous OpenBSD pour remplacer les “Altéons” :

Schématisation OpenBSD

Ne reste qu’a configurer tout cela

• CARP + VLAN (optionnel)

Définir une VIP sur nos OpenBSD (une interface CARP sur interface physique ou sur interface VLAN)

/etc/sysctl.conf
 
net.inet.carp.preempt=1
net.inet.carp.allow=1
 
#ifconfig carp0 create
 
#ifconfig carp0 vhid 1 pass motdepasse carpdev em0 advskew 1 10.0.0.1 netmask 255.255.255.0
 
Pour un VLAN (exemple):
cat /etc/hostname.vlan3
inet 10.0.0.3 255.255.255.0 vlan 3 vlandev em0
 
cat /etc/hosname.carp0
inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 carpdev vlan3 advskew 1 pass motdepasse

Je ne m’attarde pas la dessus, en ayant déjà parler sur CE BILLET.

• PFSYNC

ifconfig pfsync0 syncpeer "ip openbsd en face" syncdev em1
ifconfig pfsync0 up

• Partie PF / Hoststated

/etc/pf.conf
 
rdr-anchor "hostatetd/*"
 
table  persist { 192.168.1.1, 192.168.1.2 }
 
rdr on $carp0 from any to $ipcarp port 80 ->  round-robin sticky-address
 
# la variable sticky-address signifie que PF maintient la session du client sur le même serveur
 
/etc/hoststated.conf
 
real1="192.168.1.1"
real2="192.168.1.2"
vip="10.0.0.1" # VIP CARP
 
interval 5 #on vérifie l'état des serveurs toutes les 5 secondes
 
table messerveurs {
check http "/status.html" code 200
timeout 300
real port 80
host $real1
host $real2
}
 
service www {
virtuel ip $vip port 80
table messerveurs
}

Petite explication :

On utilise une table “messerveurs” qui contient la liste des serveurs à “loadbalancer”.
PF redirige les requètes entrantes sur la VIP (10.0.0.1) alternativement (round-robin) et maintient la session du client sur le même serveur (sticky-address).
Bien évidemment, tout cela est optionnel et à vous d’adapter selon vos applis (man pf ).

Le démon Hoststated vérifie que les serveurs réels sont bien vivants en appelant la page status.html sur chacun des serveurs de sa liste.
En cas de non réponse (code retour http différent de 200), il considérera le serveur comme down et le retirera de la table “messerveurs”.

C’est pas beau tout cela ?

La commande # hoststatectl show vous donnera l’état des serveurs et vous pouvez manuellement les sortir ou les remettre dans le pool (# hoststatectl host disable/enable 192.168.1.x).

Et petit bonus, vous pouvez agir directement sur la couche 7

Exemple de relais load-balancé HTTPS :

protocol monchteuteupeucrypte {
protocol http
header append "$REMOTE_ADDR" to "X-Forwarder-For"
header append "$SERVER_ADDR:$SERVER_PORT" to "X-Forwarder-By"
header change "Keep-Alive" to "$TIMEOUT"
url hash "sessid"
cookie hash "sessid"
path filter "*command=*" from "/cgi-bin/index.cgi"
 
ssl { sslv2, ciphers "MEDIUM:HIGH" }
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
}
 
relay wwwssl {
listen on $vip port 443 ssl
protocol monchteuteupeucrypte
table messerveurs loadbalance
}

Maintenant que je vous ai titillé avec tout cela, je vous invite, outre à manger les MAN d’OpenBSD, mais aussi à lire cet excellent ouvrage :

The Book of PF
A No-Nonsense Guide to the OpenBSD Firewall
Par Peter N.M. Hansteen

Vous le trouverez chez Amazon par exemple :
http://www.amazon.fr/Book-PF-No-nonsense-Guide-Firewall/dp/1593271654

Conclusion :

Loin de moi l’idée de vous dire qu’une architecture comme celle-ci sera tout aussi efficace qu’un Switch Applicatif hors de prix, il existe des fonctions sur ces boitiers que l’on peut évidemment reproduire mais qui demanderons du temps…

Par contre, ce type d’architecture n’a pas a rougir en Production pour load-balancer des applications se prétant à ce jeu.

Amusez vous bien