Il y a trois sortes de tunnels sous Linux : l'IP dans un tunnel IP, le tunnel GRE et les tunnels qui existent en dehors du noyau (comme, par exemple, PPTP).
Les tunnels peuvent faire des choses très inhabituelles et vraiment sympa. Ils peuvent aussi absolument tout détraquer si vous ne les avez pas configurés correctement. Ne définissez pas votre route par défaut sur un tunnel, à moins que vous ne sachiez exactement ce que vous faites.
De plus, le passage par un tunnel augmente le poids des en-têtes (overhead), puisqu'un en-tête IP supplémentaire est nécessaire. Typiquement, ce surcoût est de 20 octets par paquet. Donc, si la taille maximum de votre paquet sur votre réseau (MTU) est de 1500 octets, un paquet qui est envoyé à travers un tunnel sera limité à une taille de 1480 octets. Cela n'est pas nécessairement un problème, mais soyez sûr d'avoir bien étudié la fragmentation et le réassemblage des paquets IP quand vous prévoyez de relier des réseaux de grande taille par des tunnels. Et bien sûr, la manière la plus rapide de creuser un tunnel est de creuser des deux côtés.
Ce type de tunnel est disponible dans Linux depuis un long moment. Il nécessite deux modules, ipip.o et new_tunnel.o.
Disons que vous avez trois réseaux : 2 réseaux internes A et B, et un réseau intermédiaire C (ou disons Internet). Les caractéristiques du réseau A sont :
réseau 10.0.1.0
masque de sous-réseau 255.255.255.0
routeur 10.0.1.1
et le réseau B :
réseau 10.0.2.0
masque de sous-réseau 255.255.255.0
routeur 10.0.2.1
En ce qui concerne le réseau C, nous supposerons qu'il transmettra n'importe quel paquet de A vers B et vice-versa. Il est également possible d'utiliser l'Internet pour cela.
Voici ce qu'il faut faire :
Premièrement, assurez-vous que les modules sont installés :
insmod ipip.o
insmod new_tunnel.o
Ensuite, sur le routeur du réseau A, faites la chose suivante :
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
et sur le routeur du réseau B :
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0
Et quand vous aurez terminé avec votre tunnel :
ifconfig tunl0 down
Vite fait, bien fait. Vous ne pouvez pas transmettre les paquets de diffusion (broadcast), ni le trafic IPv6 à travers un tunnel IP-IP. Vous ne pouvez connecter que deux réseaux IPv4 qui, normalement, ne seraient pas capables de se "parler", c'est tout. Dans la mesure où la compatibilité a été conservée, ce code tourne depuis un bon moment, et il reste compatible depuis les noyaux 1.3. Le tunnel Linux IP dans IP ne fonctionne pas avec d'autres systèmes d'exploitation ou routeurs, pour autant que je sache. C'est simple, ça marche. Utilisez-le si vous le pouvez, autrement utilisez GRE.
GRE est un protocole de tunnel qui a été à l'origine développé par Cisco, et qui peut réaliser plus de choses que le tunnel IP dans IP. Par exemple, vous pouvez aussi transporter du trafic multi-diffusion (multicast) et de l'IPv6 à travers un tunnel GRE.
Dans Linux, vous aurez besoin du module ip_gre.
Dans un premier temps, intéressons-nous au tunnel IPv4 :
Disons que vous avez trois réseaux : 2 réseaux internes A et B, et un réseau intermédiaire C (ou disons Internet).
Les caractéristiques du réseau A sont :
réseau 10.0.1.0
masque de sous-réseau 255.255.255.0
routeur 10.0.1.1
Et pour le réseau B :
réseau 10.0.2.0
masque de sous-réseau 255.255.255.0
routeur 10.0.2.1
En ce qui concerne le réseau C, nous supposerons qu'il transmettra n'importe quels paquets de A vers B et vice-versa. Comment et pourquoi, on s'en fiche.
Sur le routeur du réseau A, nous faisons la chose suivante :
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
Discutons un peu de cela. Sur la ligne 1, nous avons ajouté un périphérique tunnel, que nous avons appelé netb (ce qui est évident, dans la mesure où c'est là que nous voulons aller). De plus, nous lui avons dit d'utiliser le protocole GRE (mode gre), que l'adresse distante est 172.19.20.21 (le routeur de l'autre coté), que nos paquets "tunnelés" devront être générés à partir de 172.16.17.18 (ce qui autorise votre serveur à avoir plusieurs adresses IP sur le réseau C et ainsi vous permet de choisir laquelle sera utilisée pour votre tunnel) et que le champ TTL de vos paquets sera fixé à 255 (ttl 255).
Sur la deuxième ligne, nous avons donné à cette nouvelle interface l'adresse 10.0.1.1. C'est bon pour de petits réseaux, mais quand vous commencez une exploitation minière (BEAUCOUP de tunnels !), vous pouvez utiliser une autre gamme d'adresses IP pour vos interfaces "tunnel" (dans cet exemple, vous pourriez utiliser 10.0.3.0).
Sur la troisième ligne, nous positionnons une route pour le réseau B. Notez la notation différente pour le masque de sous-réseau. Si vous n'êtes pas familiarisé avec cette notation, voici comment ça marche : vous écrivez le masque de sous-réseau sous sa forme binaire, et vous comptez tous les 1. Si vous ne savez pas comment faire cela, rappelez-vous juste que 255.0.0.0 est /8, 255.255.0.0 est /16 et 255.255.255.0 est /24. Et 255.255.254.0 est /23, au cas où ça vous intéresserait.
Mais arrêtons ici, et continuons avec le routeur du réseau B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta
Et quand vous voudrez retirer le tunnel sur le routeur A :
ip link set netb down
ip tunnel del netb
Bien sûr, vous pouvez remplacer netb par neta pour le routeur B.
BON GROS AVERTISSEMENT !
Ce qui suit n'est pas testé. Vous opérez à vos risques et périls. Ne dites pas que je ne vous avais pas prévenu.
FIXME: vérifier et essayer tout ceci.
De petites choses à propos des adresses IPv6 :
Les adresses IPv6 sont, en comparaison avec les adresses IPv4, monstrueusement grosses. Voici un exemple :
3ffe:2502:200:40:281:48fe:dcfe:d9bcDonc, pour rendre l'écriture plus facile, il y a quelques règles :
::. Vous ne pouvez faire cela qu'une seule fois par
adresse et seulement pour une longueur de 16 bits.
À propos des tunnels.
Supposons que vous ayez le réseau IPv6 suivant, et que vous vouliez le connecter à une dorsale IPv6 (6bone), ou à un ami.
Réseau 3ffe:406:5:1:5:a:2:1/96
ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone
Voyons cela de plus près. Sur la première ligne, nous avons créé un périphérique tunnel appelé sixbone. Nous lui avons affecté le mode "sit" (qui est le tunnel IPv6 sur IPv4) et lui avons dit où l'on va (remote) et d'où l'on vient (local). TTL est configuré à son maximum, 255. Ensuite, nous avons rendu le périphérique actif (up). Puis, nous avons ajouté notre propre adresse réseau et configuré une route pour 3ffe::/15 à travers le tunnel.
Les tunnels GRE constituent actuellement le type préféré de tunnel. C'est un standard qui est largement adopté, même à l'extérieur de la communauté Linux, ce qui constitue une bonne raison de l'utiliser.
Il y a des dizaines d'implémentations de tunnels à l'extérieur du noyau. Les plus connus sont bien sûr PPP et PPTP, mais il y en a bien plus (certains propriétaires, certains sécurisés, d'autres qui n'utilisent pas IP), qui dépassent le cadre de cet HOWTO.