Construction et essais

Reprenons la topologie utilisée :

Les deux réseaux A et B sont les mêmes que définis sur la page « Virtual Private Network ».

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.

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

• Amener les outils. Il faut charger le module nécessaire à la construction du tunnel :
  modprobe ip_gre ;
• Construire le tunnel :
  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) ;
• Monter l'interface réseau :
  ip link set netb up ;
• Lui donner une adresse IP qui sera la même que celle de l'interface qui supporte le tunnel dans le réseau local :
  ip addr add 172.16.254.1 dev netb ;
• Ici il s'agit de 172.16.254.1 ;
• Baliser la route vers le réseau B :
  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).

• Amener les outils. Il faut charger le module nécessaire à la construction du tunnel :
  modprobe ip_gre ;
• Construire le tunnel :
  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) ;
• Monter l'interface réseau :
  ip link set neta up ;
• Lui donner une IP qui sera la même que celle de l'interface qui supporte le tunnel dans le réseau local :
  ip addr add 192.168.0.252 dev neta ;
• Ici il s'agit de 192.168.0.252 ;
• Baliser la route vers le réseau A :
  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 maintenant souvent utilisée pour identifier un réseau. le “/16” indique que les 16 bits les plus lourds, les plus à gauche, sont les seuls bits à considérer pour identifier le réseau. Autrement dit, que le masque de sous réseau est 255.255.0.0

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

• 25: ppp0 est le lien PPP vers le réseau du fournisseur d'accès internet ;
• 26: gre@NONE est le tunnel lui-même ;
• 27: neta@NONE est l'interface virtuelle, qui correspond à l'extrémité du tunnel.

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

• Une couche PPP (PPPoE) ;
  • une couche IP sur ce lien PPP ;
    • un tunnel GRE sur cette couche IP ;
      • une couche IP dans le tunnel.

Les encapsulations successives entrainent à 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 apparait comme un protocole intermédiaire, nous le reverrons plus pratiquement sur une analyse de trames.

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)

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 :

• depuis chez vous sous Windows , accéder à votre répertoire partagé sur votre lieu de travail par le voisinage réseau Microsoft,
• en utilisant la connexion du bureau à distance, vous pouvez depuis chez vous travailler sur votre poste de travail professionnel,
• et d'une manière générale, depuis chez vous, vous pouvez faire tout ce que vous faites sur votre lieu de travail.

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.

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

• Les données ne sont pas chiffrées dans le tunnel,
• les deux extrémités du tunnel ne disposent d'aucun processus d'authentification.

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.