Le tunnel GRE
09/02/2005
 Christian CALECA 
Liste des cours

Tunnel GRE

Accueil ] [ Le principe ] [ Tunnel GRE ] [ Le protocole ] [ Utilisation ] [ Limites ]


Avertissements

Il existe avec Linux un type de tunnel qui encapsule de l'IP sur IP. Cette solution n'existe, semble-t-il, que sous Linux et reste assez limitative. Nous allons plutôt utiliser une méthode normalisée, à peine plus complexe : le tunnel GRE. Ne confondez donc pas ces deux possibilités.

Le tunnel GRE (Generic Routine Encapsulation) fonctionne parfaitement. C'est un protocole ouvert, initialement développé par CISCO, et qui peut donc se mettre en place sur des plate-formes différentes. Il est défini par la RFC 2784

Malheureusement, ce n'est pas un protocole sécurisé. Si vous l'utilisez sur l'internet, mesurez les risques que vous prenez ! 

Faites une recherche sur les façons de prendre possession d'un réseau utilisant un tel tunnel et vous serez fixé. Ce n'est pas facile à faire, mais c'est tout à fait réalisable. Vous êtes prévenu.

(Je l'ai peut-être déjà dit...)

Construction

Juste pour voir comme c'est simple à monter, et comme un tunnel peut rendre des services, nous allons tout de même en réaliser un, le temps de faire la manip.

Reprenons la topologie utilisée :

Les deux réseaux

Les deux réseaux A et B sont les mêmes que définis sur la page précédente.

Les deux routeurs sont des machines sous Linux, avec un noyau 2.4.x. Il nous faut disposer d' iproute2. Toutes les distributions le proposent, mais ne l'installent pas forcément par défaut.

On creuse

Un tunnel, ça se creuse des deux côtés à la fois. Il faut donc intervenir sur les deux routeurs.

Réseau A

modprobe ip_gre
ip tunnel add netb mode gre remote 80.8.147.232 local 81.248.152.18 ttl 255
  • netb est le nom de la nouvelle interface réseau qui va conduire au réseau B,
  • l'adresse IP de l'autre bout du tunnel (remote) est 80.8.147.232,
  • l'adresse IP de ce bout-ci du tunnel (local) est 81.248.152.18
  • on indique un ttl (time to live) maximum (255)
ip link set netb up
ip addr add 172.16.254.1 dev netb
  • Ici il s'agit de 172.16.254.1
  • ip route add 192.168.0.0/24 dev netb

Et voilà. Le tunnel est creusé du côté A. Reste à refaire la même chose du côté B (aux adresses IP près).

Réseau B

modprobe ip_gre
ip tunnel add neta mode gre remote 81.248.152.18 local 80.8.147.232 ttl 255
  • neta est le nom de la nouvelle interface réseau qui va conduire au réseau A
  • l'adresse IP de l'autre bout du tunnel (remote) est 81.248.152.18,
  • l'adresse IP de ce bout-ci du tunnel (local) est 80.8.147.232,
  • on indique un ttl (time to live) maximum (255)
ip link set neta up
ip addr add 192.168.0.252 dev neta
  • Ici il s'agit de 192.168.0.252
  • ip route add 172.16.0.0/16 dev neta

Et le tunnel est entièrement creusé et opérationnel. Bien entendu, il vous faudra ajouter dans les règles IPtables, ce qui est nécessaire pour que ça fonctionne. C'est à vous de voir en fonction de vos règles en place. On peut imaginer que ces choses du genre :

iptables -A FORWARD -i netb -j ACCEPT
iptables -A FORWARD -o netb -j ACCEPT

dans le réseau A, et 

iptables -A FORWARD -i neta -j ACCEPT
iptables -A FORWARD -o neta -j ACCEPT

dans le réseau B permettront de laisser passer le trafic dans le tunnel, mais il peut être utile, voire nécessaire, de faire des choses moins permissives.

Note:
La notation de type 172.16.0.0/16 est souvent utilisée pour identifier un réseau. le "/16" indique que les 16 bits les plus lourds (le plus à gauche) sont les seuls bits à considérer pour identifier le réseau.
Autrement dit, ça revient à dire que le masque de sous réseau est 255.255.0.0

Vérifications

Les interfaces

Utilisons iproute2, puisque nous l'avons :

gw2:~# ip link list
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 52:54:05:fc:ad:0c brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:20:af:2f:5d:16 brd ff:ff:ff:ff:ff:ff
25: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3
link/ppp
26: gre0@NONE: <NOARP> mtu 1476 qdisc noop
link/gre 0.0.0.0 brd 0.0.0.0
27: neta@NONE: <POINTOPOINT,NOARP,UP> mtu 1468 qdisc noqueue
link/gre 80.8.147.132 peer 81.248.152.18

Notez le MTU qui diminue à chaque niveau, ce qui est normal. Dans cette situation, nous avons sur Ethernet (niveau 2) :

Les encapsulations successives entraînent à chaque étape, une diminution de la charge utile des paquets ("payload"), donc le MTU diminue.

Notez bien la particularité de GRE : Ce n'est pas à proprement parler de l'IP sur IP, mais de l'IP dans GRE dans de l'IP. GRE apparaît comme un protocole intermédiaire, nous le reverrons plus pratiquement sur une analyse de trames.

Snif d'un ping

Nous allons faire un petit ping depuis une machine du réseau B (192.168.0.10) vers une machine du réseau A (172.16.252.2).

Nous observons les trames au niveau du routeur B sur l'interface neta (donc au niveau de l'extrémité du tunnel) :

Frame 1 (76 bytes on wire, 76 bytes captured)
    Arrival Time: Mar  3, 2004 16:05:17.050838000
    Time delta from previous packet: 0.000000000 seconds
    Time since reference or first frame: 0.000000000 seconds
    Frame Number: 1
    Packet Length: 76 bytes
    Capture Length: 76 bytes
Linux cooked capture
    Packet type: Sent by us (4)
    Link-layer address type: 778
    Link-layer address length: 0
    Source: <MISSING>
    Protocol: IP (0x0800)

# Comme c'est finalement assez logique, nous ne trouvons pas sur cette interface 
# de couche  Ethernet.
# Il nous faudrait étudier de façon plus précise le protocole GRE, mais ce n'est
# pas l'objet de ce chapitre.

Internet Protocol, Src Addr: 192.168.0.10, Dst Addr: 172.16.252.2
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 60
    Identification: 0x1b61 (7009)
    Flags: 0x00
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 127
    Protocol: ICMP (0x01)
    Header checksum: 0x9d0c (correct)
    Source: 192.168.0.10 (192.168.0.10)
    Destination: 172.16.252.2 (172.16.252.2)
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0 
    Checksum: 0x2d5c (correct)
    Identifier: 0x0200
    Sequence number: 0x1e00
    Data (32 bytes)
0000  61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70   abcdefghijklmnop
0010  71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69   qrstuvwabcdefghi

Et la réponse :

Frame 2 (76 bytes on wire, 76 bytes captured)
    Arrival Time: Mar  3, 2004 16:05:17.177500000
    Time delta from previous packet: 0.126662000 seconds
    Time since reference or first frame: 0.126662000 seconds
    Frame Number: 2
    Packet Length: 76 bytes
    Capture Length: 76 bytes
Linux cooked capture
    Packet type: Unicast to us (0)
    Link-layer address type: 778
    Link-layer address length: 0
    Source: <MISSING>
    Protocol: IP (0x0800)
Internet Protocol, Src Addr: 172.16.252.2, Dst Addr: 192.168.0.10
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 60
    Identification: 0x067e (1662)
    Flags: 0x00
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 127
    Protocol: ICMP (0x01)
    Header checksum: 0xb1ef (correct)
    Source: 172.16.252.2 (172.16.252.2)
    Destination: 192.168.0.10 (192.168.0.10)
Internet Control Message Protocol
    Type: 0 (Echo (ping) reply)
    Code: 0 
    Checksum: 0x355c (correct)
    Identifier: 0x0200
    Sequence number: 0x1e00
    Data (32 bytes)
0000  61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70   abcdefghijklmnop
0010  71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69   qrstuvwabcdefghi

Ca marche. Vu au niveau de l'interface neta, tout se passe comme nous avons l'habitude de le voir sur un réseau IP. Notez toutefois que le sniffeur ne reconnaît pas la couche de niveau 2 (ce qui est surligné en bleu pâle)

Conclusions

Mesurez bien la portée de ce que nous venons de faire...

Au travers de l'internet, nous avons créé une liaison spécialisée virtuelle qui permet de relier entre eux deux réseaux IP. Ces deux réseaux sont constitués avec des IP privées, et semblent simplement inter-connectés par un routeur. Une adresse IP privée du réseau A dialogue sans problème avec une autre adresse IP privée du réseau B, et réciproquement. Pourtant, le lien entre ces deux réseaux est bel et bien bâti sur l'internet, où ces adresses IP privées sont bannies.

En d'autres termes, Si le réseau B est le réseau de votre lieu de travail et le réseau A celui de votre domicile, vous pouvez par exemple :

Bien entendu, vous êtes tout de même limité par le débit de votre connexion. Vous aurez un tuyau d'environ 128 kbps dans le cas le plus courant d'une connexion de type ADSL, rien de comparable, donc, avec un réseau local qui sera au minimum de 10 Mbps.

Mais encore une fois attention !!!

Ce type de tunnel n'est absolument pas sécurisé, vous l'ais-je déjà dit ?.

Donc, si ce tunnel est en théorie magnifique, en pratique, il l'est beaucoup moins.

Dommage...

Heureusement, d'autres solutions plus sécurisées existent, qui permettent d'aboutir au même résultat sans prendre autant de risques. Ces solutions ne sont pas abordées pour l'instant dans ce chapitre, basées sur le chiffrement et l'authentification.


Précédente ] [ Accueil ] [ Suivante ]