Réseaux GRE avec routage OSPF

Aucun commentaire

Objectifs

Etablir un réseau maillé (mesh) avec des liaisons GRE. Les tables de routage seront découvertes automatiquement via le protocole OSPF (Open Shortest Path First).

Donc dans un premier temps, configurer les liaisons GRE. Dans un second temps, configurer les démons ospfd pour la partie routage.

Topologie de la maquette

Il s’agit d’une version étendue de celle utilisée pour l’article sur la configuration d’un tunnel GRE simple. Au lieu d’avoir 2 réseaux distincts, nous en avons cette fois 4.

Les 4 réseaux A, B, C, D possède un identifiant qui leur a été attribué de manière arbitraire, pour simplifier les plans d’adressage:

  • Le réseau A => 16
  • Le réseau B => 22
  • Le réseau C => 227
  • Le réseau D => 13

Pour faire simple là aussi, ces différents réseaux sont reliés entre eux par un accès WAN sur une plage d’adresse unique en 192.168.122.X. X est remplacé par l’identifiant du réseau.

Chaque réseau possède des clients utilisant une plage d’adresse privée du style 192.168.X.0/24 où X est là aussi remplacé par l’idéntifiant du réseau.

Ce qui nous donne au final:

  • Réseau A Adresse WAN 192.168.122.16 avec réseau clients 192.168.16.0/24
  • Réseau B Adresse WAN 192.168.122.22 avec réseau clients 192.168.22.0/24
  • Réseau C Adresse WAN 192.168.122.227 avec réseau clients 192.168.227.0/24
  • Réseau D Adresse WAN 192.168.122.13 avec réseau clients 192.168.13.0/24

Toujours pour simplifier, l’adresse IP du serveur OpenBSD gérant le tunnel, et faisant office de passerelle, est sous la forme 192.168.X.254.

Bref voir le schéma suivant:

En fonction de la fiabilité des liens entre les différents réseaux, il est possible de ne faire que seulement 2 liens entre chaque site, pour assurer la tolérance de panne. Pour que ce soit un vrai réseau maillé, pour N noeuds, chaque N doit avoir N-1 connexions. Donc dans notre cas, 3 connexions. Celles-ci seront numérotées arbitrairement pour faciliter encore une fois la configuration, voir le schéma suivant:

Il n’y a pas non plus de logique dans l’attribution des adresses IP des extrémités des tunnels, j’aurais pu opter pour un adressage du style 172.16.numero_tunnel.identifiant_réseau… Peut être la prochaine fois ?

Ce numéro de tunnel est aussi repris dans la numérotation des interfaces GRE.

Pré-requis

Il s’agit des mêmes pré-requis que pour la configuration d’un tunnel GRE simple.

Pare-feu

Dans un premier temps, pour faciliter la mise en oeuvre, n’appliquons aucun filtrage sur les interfaces GRE.

Sur tun.a

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre1
set skip on gre2

OSPF

Sur tun.b

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre3
set skip on gre4
Sur tun.c

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre1
set skip on gre3
set skip on gre5
Sur tun.d

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre2
set skip on gre4
set skip on gre5

Autorisation des tunnels GRE

Pour autoriser au niveau du noyau les tunnels de type GRE, il faut ajouter sur l’ensemble des serveurs, la ligne suivante dans /etc/sysctl.conf:

net.inet.gre.allow=1

Et pour l’appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.gre.allow=1

Autorisation du routage

Pour activer le routage IP, il faut ajouter sur l’ensemble des serveurs la ligne suivante dans /etc/sysctl.conf:

net.inet.ip.forwarding=1

Et pour l’appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.ip.forwarding=1

Configuration des tunnels GRE

La configuration des 3 liaisons est effectuées sur chaque serveur. Il n’y a aucune information sur le routage à ce niveau.

Sur tun.a

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.22
Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.2 172.16.1.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.227
Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.2 172.16.2.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.13

Sur tun.b

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.1 172.16.3.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.227
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.1 172.16.4.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.13

Sur tun.c

Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.1 172.16.1.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.2 172.16.3.1 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.1 172.16.5.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.13

Sur tun.d

Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.1 172.16.2.2 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.16
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.2 172.16.4.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.2 172.16.5.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.227

Sur l’ensemble des serveurs

Pour activer les connexions GRE:

# sh /etc/netstart

Elles sont de toute façon activées par défaut au démarrage.

Configuration du démon OSPF

Il s’agit ici d’une configuration très simple permettant d’indiquer sur quelles interfaces le protocole OSPF doit opérer. L’interface indiquée comme passive permet à OSPFd de connaitre le reseau de cette dernière, sans faire d’annonce sur celle-ci. Les démons OSPFd dans notre cas ne peuvent en effet communiquer que via les tunnels GRE.

Sur notre maquette, l’interface reliée au réseau privé est em0.

Sur tun.a

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre1 {}
       interface gre2 {}
       interface em0 { passive }
}

Sur tun.b

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre3 {}
       interface gre4 {}
       interface em0 { passive }
}

Sur tun.c

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre1 {}
       interface gre3 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur tun.d

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre2 {}
       interface gre4 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur l’ensemble des serveurs

Pour activer le démon ospfd par défaut au démarrage, il faut modifer le fichier /etc/rc.conf.local (le créer s’il n ‘existe pas) pour avoir la ligne suivante:

ospfd_flags=""

Validation

Une fois tous les tunnels montés, et les services ospfd démarrés, ceux-ci devraient commencer à faire leurs découvertes sur les réseaux. Les routes seront échangées entre les différents démons via les annonces OSPF, constituant une base d’information de routage (ou RIB pour Routing Information Base). Pour consulter la RIB sur un serveur:

$ ospfctl show rib

Exemple sur la machine tun.a:

$ ospfctl show rib                                                                                                   
Destination          Nexthop           Path Type    Type      Cost    Uptime  
172.16.0.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.1.2/32        172.16.1.1        Intra-Area   Network   20      01:19:58
172.16.2.2/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.3.1/32        172.16.1.1        Intra-Area   Network   20      00:57:57
172.16.3.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.4.1/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.4.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36 
172.16.5.1/32        172.16.2.1        Intra-Area   Network   20      01:19:27
172.16.5.2/32        172.16.1.1        Intra-Area   Network   20      01:19:33
192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:19:39
192.168.22.0/24      172.16.0.1        Intra-Area   Network   20      00:57:36
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:19:58

A noté que le réseau 192.168.16.0/24 (réseau A) n’apparait pas vu qu’il s’agit du réseau local de la machine tun.a. Cette RIB nous informe que les démons ospfd a trouvé des routes pour les réseaux distants qui nous interessent, à savoir:

  • 192.168.13.0/24 (réseau D)
  • 192.168.22.0/24 (réseau B)
  • 192.168.227.0/24 (réseau C)

Un poids ou coût de 20 leur a été attribué.

Coupons maintenant la liaison GRE (numéro 0) entre tun.a et tun.b, en executant sur tun.b la commande suivante:

# ifconfig gre0 down

Regardons toujours sur tun.a, la RIB (les lignes inutiles sont masquées):

192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:26:07
192.168.22.0/24      172.16.2.1        Intra-Area   Network   30      00:00:13
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:00:13
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:26:26

Le réseau B 192.168.22.0/24 n’est plus annoncé comme accessible via 172.16.0.1 (tun.a) mais par 2 nouvelles routes 172.16.2.1 (tun.d) et 172.16.1.1 (tun.c). Cela montre bien que la route défectueuse est contournée. Ce qui est confirmé par l’augmentation du coût de ces routes (30 au lieu de 20).

Coupons maintenant la liaison GRE (numero 2) entre tun.a et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:09
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:04:56
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:09

Une route vers 192.168.22.0/24 a bien disparue.

Coupons maintenant la liaison GRE (numero 3) entre tun.c et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:41
192.168.22.0/24      172.16.1.1        Intra-Area   Network   40      00:05:28
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:41

La route vers 192.168.22.0/24 est toujours disponible, mais a un coût elevée (40), vu que de tun.a, nous passons par tun.c puis tun.d pour joindre tun.b. Donc malgré 3 coupures notre réseau est toujours fonctionnel, du moment qu’un site possède toujours au moins 1 connexion GRE.

Étiqueté avec , , ,

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *