Dans les précédents articles, nous avons mis en place l’architecture réseau de la plateforme cloud, installer un routeur firewall et relié ce site à notre site central.

 

Ce billet explore le routage dynamique OSPF pour intégrer la plateforme à notre plan d’adressage ip.

Le protocole OSPF (Open Shortest Path First) repose sur l’état du lien immédiat de l’équipement. Les articles sur le sujet sont nombreuses sur la toile. Ce qu’il faut retenir c’est son usage.

Ce protocole sert à l’organisation interne d’un domaine, c’est à dire que chaque routeur du domaine possède l’intégralité des routes du domaine. Aussi ce protocole n’est utilisé que pour un usage interne.

Pour communiquer entre deux domaines, d’autre protocole à vecteur de chemin sont plus approprié (BGP). Ce type de protocole permet de ne pas diffuser l’intégralité de son plan d’adressage ip. Il indique seulement que tout ou partie d’un plan ip peut être trouver dans ce domaine. Il n’indique pas comment y accéder, seulement qu’il faut passer par ce routeur de bordure de domaine. C’est ce routeur qui possède aussi d’autre protocole (type OSPF) qui sera le point d’entré.

En ce qui nous concerne, le private cloud fait partie intégrante de notre domaine. Dans certain cas d’usage, il est préférable de l’isoler en utilisant BGP. C’est ce qui est fait par exemple pour les clouds publics (tel Azure avec leur VPN gateway).

Avant de commencer l’implémentation, le schéma suivant décrit la topologie souhaitée et le découpage des zones.

Deux point majeurs importants à retenir dans ce schéma :

– le tunnel gre fait partie de la zone 2.2.2.2 : cela évite d’utiliser un lien non stable pour diffuser des messages ospf de la zone 0.

– les zones doivent toujours être relié à la zone backbone (bonne pratique du routage ospf)

Vous pouvez vous inspirer des recommandations de l’ietf pour approfondir le sujet (https://tools.ietf.org/html/draft-ietf-ospf-deploy-00)

 

Configuration OSPF du routeur central

 

vyos@rcentral# show protocols ospf 
 area 0.0.0.0 {
     network 10.0.10.0/24
 }
 area 2.2.2.2 {
     area-type {
         normal
     }
     network 10.10.10.0/24
 }
 redistribute {
     connected {
     }
 }

Configuration OSPF du routeur cloud

set protocols ospf area 2.2.2.2 area-type normal
set protocols ospf area 2.2.2.2 network '10.10.10.0/24'
set protocols ospf redistribute connected

la directive redistribute connected permet l’inclusion de route directement relié au routeur. Cela induit que le réseau 192.168.200.0/24 sera diffusé dans la déclaration des routes de la zone.

Nous aurions pu déclarer ce réseau dans la zone 2.2.2.2. Mais si nous changeons le plan d’adressage, nous devons alors le modifier. Ce qui est en soit normal, mais si on oublie parce que plusieurs années se sont écoulées et que l’on n’y repense pas. Cela peut créer des problèmes.

 

Cas particulier GRE

Un tennel gre peut faire du broadcast mais dans notre cas il n’est pas utile d’une part il est au dessus d’IPSEC et d’autre part il n’y a qu’une seule terminaison vpn.

 

Aussi pour des questions de performance, nous évitons de diffuser en broadcast les messages OSPF.

Ces commandes sont à effectuer sur les deux routeurs

set interfaces tunnel tun0 ip ospf dead-interval '40'
set interfaces tunnel tun0 ip ospf hello-interval '10'
set interfaces tunnel tun0 ip ospf network 'point-to-point'
set interfaces tunnel tun0 ip ospf priority '10'
set interfaces tunnel tun0 ip ospf retransmit-interval '5'
set interfaces tunnel tun0 ip ospf transmit-delay '1'

Validation des échanges de routage

La commande show ip ospf neifhboor vérifie que le routeur d’en face réponde bien.

vyos@rcentral# run show ip ospf neighbor 

Neighbor ID     Pri State           Dead Time Address         Interface                        RXmtL RqstL DBsmL
192.168.99.2     10 Full/DROther       7.508s 10.10.10.2      tun0:10.10.10.1                      0     0     0

[edit]

Pour afficher l’ensemble des routes présent dans la base du routeur, c’est la commande show ip route (un « wrapper » ou enrobage de la commande ip route)

vyos@rcentral# run show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 0.0.0.0/0 [210/0] via 149.189.1.1, eth0, 01:38:31
O   10.0.10.0/24 [110/1] is directly connected, eth1, 00:36:51
C>* 10.0.10.0/24 is directly connected, eth1, 00:52:33
O   10.10.10.0/30 [110/10] is directly connected, tun0, 00:36:51
C>* 10.10.10.0/30 is directly connected, tun0, 00:52:21
C>* 149.189.1.0/24 is directly connected, eth0, 01:38:31
O>* 149.202.1.0/24 [110/20] via 10.10.10.2, tun0, 00:00:21
C>* 192.168.99.1/32 is directly connected, lo, 01:10:43
O>* 192.168.99.2/32 [110/20] via 10.10.10.2, tun0, 00:00:21
O>* 192.168.200.0/24 [110/20] via 10.10.10.2, tun0, 00:00:21

On voit bien la présence du réseau d’admin de notre plateforme cloud (192.168.200.0/24)

Une dernière vérification pour la route. Pour rappel, l’hyperviseur possède une adresse sur le réseau admin. Depuis ce serveur, logiquement nous pouvons joindre l’interface interne du routeur central.

Faisons alors un test de ping depuis ce serveur vers le routeur central.

jph@serveur1:~/ ping -c 4 10.0.10.1
PING 10.0.10.1 (10.0.10.1) 56(84) bytes of data.
64 bytes from 10.0.10.1: icmp_seq=1 ttl=63 time=2.00 ms
64 bytes from 10.0.10.1: icmp_seq=2 ttl=63 time=1.34 ms
64 bytes from 10.0.10.1: icmp_seq=3 ttl=63 time=1.25 ms
64 bytes from 10.0.10.1: icmp_seq=4 ttl=63 time=1.15 ms

--- 10.0.10.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.157/1.439/2.005/0.335 ms

La trace confirme bien la connectivité vers le routeur central. Pour valider qu’il emprunte bien le tunnel et non pas internet, nous regardons la table des connexions sur le routeur.

L’outil conntrack sert a visualiser les connexions transitant sur le routeur.

conntrack v1.4.5 (conntrack-tools): 19 flow entries have been shown.
root@rcentral:~# conntrack -L
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=54664 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=54664 mark=0 use=1
unknown  89 598 src=10.0.10.1 dst=224.0.0.5 [UNREPLIED] src=224.0.0.5 dst=10.0.10.1 mark=0 use=1
unknown  89 597 src=10.10.10.2 dst=224.0.0.5 [UNREPLIED] src=224.0.0.5 dst=10.10.10.2 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=47507 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=47507 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=39633 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=39633 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=36413 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=36413 mark=0 use=1
unknown  50 599 src=149.189.1.100 dst=149.202.1.100 src=149.202.1.100 dst=149.189.1.100 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=42646 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=42646 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=33046 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=33046 mark=0 use=1
gre      47 179 src=192.168.99.1 dst=192.168.99.2 srckey=0x0 dstkey=0x0 src=192.168.99.2 dst=192.168.99.1 srckey=0x0 dstkey=0x0 [ASSURED] mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=33367 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=33367 mark=0 use=1
icmp     1 29 src=192.168.200.2 dst=10.0.10.1 type=8 code=0 id=8082 src=10.0.10.1 dst=192.168.200.2 type=0 code=0 id=8082 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=49792 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=49792 mark=0 use=1
unknown  89 598 src=10.10.10.1 dst=224.0.0.5 [UNREPLIED] src=224.0.0.5 dst=10.10.10.1 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=38780 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=38780 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=45612 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=45612 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=50548 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=50548 mark=0 use=1
udp      17 7 src=127.0.0.1 dst=127.0.0.1 sport=55672 dport=53 [UNREPLIED] src=127.0.0.1 dst=127.0.0.1 sport=53 dport=55672 mark=0 use=1
conntrack v1.4.5 (conntrack-tools): 18 flow entries have been shown.

On remarque bien un flux icmp provenant de notre serveur cloud relié au vpn. Son adresse ip n’a pas changé (pas de nat), on peut en conclure que ce flux n’a pas été translater et provient bien du serveur et non de la passerelle internet du cloud.

 

Prochaines étapes

 

Récapitulons ce qui a été fait :

– mis en œuvre de l’architecture réseau physique et logique;

– installation de l’hyperviseur Qemu/kvm;

– déploiement d’un firewall virtuel;

– configuration d’un tunnel sécurisé entre la plateforme et le site central;

– déclaration des routes au sens ip.

 

Ces pré-requis sont un minimum pour garantir une expérience cloud tout en sécurité. Les prochains articles rentrera dans la configuration des services réseaux et le déploiement des services Openstack.