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.
modprobe ip_gre ;ip tunnel add netb mode gre remote 80.8.147.232 local 81.248.152.18 ttl 255 ;80.8.147.232 ;81.248.152.18 ;ip link set netb up ;ip addr add 172.16.254.1 dev netb ;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).
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 ;est 81.248.152.18 ;80.8.147.232 ;ip link set neta up ;ip addr add 192.168.0.252 dev neta ;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 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
Notez le MTU qui diminue à chaque niveau, ce qui est normal. Dans cette situation, nous avons sur Ethernet (niveau 2) :
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 :
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 ?.
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.