Tunnel GRE sur Linux

Il est parfois intéressant de monter un tunnel GRE entre deux sites distants pour pouvoir interconnecter deux réseaux sans forcément effectuer le routage sur toute  la chaîne de liaison.

Ce type de design sert particulièrement dans les architectures BCP (Business Continuity Plan), ou la zone de sauvegarde (DRP – Disaster Recovery  Plan) d’un site en particulier a besoin de garder le même adressage IP (cas typique des backup des VMs sous ESX)

Nous présentons ci-dessous un exemple pratique :

Description du fonctionnement :

0 – le site SOHO-Primaire (Small Office/Home Office Primaire) effectue la sauvegarde des machines virtuelles tous les jours vers le site DRP sur le site HQ (HeadQuarters)

• Un incident se produit sur le site SOHO-Primaire et n’est plus joignable

• Les utilisateurs se déplacent vers le site SOHO-BCP et doivent pouvoir accéder à leur zone DRP qui se trouve sur HQ

• Vu que le site SOHO-Primaire est HS, le routeur sur le site BCP ne reçoit plus d’annonce de routage (en BGP par exemple). La route statique qui a une AD élevé de 254 (appelé aussi “Floating Static Route”) est automatiquement activée
  

Description de connexion (traçage de flux) :

1. L’utilisateur veut contacter un serveur dans une zone DRP. Les requêtes partent vers la passerelle (10.172.43.1)

2. Le routeur « 10.172.43.1 »ayant sa “Floating static route” activée, renvoi toutes les requêtes partantes du site SOHO-BCP en destination du réseau 10.172.40.0/23 vers la VM-GRE-BCP 10.172.43.42 qui a un tunnel GRE établie avec la VM qui se trouve sur le site HQ   « VM-GRE-HQ »

3. Toutes les requêtes sont encapsulées et traversent tout le nuage VPN MPLS de façon transparente

4. La VM « VM-GRE-HQ » ayant une interface sur le réseau DRP 10.172.40.1 (qui est l’adresse IP de la passerelle par défaut du site SOHO-Primaire) relaie les paquets décapsulé vers les serveurs Destinataire (dans notre exemple 10.172.40.41)

Les utilisateurs se déplacent vers le site SOHO-BCP et doivent pouvoir accéder à leur zone DRP (qui se trouve sur HQ)

5. Les requêtes arrivent à la machine qui se trouve en DRP 10.172.40.41. Il faut à présent qu’elles puissent revenir vers le réseau source (10.172.43.0/24)

Cela se fait grace à la passerelle par défaut (qui reste la même pas sur les VMs sauvegardés) 10.172.40.1

6. Le paquet ré-emprunte le tunnel GRE

7. L’utilisateur reçoit le retour du paquet.

Configuration :

Les commandes sont à taper directement en ligne de commande (shell) sur les deux serveurs

Sur serveur VM-GRE SOHO :

iptunnel add tunY mode gre remote 10.173.15.71 local 10.172.43.42 ttl 225
 ifconfig tunY 1.11.11.1/24
 ifconfig tunY up
 ifconfig tunY pointopoint 1.11.11.2
 ip route add 10.172.40.0/23 dev tunY

Sur serveur VM-GRE HQ :

iptunnel add tunX mode gre remote 10.172.43.42 local 10.173.15.71 ttl 225
 ifconfig tunX 1.11.11.2/24
 ifconfig tunX up
 ifconfig tunX pointopoint 1.11.11.1
 ip route add 10.172.43.42/32 dev eth0
 ip route add 10.172.43.0/24 dev tunX

Vérifier le bon fonctionnement (coté HQ) :

root@HQ:~# ifconfig tunX
 tunX Link encap:UNSPEC HWaddr 0A-AD-0F-55-00-00-65-74-00-00-00-00-00-00-00-00
 inet addr:1.11.11.2 P-t-P:1.11.11.1 Mask:255.255.255.0
 UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
 RX packets:294 errors:0 dropped:0 overruns:0 frame:0
 TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:0
 RX bytes:19848 (19.3 KiB) TX bytes:5544 (5.4 KiB)

root@HQ:~# ping 1.11.11.1
 PING 1.11.11.1 (1.11.11.1) 56(84) bytes of data.
 64 bytes from 1.11.11.1: icmp_req=1 ttl=64 time=20.6 ms
 64 bytes from 1.11.11.1: icmp_req=2 ttl=64 time=18.2 ms
 64 bytes from 1.11.11.1: icmp_req=3 ttl=64 time=18.8 ms
 ^C
 1.11.11.1 ping statistics ---
 3 packets transmitted, 3 received, 0% packet loss, time 2003ms
 rtt min/avg/max/mdev = 18.238/19.255/20.637/1.019 ms

Les commentaires sont fermés.