/*!
* container_of - cast a member of a descriptor out to the containing descriptor
*
* @ptr:    the pointer to the member.
* @type:    the type of the container struct this is embedded in.
* @member:    the name of the member within the struct.
*
*/
#define container_of(ptr, type, member) ({			\
const typeof( ((type *)0)->member ) *__mptr = (ptr);	\
(type *)( (char *)__mptr - offsetof(type,member) );})

Elle prend en paramètres (comme décrit plus haut):

• ptr: le pointeur que nous manipulons, membre de la structure instanciée dont nous voulons récupérer l’adresse
• type: le type de la structure qui contient ce membre,
• member: le nom du membre dans la déclaration de la structure.

La premiere ligne de la macro permet de déclarer un pointeur qui va contenir l’adresse du membre.

Ce pointeur va être correctement déclaré grâce au cast réalisé par:

typeof( ((type *)0)->member )*

(type *) 0 permet de déclarer un pointeur de structure de type (type) à l’adresse 0. On récupère alors le membre qui nous intéresse et plus précisément son type avec typeof, opérateur unaire comme sizeof défini par gcc (http://gcc.gnu.org/onlinedocs/gcc/Typeof.html).

La deuxième ligne peut se décomposer en deux parties:

• offsetof(type, member) va calculer le décalage du champ member à partir du début de la structure type, en octet. offsetof (3) est une macro définie dans stddef.h,
• on soustrait à l’adresse contenue par __mptr l’offset calculé par offsetof. On caste __mptr en (char *) afin que la soustraction soit effectuée en octet (sinon le compilateur fixera comme unité la taille du membre member).

L’adresse retournée est donc l’adresse de la structure contenant le membre ptr.

Prenons un exemple:

struct toto {
char a;
char b;
};

À un instant t dans mon code, je manipule un pointeur sur le membre b d’une structure toto instanciée préalablement en mémoire: (char *)ptr_sur_b;
Je n’ai plus dans le contexte de la fonction l’adresse de cette structure et pour une raison quelconque (par exemple accéder au membre a) je veux récupérer cette adresse:

struct toto *t;
/* je récupère l'adresse de la structure grâce à containerof */
t = containerof(ptr_sur_b, struct toto, b);
/* je peux alors accéder au membre a de la structure t: t->a */

Si l’on remplace member et type dans la macro par ce qui nous intéresse ici:

ligne 1:

const typeof( ((type *)0)->member ) *__mptr = (ptr);
=> const typeof ( ((struct toto*)0)->b ) *__mptr;
=> const char *__mptr;

ligne 2:

(struct toto *) ( (char *)__mptr - offsetof (struct toto, b));
=> (struct toto *) ( (char *) __mptr - 1 );

On retrouvera entre autre l’utilisation de cette macro dans l’implémentation des listes (./include/linux/list.h) du kernel.

Ce module est présent et activé par défaut dans freeradius depuis la version 1.1.0. Il permet de définir une durée maximale de connexion pour un utilisateur donné, en se basant sur les valeurs stockées dans la table radacct (Accounting) pour chaque session.

On trouvera le fichier de configuration du module dans /etc/freeradius/sql/mysql/counter.conf

Il est possible de définir une période de rafraîchissement pour laquelle la durée autorisée est réinitialisée à intervalle régulier. On pourra par exemple accorder x minutes par jour ou par mois en utilisant les scénarios prédéfinis daily et monthly de counter.conf, ou en écrivant son propre sqlcounter.

On trouve aussi dans counter.conf, le sqlcounter noresetcounter, permettant de définir une durée maximale unique pour l’utilisateur qu’il pourra utiliser sur une ou plusieurs sessions:

sqlcounter noresetcounter {
counter-name = Max-All-Session-Time
check-name = Max-All-Session
sqlmod-inst = sql
key = User-Name
reset = never
query = "SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{%k}'"
}

Le fichier de conf est assez bien commenté et on trouvera une doc complète de mise en place sur http://wiki.freeradius.org/Rlm_sqlcounter

Une fois activée, à chaque Access-Request, freeradius va consulter le module rlm_sqlcounter qui va calculer le temps de connexion passé en additionnant les AcctSessionTime des sessions précédentes, et le comparer avec la valeur de l”attribut Max-All-Session (placé dans radcheck ou radgroupcheck).

Si Max-All-Session > SUM(AcctSessionTime) alors freeradius va renvoyer un Access-Accept avec un attribut Session-Timeout = Max-All-Session – SUM(AcctSessionTime), sinon il envoie un Access-Reject.

Exemple avec un utilisateur min5 (avec un Max-All-Session de 5min, ayant déjà consommé 124s de connexion) envoyant un Access-Request (logs crachés par un freeradius lancé avec l’option -X):

[...]
rlm_sqlcounter: Entering module authorize code
sqlcounter_expand:  'SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}''
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
sqlcounter_expand:  '%{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'}'
[noresetcounter] sql_xlat
[noresetcounter]     expand: %{User-Name} -> min5
[noresetcounter] sql_set_user escaped user --> 'min5'
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
rlm_sql (sql): Reserving sql socket id: 1
[noresetcounter] sql_xlat finished
rlm_sql (sql): Released sql socket id: 1
[noresetcounter]     expand: %{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'} -> 124
rlm_sqlcounter: Check item is greater than query result
rlm_sqlcounter: Authorized user min5, check_item=300, counter=124
rlm_sqlcounter: Sent Reply-Item for user min5, Type=Session-Timeout, value=176
++[noresetcounter] returns ok
 
Sending Access-Accept of id 85 to 78.114.63.174 port 53158
Session-Timeout == 176
[...]

Si Max-All-Session < SUM(AcctSessionTime) alors on aura:

[...]
rlm_sqlcounter: Entering module authorize code
sqlcounter_expand:  'SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}''
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
sqlcounter_expand:  '%{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'}'
[noresetcounter] sql_xlat
[noresetcounter]     expand: %{User-Name} -> min5
[noresetcounter] sql_set_user escaped user --> 'min5'
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
rlm_sql (sql): Reserving sql socket id: 1
[noresetcounter] sql_xlat finished
rlm_sql (sql): Released sql socket id: 1
[noresetcounter]     expand: %{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'} -> 301
rlm_sqlcounter: (Check item - counter) is less than zero
rlm_sqlcounter: Rejected user min5, check_item=300, counter=301
++[noresetcounter] returns reject
 
Sending Access-Reject of id 124 to 78.114.63.174 port 51651
Reply-Message = "Your maximum never usage time has been reached"
[...]

Néanmoins, que se passe t’il lors de la première connexion de l’utilisateur, alors qu’il n’y a aucune durée de connexion loggée dans la table radacct ?

[...]
rlm_sqlcounter: Entering module authorize code
sqlcounter_expand:  'SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}''
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='%{User-Name}' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
sqlcounter_expand:  '%{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'}'
[noresetcounter] sql_xlat
[noresetcounter]     expand: %{User-Name} -> min5
[noresetcounter] sql_set_user escaped user --> 'min5'
[noresetcounter]     expand: SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5' -> SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'
rlm_sql (sql): Reserving sql socket id: 1
[noresetcounter] row[0] returned NULL
rlm_sql (sql): Released sql socket id: 1
[noresetcounter]     expand: %{sql:SELECT SUM(AcctSessionTime) FROM radacct WHERE UserName='min5'} ->
rlm_sqlcounter: No integer found in string ""
++[noresetcounter] returns noop
 
Sending Access-Accept of id 81 to 78.114.63.174 port 57171
[...]

Rlm_sqlcounter n’est pas capable d’effectuer sa requête puisqu’il n’y a pas de session antérieure concernant le nouvel utilisateur. Il est échoue et freeradius renvoie un Access-Accept, sans Session-Timeout, donc sans aucune restriction concernant la durée de connexion !

Il faut préalablement définir pour l’utilisateur (table radreply) ou un groupe d’utilisateur (table radgroupreply) un Session-Timeout correspondant au Max-All-Session, afin qu’il soit utilisé lors de la première connexion. Pour les futures connexions, le module Rlm_sqlcounter génèrera un Session-Timeout que freeradius utilisera à la place de la valeur configurée par défaut.

• freeradius_2.1.4-0_i386.deb
• freeradius-mysql_2.1.4-0_i386.deb
• freeradius-postgresql_2.1.4-0_i386.deb
• freeradius-ldap_2.1.4-0_i386.deb
• freeradius-krb5_2.1.4-0_i386.deb
• freeradius-iodbc_2.1.4-0_i386.deb
• freeradius-dialupadmin_2.1.4-0_all.deb
• freeradius-dbg_2.1.4-0_i386.deb

Un petit patch

Un patch (peut-être pas très propre ni très abouti) est disponible ici http://aandre.evolix.net/files/vrrpd/vrrpd-1.0-ebtables.diff. Il permet d’utiliser la méthode décrite précédemment tout en améliorant l’affichage du statut de vrrpd pendant son exécution.

Le script /etc/vrrpd/vrrp_switch sera exécuté lors des changements d’états avec des arguments supplémentaires:

• l’IP virtuelle VRRP,
• l’interface sur laquelle l’instance VRRP tourne,
• la priorité actuelle de l’instance,
• l’advertisement interval VRRP
• la preemption VRRP

On récupère aussi l’adresse mac matérielle de l’interface du routeur, et l’adresse mac VRRP.

On va ainsi logger plus d’information sur l’état de notre routeur VRRP dans /var/vrrp/vrrp-$VRRP_NAME, mais surtout on aura à disposition les paramètres nécessaires pour le bon fonctionnement de nos règles ebtables gérant les états master et slave.

Il est prévu d’utiliser vrrpd avec l’option -n afin que ce dernier n’ait pas à gérer l’adresse mac virtuelle. Néanmoins cela entraîne aussi l’envoi des paquets d’échanges VRRP avec l’adresse mac matérielle. Le patch corrige cela.

On télécharge les sources de vrrpd ici http://ftp.de.debian.org/debian/pool/main/v/vrrpd/vrrpd_1.0-1exp1.tar.gz

$ wget http://ftp.de.debian.org/debian/pool/main/v/vrrpd/vrrpd_1.0-1exp1.tar.gz
$ tar zxvf vrrpd_1.0-1exp1.tar.gz

On applique le patch et on compile:

$ wget http://aandre.evolix.net/files/vrrpd/vrrpd-1.0-ebtables.diff
$ cd vrrpd-1.0 && patch -p1 < ../vrrpd-1.0-ebtables.diff
$ make

On prépare l’environnement de vrrpd à la main:

En root

# mkdir /etc/vrrpd && cp debian/vrrp_switch /etc/vrrp
# mkdir /var/vrrp

Voilà on est prêt à tester vrrpd, en utilisant la topologie classique suivante :

VRRP demo

Dans cet article on se contentera de tester la bascule VRRP en pingant continuellement l’adresse ip virtuelle et on regardera si les adresses MAC sont correctes dans /proc/net/arp de la machine “client”.

Côté Cisco 800

On configure une instance VRRP avec un group ID de 10, une priorité de 110, un advertisement interval de 2s et l’adresse IP virtuelle 192.168.10.250, sur l’interface configurée avec l’adresse 192.168.10.2/24 :

conf t
interface bla
vrrp 10 ip 192.168.10.250
vrrp 10 priority 110
vrrp 10 timers advertise 2

Côté Linux

On prépare le bridge en y ajoutant la ou les interfaces que l’on souhaite, ici eth0.

# brctl addbr br0
# ifconfig eth0 up
# brctl addif br0 eth0
# ifconfig br0 192.168.10.3

On lance vrrpd sur cette interface avec une priorité de 90 (donc backup par rapport au cisco).

# ./vrrpd -n -i br0 -v 10 -p 90 -d 2 -l demo 192.168.10.250 -D

L’état de la machine faisant tourner vrrpd est bien slave :

# cat /var/vrrp/state.10
slave
# cat /var/vrrp/vrrp-demo
VRRP - demo
Group 10
State is slave
Virtual IP address is 192.168.10.250
Virtual MAC address is 00:00:5E:00:01:a
demo is running on br0
Priority is 90
Advertisement interval is 2
Preemption is true

Côté client

On peut lancer un tcpdump sur l’interface 192.168.10.12.

# tcpdump -vvv -xx -i eth0 -n vrrp
 
11:12:09.311568 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none], proto VRRP (112), length 40)
192.168.10.2 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 110, authtype none, intvl 2s, length 20, addrs: 192.168.10.250
0x0000:  0100 5e00 0012 0000 5e00 010a 0800 45c0
0x0010:  0028 0000 0000 ff70 0fe9 c0a8 0a02 e000
0x0020:  0012 210a 6e01 0002 a54f c0a8 0afa 0000
0x0030:  0000 0000 0000 0000 0000 0000

Et l’on voit défiler les paquets VRRP d’avertissement émis par le routeur master (le cisco 800) avec l’adresse mac virtuelle 0000 5e00 010a

Un coup d’oeil sur les résolutions arp à partir de la machine client:

$ ping -c 1 192.168.10.2
$ ping -c 1 192.168.10.3
$ ping -c 1 192.168.10.250
$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.10.2     0x1         0x6         00:1e:7a:93:6f:21     *        eth0
192.168.10.3     0x1         0x2         00:13:72:76:23:aa     *        eth0
192.168.10.250   0x1         0x2         00:00:5e:00:01:0a     *        eth0

Les deux routeurs sont toujours accessibles sur leur ip réelles avec les adresse mac matérielles correspondantes. La VMAC de l’instance VRRP est bien associée à 192.168.10.250.

Simulons grossièrement une “panne” du master en débranchant le cisco du lan et en pingant continuellement la VIP à partir du client:

$ ping 192.168.10.250
[...]
64 bytes from 192.168.10.250: icmp_seq=108 ttl=255 time=0.972 ms
64 bytes from 192.168.10.250: icmp_seq=109 ttl=255 time=0.959 ms
64 bytes from 192.168.10.250: icmp_seq=117 ttl=64 time=0.195 ms
64 bytes from 192.168.10.250: icmp_seq=118 ttl=64 time=0.171 ms
[...]

La convergence vers le nouveau master s’est faite en quelques secondes, on l’observe sur le ping (ah regardez la ttl par exemple et /proc/sys/net/ipv4/ip_default_ttl sur la machine faisant tourner vrrpd…).

$ cat /var/vrrp/state.10
master
$ cat /var/vrrp/vrrp-demo
VRRP - demo
Group 10
State is master
Virtual IP address is 192.168.10.250
Virtual MAC address is 00:00:5E:00:01:a
vrrpd- is running on br0
Priority is 90
Advertisement interval is 2
Preemption is true

Dans notre tcpdump, on voit que c’est vrrpd qui génère à présent les avertissements VRRP.

11:43:51.714625 IP (tos 0x0, ttl 255, id 256, offset 0, flags [none], proto VRRP (112), length 40)
192.168.10.3 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 90, authtype none, intvl 2s, length 20, addrs: 192.168.10.250
0x0000:  0100 5e00 0012 0000 5e00 010a 0800 4500
0x0010:  0028 0100 0000 ff70 0fa8 c0a8 0a03 e000
0x0020:  0012 210a 5a01 0002 b94f c0a8 0afa 0000
0x0030:  0000 0000 0000 0000 0000 0000

L’interface br0 s’est bien appropriée la VIP 192.168.10.250:

$ ip addr show br0
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 00:13:72:76:23:aa brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.3/24 brd 192.168.10.255 scope global br0
    inet 192.168.10.250/32 brd 192.168.10.250 scope global br0

Vérifions à nouveau les adresses mac

$ ping -c 1 192.168.10.3
$ ping -c 1 192.168.10.250
$ cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.10.3     0x1         0x2         00:13:72:76:23:aa     *        eth0
192.168.10.250   0x1         0x2         00:00:5e:00:01:0a     *        eth0

Tout est ok lorsque vrrpd est master.

On peut aussi vérifier les règles ebtables insérées lors du passage à l’état master :

navi:/var/vrrp# ebtables -t broute -L
Bridge table: broute
 
Bridge chain: BROUTING, entries: 1, policy: ACCEPT
-p IPv4 -d 0:0:5e:0:1:a --logical-in br0 -j redirect
navi:/var/vrrp# ebtables -L
Bridge table: filter
 
Bridge chain: INPUT, entries: 0, policy: ACCEPT
 
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
 
Bridge chain: OUTPUT, entries: 1, policy: ACCEPT
-p ARP -s 0:13:72:76:23:aa --logical-out br0 --arp-op Reply --arp-ip-src 192.168.10.250 -j DROP
navi:/var/vrrp# ebtables -t nat -L
Bridge table: nat
 
Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-p ARP --logical-in br0 --arp-op Request --arp-htype 1 --arp-ptype IPv4 --arp-ip-dst 192.168.10.250 -j arpreply --arpreply-mac 0:0:5e:0:1:a --arpreply-target ACCEPT
 
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
 
Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
-p IPv4 --logical-out br0 --ip-src 192.168.10.250 -j snat --to-src 0:0:5e:0:1:a --snat-target ACCEPT

Conclusion

L’exemple porte sur une seule instance de VRRP, mais il sera possible d’en lancer plusieurs en parallèle sur la mêmes interfaces et conserver la même cohérence.

Un autre sujet intéressant sur vrrpd pourrait concerner la fonctionnalité de tracking d’interface, qui prend tout son sens dans le cas par exemple d’un backup de ligne adsl. Néanmoins le code en l’état ne permet pas de l’utiliser sur ppp0 (cf les fonctions monitorit() l.1984 et mido_read() l.2005).

Il y a pas mal d’articles sur le sujet en fait, mais un petit memo perso fait pas de mal:

• Plug du téléphone en usb, avec mon samsung F480 j’obtiens ô joie un joli /dev/ttyACM0:

  usb 4-1: new full speed USB device using uhci_hcd and address 4
  usb 4-1: configuration #1 chosen from 1 choice
  cdc_acm 4-1:1.0: ttyACM0: USB ACM device

• Lancement de pppd (Le tout sur une seule ligne.):

  pppd connect '/usr/sbin/chat -v ABORT "NO CARRIER" "" "AT&F" OK "AT+CGDCONT=1,\"IP\",\"sl2sfr\",\"0.0.0.0\",0,0" OK "ATDT *99#" CONNECT' disconnect '/usr/sbin/chat -v ABORT "BUSY" "" "\K" "" "+++ATH"' /dev/ttyACM0 defaultroute noauth asyncmap 0 mtu 1500 mru 1500 noipdefault usepeerdns idle 600

  En fait vous avez plusieurs choix pour la chaine “AT+CGDCONT=1,\”IP\”,\”sl2sfr\”,\”0.0.0.0\”,0,0″ :
  - Vous avez débloqué l’option iphone chez SFR pour avoir accès directement à l’IMAP(s)/SMTP/POP : sl2sfr
  - Vous n’avez pas débloqué cette option: wapsfr
  - Vous voulez payer la connexion ou vous n’avez pas de forfait illimythics: websfr

• On regarde dans /var/log/messages en même temps et on constate que ça marche !

   pppd[31007]: pppd 2.4.4 started by root, uid 0
  chat[31008]: abort on (NO CARRIER)
  chat[31008]: send (AT&F^M)
  chat[31008]: expect (OK)
  chat[31008]: AT&F^M^M
  chat[31008]: OK
  chat[31008]:  -- got it
  chat[31008]: send (AT+CGDCONT=1,"IP","sl2sfr","0.0.0.0",0,0^M)
  chat[31008]: expect (OK)
  chat[31008]: ^M
  chat[31008]: AT+CGDCONT=1,"IP","sl2sfr","0.0.0.0",0,0^M^M
  chat[31008]: OK
  chat[31008]:  -- got it
  chat[31008]: send (ATDT *99#^M)
  chat[31008]: expect (CONNECT)
  chat[31008]: ^M
  chat[31008]: ATDT *99#^M^M
  chat[31008]: CONNECT
  chat[31008]:  -- got it
  pppd[31007]: Serial connection established.
  pppd[31007]: Using interface ppp0
  pppd[31007]: Connect: ppp0 <--> /dev/ttyACM0
  pppd[31007]: Could not determine remote IP address: defaulting to 10.64.64.64
  pppd[31007]: local  IP address 10.X.X.X
  pppd[31007]: remote IP address 10.64.64.64
  pppd[31007]: primary   DNS address 172.20.2.39
  pppd[31007]: secondary DNS address 172.20.2.10

• On configure le proxy qui va bien dans firefox (ou autre) dans edition/preferences/réseau/paramètres: 195.115.25.129:8080 pour http et https.

Le proxy SFR  ne laisse passer que les user agent de navigateur de téléphone portable. Il faut donc changer la variable general.useragent.extra.firefox en par exemple Samsung-SGH-F480-Vodafone/F480AEHH2 SHP/VPP/R5 NetFront/3.4 Qtv5.3 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1 et voilà, une connexion de dépannage “illimité” et “gratuite” pour votre lappy  :-p

NB: Il sera plus pratique d’utiliser les plugins firefox User Agent Switcher et SwitchProxy Tool pour gérer les deux derniers points.

Il existe une implémentation libre du protocole : vrrpd, apparemment plus maintenue à ce jour. On lui préfèrera la version patchée par les contributeurs debian qui amène pas mal d’améliorations et de corrections de bug. Je passe la description détaillée du protocole, on notera que vrrpd respecte la rfc 2338, qui a été mise à jour par la rfc 3768 n’apportant en fait rien de spécial, à part en gros la suppression de l’authentification (tout en concervant la comptabilité avec l’ancienne rfc) et quelques clarifications.

Le principal problème sous linux quand on utilise un protocole de redondance utilisant une adresse MAC virtuelle est le fait qu’on ne puisse attribuer qu’une seule adresse mac par NIC, comme on peut le lire dans ce thread concernant justement VRRP.

Pour une unique instance de VRRP, le problème est donc contourné dans vrrpd de la manière suivante:

1. L’adresse MAC de l’interface sur laquelle tourne vrrpd est remplacée en mode Master par l’adresse MAC virtuelle de l’instance VRRP (que l’on notera VMAC par la suite),
2. La véritable adresse MAC est rajoutée à la liste des filtres multicast de l’interface, cette astuce permettra à celle-ci d’accepter les paquets envoyées à destination de son adresse IP réelle avec l’adresse MAC réelle.

La première opération est effectuée par le code suivant dans la fonction hwaddr_set ligne 508:

/* change the hwaddr */
memcpy( ifr.ifr_hwaddr.sa_data, addr, addrlen ); /* addr est VMAC */
ifr.ifr_hwaddr.sa_family = AF_UNIX;
ret = ioctl(fd, SIOCSIFHWADDR, (char *)&ifr);

Et on retrouve la deuxième dans le code de la fonction  rcvhwaddr_op ligne 484:

strncpy(ifr.ifr_name, ifname, sizeof(ifr.ifr_name));
memcpy( ifr.ifr_hwaddr.sa_data, addr, addrlen );    /* addr est ici la véritable adresse MAC de l'interface */
ifr.ifr_hwaddr.sa_family = AF_UNSPEC;
ret = ioctl(fd, addF ? SIOCADDMULTI : SIOCDELMULTI, (char *)&ifr);

Ces deux fonctions sont appelées lors d’un changement d’état Backup -> Master et inversement.

Alors si ce hack fonctionne pour une instance de VRRP, on est quand même confronté à un problème en mode Master:

- l’interface VRRP est joignable avec le bon couple VIP / VMAC. Quand un équipement du réseau fait une requête ARP pour connaître la VMAC liée à VIP, elle récupère bien la bonne adresse.

- Par contre si l’on essaye d’envoyer des paquets sur l’ancienne IP, soit notre équipement connait déjà l’adresse MAC et il n’y aura pas de requête ARP, soit il ne la connaît pas, effectue une requête ARP pour l’atteindre et reçoit la  VMAC au lieu de la véritable adresse MAC de l’interface. Bref cela fonctionnera, mais bon, ce n’est pas très cohérent …

Je vous laisse imaginer le chaos lorsque l’on tente de lancer plusieurs instances de VRRP sur la même interface (avec des group ids différents) et observer ce qu’il se passe après chaque execution d’un nouveau vrrpd en pingant, sniffant, regarder /proc/net/arp sur les machines distantes, et jeter un oeil aux résultats de la commande ip link show <interface>

Le problème apparait alors clairement: Comment faire pour conserver d’une part l’association adresse IP réelle de l’interface / adresse MAC réelle, et pour une ou plusieurs instances de VRRP l’association adresse IP virtuelle 1..n / adresse MAC virtuelle 1..n ?

Si l’on utilise vrrpd sur une interface de type bridge, il est possible de simuler cette association avec ebtables, dont la syntaxe est très proche d’iptables. Les schémas ici donnent une bonne idée du mécanisme et nous montrent où sont positionnés les hooks ebtables dans le cheminement d’un paquet.

Le but est de tromper la couche ethernet en falsifiant les réponses ARP et en créant les associations IP/MAC que l’on désire avec quelques règles.

On pose quelques variables:

- ROUTER_IF: Nom de l’interface sur laquelle tourne l’instance VRRP
- ROUTER_MAC: Adresse MAC de l’interface
- VRRP_IP: Adresse IP Virtuelle VRRP
- VRRP_MAC: Adresse MAC Virtuelle VRRP

Et on attaque avec la première règle qui va empêcher les reply ARP avec la MAC réelle lorsque l’on reçoit un request ARP pour VRRP_IP (0×0806 désigne l’ethertype ARP.):

$EBTABLES -A OUTPUT \
-p 0X0806 \
--logical-out $ROUTER_IF -s $ROUTER_MAC \
--arp-opcode 2 \
--arp-ip-src $VRRP_IP \
-j DROP

L’option –arp-opcode 2 désigne un paquet ARP reply (ebtables -h arp). Dans cette règle on matche les ARP reply générés par la couche ARP du kernel ayant pour source l’ip VRRP_IP.

On veut envoyer à la place la bonne VMAC:

$EBTABLES -t nat -A PREROUTING \
-p 0x0806 --logical-in $ROUTER_IF \
--arp-opcode 1 --arp-htype 1 --arp-ptype 0x0800 \
--arp-ip-dst $VRRP_IP \
-j arpreply --arpreply-mac $VRRP_MAC --arpreply-target ACCEPT

Ici on matche les ARP request pour VRRP_IP, et on génère avec -j arpreply un reply ARP avec la mac VRRP_MAC associée à VRRP_IP.

Maintenant que l’on contrôle les request/reply ARP, on veut aussi que les paquets sortant avec l’adresse IP virtuelle VRRP_IP possèdent l’adresse MAC virtuelle VRRP_MAC:

$EBTABLES -t nat -A POSTROUTING \
-p 0x0800 --logical-out $ROUTER_IF \
--ip-src $VRRP_IP \
-j snat --to-source $VRRP_MAC --snat-target ACCEPT

On veut faire l’inverse sur les paquets entrant, c’est à dire qu’on va changer l’adresse MAC virtuelle VRRP_MAC du paquet en adresse MAC ROUTER_MAC afin que le bridge ne le rejette pas:

$EBTABLES -t broute -A BROUTING \
--logical-in $ROUTER_IF -p 0x0800 -d $VRRP_MAC \
-j redirect

En utilisant la table broute, on change au plus tôt l’adresse MAC.
Le redirect signale au bridge de continuer le traitement du paquet après avoir changer l’adresse MAC.

Et voilà, on a toutes les règles qu’il nous faut, la magie est en place. On va pouvoir lancer plusieurs instances de VRRP indépendantes les unes des autres sur une interface de type bridge, en respectant la RFC et l’intégrité du niveau ethernet.

Pour que vrrpd applique ses règles automatiquement, on désactive sa gestion de l’adresse MAC virtuelle avec l’option “-n” et on place nos règles dans le script /etc/vrrpd/vrrp_switch dans le case “$1″ en différenciant le cas “master” du cas “slave” (fonctionnalité rajouté par les contributeurs Debian, ce script est appelé à chaque changement d’état). Ne pas oublier d’effacer les règles dans le cas “slave”.

Alors certes cette méthode oblige à utiliser une interface de type bridge, mais on peut se dire que si on utilise VRRP sur une box, il y a de grandes chances que l’interface concernée soit déjà un bridge qui agrège plusieurs interfaces eth*. Sinon il existe sûrement une meilleure méthode qui permette les mêmes manipulations au niveau ARP, si quelqu’un a un lien je suis preneur.

Un autre avantage notable c’est que l’on ne tombe plus l’interface VRRP pour changer les adresses MAC (cf les deux fonctions plus haut) et on ne perd plus du coup les règles de routage liées à l’interface (alors oui il y a bien un patch pour ça mais bon…).

Il y aura sûrement d’autres articles sur vrrpd, il y a encore quelques trucs à bidouiller pour l’améliorer et je reviendrai sur l’illustration du bon fonctionnement de cette méthode, le post d’aujourd’hui est assez long comme ça …

NB : Pour aller plus loin avec ARP en général, je suis tombé récemment sur une page très interessante et un petit utilitaire du même auteur pour faire pleins de choses sympas avec ARP.

Si comme moi ça ne vous arrive pas souvent et que vous vous ne rappellez jamais les commandes adéquats pour importer dans apt la clé nécessaire, notez dans un coin :

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys XXXXXXXXX
gpg --armor --export XXXXXXXX | apt-key add -

Et hop.

W: GPG error: ftp://ftp.fr.debian.org testing Release: The following<br />
signatures couldn't be verified because the public key is not<br />
available: NO_PUBKEY  XXXXXXXXXXXXXXXX

Ce bug est signalé chez debian et concerne apt version < =0.6.43. Les images d'installation Etch sont construites quotidiennement, et il s'avère que j'utilisais une image d'installation par le réseau vieille de plus d'un mois.

Ayant la flemme de télécharger une nouvelle image et recommencer l’installation je choisis d’accéder à une console (alt-F2) et de me chrooter dans l’environnement presque finalisé, afin de mettre à jour apt lui même.

# chroot /target<br />
# apt-get update<br />
[...] GPG ERROR blabla [...]<br />
# apt-get install apt<br />
[...]<br />

Apt s’est alors mis à jour, et j’ai pu terminer mon installation .

Il est bien sûr conseillé d’utiliser une image récente lors d’installation de version testing afin d’éviter ce genre de désagrément.