Linux Attitude

^--- billet invité

Niveau :
Résumé : proxy ndp

Aujourd'hui nous allons parler d'IPv6. Pas du troll sur son arrivée imminente (ou pas), mais de situations qui nécessitent l'utilisation d'une fonctionnalité du noyau linux appelée proxy NDP.

Rappels sur IPv6 et NDP (les habitués d'IPv6 peuvent passer)

En IPv4, on dispose du protocole ARP pour trouver, à partir de l'adresse IP, l'adresse MAC à laquelle envoyer le paquet Ethernet sur le même réseau. Si c'est sur un autre réseau, il suffit d'avoir une table de routage et de connaître le routeur (la passerelle) pour cette destination, à qui on envoie le paquet.

En IPv6, on fait fi d'ARP pour utiliser ICMPv6. Vous me direz, on ne fait que reporter le problème, on n'a toujours pas l'adresse MAC : c'est là qu'intervient la notion de lien local. En effet vous avez déjà du remarquer qu'à peine votre interface réseau montée, vous disposez d'une adresse de lien local (obtenue à partir de votre adresse MAC).

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:19:66:8c:b0:d9
          inet6 addr: fe80::219:66ff:fe8c:b0d9/64 Scope:Link
[...]

De la même manière, vos voisins sur le même lien Ethernet ont leur adresse de lien local, et c'est en utilisant celle-ci combinée au protocole ICMPv6 qu'on voit passer les requêtes NDP (Neighbor Discovery Protocol) de découverte de voisinage. On y retrouve exactement le principe de l'ARP d'IPv4 (who has/target is at), avec un nouveau vocabulaire (neighbor solicitation/neighbor advertisement).

# tcpdump -ni eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

16:06:29.756895 IP6 2a01:e35:3e93:68c0:4d0a:f82b:3678:aaac > ff02::1:ff8c:b0d9: ICMP6, neighbor solicitation, who has 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9, length 32

16:06:29.757294 IP6 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9 > 2a01:e35:3e93:68c0:4d0a:f82b:3678:aaac: ICMP6, neighbor advertisement, tgt is 2a01:e35:3e93:68c0:219:66ff:fe8c:b0d9, length 32

Position du problème

Ce petit rappel étant fait, voici le problème que l'on peut rencontrer en IPv6 : un fournisseur de connectivité IPv6 vous donne (annonce) depuis son routeur un /N sur lequel vous pouvez utiliser des adresses IPv6. Là où le bât blesse, c'est que son routeur désire voir à plat (sur le même lien local) toutes les IPv6. Impossible donc à première vue de placer votre routeur juste après celui du fournisseur et d'organiser les IPv6 en réseaux comme bon vous semble. A noter qu'on rencontre le même problème en IPv4 avec un fournisseur qui donne un /N et qui veut le voir à plat. Dans ce cas de figure, on peut utiliser le proxy ARP (dans le noyau). La méthode pour l'IPv6 présentée plus bas est ni plus moins son homologue en IPv6.

On rencontre cette situation par exemple chez Free, où la Freebox annonce un /64 (l'abonné dispose même d'un /60), ou encore chez OVH lorsque vous possédez un serveur dédié, où le routeur d'OVH vous annonce un /56 rien que pour vous (même si dans le manager c'est indiqué un /64, vous pouvez utiliser ce /56). Je présume que c'est le cas pour d'autres opérateurs, ou d'autres hébergeurs comme Dedibox.

Que l'on veuille organiser son réseau domestique avec son propre routeur IPv6 derrière sa freebox, ou que l'on veuille répartir en sous-réseaux le /56 de son serveur dédié dans des machines virtuelles ou des containers, le routeur veut voir le réseau à plat (sur le même lien) c'est ce qui pose problème. La solution évidente serait de pouvoir faire du routage : si on pouvait intervenir sur la table de routage de ce routeur (via le manager d'OVH, via la console de gestion de Free, ou via le protocole DHCPv6 s'il est implémenté me dit peck (NDM(note de moi): rechercher prefix delegation)), il suffirait de dire que pour joindre tel sous-réseau il faut contacter le routeur à l'adresse donnée. Malheureusement, on ne peut pas pour l'instant, il faut donc trouver autre chose.

La solution que je vais vous proposer et détailler est un proxy NDP : il s'agit de faire croire au routeur (la freebox ou le routeur OVH) qu'il voit votre réseau à plat (sur le même lien), en transférant les messages NDP d'un côté et de l'autre. Cette solution n'est pas nouvelle : Thierry Fournier propose depuis maintenant 1 an et demi un excellent tutorial rapportant son expérience avec l'IPv6 chez Free et comment il a organisé son réseau domestique. Le Wiki Gentoo dispose lui aussi d'un excellent article à ce sujet.

Une autre solution, plus ancienne, est d'utiliser le brouting ou switch filtrant (on route l'IPv4 et on laisse passer l'IPv6), mais je ne la détaillerai pas.

Solution à base de proxy NDP

Pour résumer, il va s'agir de :

• posséder un noyau linux supérieur à 2.6.19, à partir duquel le proxy NDP a été implémenté
• activer le routage IPv6 et le proxy NDP dans le noyau
• organiser son réseau (côté routeur) en sous-réseaux (côté LAN)
• router ces sous-réseaux du routeur vers les LANs
• configurer les hôtes
• configurer le proxy NDP côté LAN pour que les hôtes aient connaissance du routeur
• configurer le proxy NDP côté routeur pour que le routeur ait connaissance des hôtes

Pour la suite, comme les explications pour Free ont déjà été données sur Internet, je vous propose d'expliquer le proxy NDP dans le contexte d'un serveur dédié chez OVH avec des machines virtuelles (VM). Notez bien que c'est le même principe, juste le contexte de l'explication qui diffère.

Voyons comment ce réseau IPv6 s'organise :

.----------. 2001:2:3:4500::/56   .---------------.
| routeur  |______________________|    serveur    |
|   IPv6   |                  eth0|     dédié     |
*----------*                      *---------------*
                                veth1 |        | veth2
                                      |        |
                   2001:2:3:4501::/64 |        | 2001:2:3:4502::/64
                                      |        |
                                 eth0 |        | eth0
                                    [VM 1]   [VM 2]

Comme vous le voyez, le routeur fournit à ce serveur le préfixe 2001:2:3:4500::/56 :

2001:0002:0003:45 00::
\_______________/ \_..._/
 partie réseau     partie pour le serveur
    (56)            (72)

Que l'on va diviser en deux /64 pour chaque VM :

• 2001:2:3:4501::/64 pour la VM1
• 2001:2:3:4502::/64 pour la VM2

A noter que chez OVH, votre routeur est joignable sur le /56 suivi de 5*FF. Supposons alors que dans notre cas, le routeur soit à l'adresse 2001:2:3:45FF:FF:FF:FF:FF.

Sur le serveur, on route ces sous-réseaux vers les VM :

# ip route add 2001:2:3:4501::/64 dev veth1
# ip route add 2001:2:3:4502::/64 dev veth2
# ip -6 route list
2001:2:3:4501::/64 dev veth1  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:4502::/64 dev veth2  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:45FF:FF:FF:FF:FF dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:4500::/56 dev eth0  proto kernel  metric 256  expires 2427074sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev veth1  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev veth2  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295

Avant d'aller plus loin, n'oubliez pas d'activer le routage IPv6 ainsi que le proxy NDP. Par exemple avec les directives suivantes dans /etc/sysctl.conf suivi d'un sysctl -p pour appliquer :

net.ipv6.conf.default.forwarding=1
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.proxy_ndp=1
net.ipv6.conf.all.proxy_ndp=1

Bien entendu, vous pouvez activer cela plus finement uniquement sur les interfaces concernées.

Pour la configuration des hôtes, il s'agit juste de leur indiquer qui est leur routeur, la route par défaut vers ce routeur, et enfin d'ajouter une ou plusieurs adresses dans le préfixe alloué. Par exemple, on configure la VM1 avec l'adresse 2001:2:3:4501::1/64 :

# ip route add 2001:2:3:45ff:ff:ff:ff:ff/128 dev eth0
# ip route add default via 2001:2:3:45ff:ff:ff:ff:ff
# ip address add 2001:2:3:4501::1/64 dev eth0
# ip -6 route list
2001:2:3:4501::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:2:3:45ff:ff:ff:ff:ff dev eth0  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
# ip -6 address list
1: lo:  mtu 16436
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0:  mtu 1500
    inet6 2001:2:3:4501::/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::218:51ff:fede:aca9/64 scope link
       valid_lft forever preferred_lft forever

La même chose pour la VM2 avec l'adresse 2001:2:3:4502::1/64.

Il faut maintenant configurer le proxy NDP côté LAN pour que les hôtes (VM) aient connaissance du routeur. Sur le serveur et pour chaque interface où il faut faire apparaître le routeur avec le proxy NDP, procéder comme suit :

# ip neigh add proxy 2001:2:3:45ff:ff:ff:ff:ff dev veth1
# ip neigh add proxy 2001:2:3:45ff:ff:ff:ff:ff dev veth2

La même chose de l'autre côté pour que le routeur ait connaissance des VM. Pour chaque adresse IPv6 utilisée par les hôtes (VM), il faut explicitement la faire apparaître avec le proxy NDP. Par exemple pour les 2 VM où on a configuré l'adresse ::1 :

# ip neigh add proxy 2001:2:3:4501::1 dev eth0
# ip neigh add proxy 2001:2:3:4502::1 dev eth0

Enfin, il faut mettre l'interface côté routeur en mode promiscuous, afin de pouvoir prendre les paquets qui ne lui sont pas destinés mais destinés aux VM :

# ifconfig eth0 promisc

Les interfaces vers les VM n'en ont pas besoin car elles sont virtuelles. Dans le cas de Free avec des hôtes réels connectés à une interface réelle, il sera nécessaire de mettre l'interface côté hôtes en mode promiscuous aussi.

Maintenant, vous devriez avoir l'IPv6 disponible sur vos VM, et organisé comme il vous plaît. Si cela ne fonctionne pas, vous pouvez analyser le réseau en différents points (eth0, veth1, veth2, eth0 des VM) pour voir (ou ne pas voir justement) les paquets IPv6 qui passent :

tcpdump -ni <interface> ip6

Enfin, comme le fait remarquer l'article sur le wiki Gentoo, on peut procéder à la configuration automatique des VM en faisant tourner un démon radvd sur le serveur pour annoncer le préfixe utilisable ainsi que l'adresse du routeur. Cela ne vous affranchira cependant pas d'ajouter manuellement le proxy NDP pour chaque IPv6 utilisée, et c'est l'inconvénient majeur de cette technique. Mais après tout, dans le cas de serveurs les IPv6 utilisées sont choisies à l'avance, et pour les postes clients le plus souvent l'adresse IPv6 est obtenue à partir de l'adresse MAC, alors on s'en sort.

Si vous trouvez un moyen de voir les IPv6 utilisées dans les sous-réseaux et d'automatiquement ajouter le proxy NDP, faites-le savoir ! Ça doit être faisable à coup de tcpdump sur les neighbor solicitation, mais c'est moche...

J'espère avoir été clair et vous souhaite de bien vous amuser avec l'IPv6 ! Si vous avez des questions, n'hésitez pas.

NDM: il y a moyen de faire sans promisc et avec du proxy NDP d'un coté seulement, mais reste a retrouver les bonne conditions pour que ça marche.

Niveau :
Résumé :lo ; 127.0.0.1

L'interface de loopback se retrouve sur toutes les machines ou presque. pensez à l'activer si ce n'est pas fait par défaut car un certain nombre d'applications en dépendent et son absence peut parfois mener à des bugs inexplicables (à ce propos évitez de mettre un firewall bloquant 127.0.0.1 ...). Mais comment fonctionne-t-elle ?

Localhost

Tout d'abord l'adresse de loopback (127.0.0.1) permet par convention de contacter la machine locale sans passer par une interface qui serait accessible de l'extérieur. Cette fonctionnalité est en soit disponible sur n'importe quelle interface réseau. Il faut juste ajouter une entrée de firewall pour éviter l'accès depuis l'extérieur. Exemple pour prouver que c'est une ip comme une autre :

# on enlève le range d'ip de l'interface lo
$ ip addr del 127.0.0.1/8 dev lo
# on l'ajoute à une interface physique
$ ip addr add 127.0.0.1/8 dev eth0
# on teste
$ ping 127.0.0.1

En pratique, rien n'empêche cette ip d'être accessible publiquement si ce n'est que ce n'est pas recommandé et que linux ne répondra pas (je n'ai pas vraiment cherché à savoir pourquoi).

Device lo

Lo est l'interface de loopback. Celle sur laquelle on met habituellement l'adresse de localhost. Mais cela n'empêche de mettre d'autres ip sur cette interface. Dans un contexte de routeur c'est même très fréquent. Le routeur dispose d'un ip publique qui n'est sur aucune de ses interfaces.

Exemple :

$ ip addr add 172.16.20.1 dev lo
$ ping 172.16.20.1

Le but n'est pas de contacter localhost, mais de contacter le routeur depuis n'importe où, à travers n'importe quelle interface, cette ip est indépendante de l'état des différentes cartes réseaux.

Exemple dans lequel m1 serait un routeur ayant une interface 10.0.0.1 connectée à m2 directement sur le même réseau :

# Première machine
m1$ ip addr add 172.16.20.1 dev lo
m1$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Deuxième machine, on contacte le loopback de m1
m2$ ip route add 172.16.20.1 via 10.0.0.1
m2$ ping 172.16.20.1

L'interface de m1 agit comme un routeur pour son ip de loopback.

Un autre usage particulier de cette adresse est d'autoriser plusieurs machines à disposer de la même ip, sans les annoncer sur le réseau (puisqu'elles ne sont sur aucune interface publique). On peut ainsi éviter les conflits (arp ...). C'est par exemple la solution retenue pour faire de la répartition de charge avec keepalived entre plusieurs serveurs ayant la même ip publique.

Niveau :
Résumé : ngrep ; netsed ; tcpdump | strings

Grep

Pour lire ce qui passe en TCP en filtrer des mots clés vous avez plusieurs techniques.

Commençons par la technique bourrin, mais qui marche :

# on dumpe en gardant les data, dont on extrait les chaines de caractère
$ tcpdump -s0 -w - port 80 | strings | egrep "html|head"

Pratique et facile à mémoriser. Cette technique permet pas mal de choses, mais est à considérer pour des serveur peu chargés.

Ngrep

Ngrep lui, est capable de vous sortir uniquement les paquets dont les données matchent une expression. L'usage n'est pas forcément le même que le précédent, ici on a un paquet complet :

$ ngrep "html|head" "port 80"

Pratique quand on est à la recherche d'un paquet foireux, ou qu'on veut loguer ce qui ce passe pendant un problème.

Sed

Un autre outil pour tester une application réseau, c'est netsed (du paquet bien nommé). Une commande bien utile qui crée un proxy tcp ou udp capable de modifier les paquets en direct.

Il ne fait ça qu'avec des expressions basiques :

# Attention pas de résolution de nom
$ netsed tcp 1080 1.2.3.4 80 's/Developpement/Production'
# Test 
$ telnet localhost 1080

Attention, contrairement à ce qu'on pourrait croire, ce ne sont pas des vraies expression sed, on est assez limité. D'autre part netsed fonctionne sur des paquets, ce qui veut dire que dans un petit nombre de cas, il ne fait pas ce qu'on veut (données à matcher répartie sur 2 paquets).

En fait, il faut prendre cet outil pour ce qu'il est, un outil de test et de debug. D'autant plus qu'il faut toucher au client pour le rediriger vers le port d'écoute de netsed.

Niveau :
Résumé : wireshark ; tcpdump

Face à un problème de communication, on en est souvent réduit aux outils de base : un sniffer.

tcpdump

Le sniffer le plus connu est tcpdump. Si vous ne l'avez pas encore utilisé, man est votre ami. Mais il est très simple. Petit exemple en root :

$ tcpdump host 1.2.3.4 and port 80

Le langage de filtrage de tcpdump est assez simple, pour l'apprendre, chercher la section "expression" dans le manuel de tcpdump. Mais finalement, la sortie de cet outil n'est pas très passionnante, et à moins de savoir décoder le tcp/ip à la vitesse de la lumière ou d'avoir besoin juste d'une petite information (les paquets passent ? combien ? ...), il est un peu ardu à utiliser.

Tout de même, les quelques options à connaître :

• -e : pour des problèmes au niveau ethernet
• -i : pour écouter sur une interface (attention le any par défaut n'inclue pas le loopback)
• -s 0 : pour stocker l'intégralité des paquets capturés (à utiliser de préférence avec -w)
• -w fichier : stocke les données dans un fichier pour analyse ultérieure

wireshark

De son ancien nom ethereal, wireshask est l'équivalent graphique de tcpdump. On ne se rend pas compte sans l'avoir testé de tout ce qu'apporte la version graphique. L'analyse de paquet est plus détaillée qu'avec tcpdump, on peut demander des infos a posteriori à coup de clic ou filtrer une unique communication.

Utilisez par exemple sudo (ou xauth) pour lancer facilement wireshark en tant que root. Wireshark utilise les mêmes filtres que tcpdump. Pratique, votre apprentissage n'est pas perdu.

Voici ce que donne une capture.

Remarquez que vous pouvez aisément analyser le contenu des paquets en bas, couche par couche.

Et parlons de l'une des fonctionnalités les plus importantes de wireshark : "follow TCP stream" dans le menu "analyse". Cette fonction vous permet de lire tout le dialogue TCP comme si vous y étiez. Qui vous donne l'écran suivant. Au passage, ne soyez pas surpris d'avoir "perdu" des paquets, cette fonctionnalité en profite pour ajouter un filtre sur la connexion considérée.

tcpdump + wireshark

Et maintenant si la machine que vous voulez analyser est un serveur ? Ce qui est souvent le cas. Hé bien on combine les deux.

# sur le serveur
$ tcpdump -i eth0 -s0 -w /tmp/dump0.cap
# sur un client quelconque avec wireshark
$ scp serveur:/tmp/dump0.cap .
# puis cliquer sur open dans wireshark pour lire la capture ainsi obtenue

Et la lecture se passe de la même façon que si la capture s'était faite sur la machine locale.

Edit : on me fait remarquer une meilleure méthode pour faire tout cela en une ligne (note, toujours faire tenir les commandes sur une seule ligne, ça facilite les essais successifs).

# Le user et le sudo sont à moduler selon votre situation
# Attention au cas du port 22 qu'on utilise en direct
$ ssh server "sudo tcpdump -i eth0 -s0 -w - port not 22" | wireshark -i - -k

Pour ceux qui voudraient savoir comment ça marche avec un mot de passe : ça marche bien, puisque ssh comme sudo utilisent le tty pour demander le mot de passe et non pas stdin (vous savez le truc qui fait qu'on ne peut pas mettre le mot de passe dans un script et lui passer en pipe).

Niveau :
Résumé : conntrack

I'm back !
Désolé de vous avoir fait attendre, j'étais en quelque sorte en vacances.

Firewall

Cette fois nous allons parler de firewall. Comme vous le savez, netfilter, le firewall intégré à linux, est statefull par défaut. Ce qui veut dire que si on ne lui dit pas de ne pas le faire, il trace l'état de toutes les connexions qui le traversent. C'est grâce à cela qu'il sait filtrer les connexions avec des règles "simples" ou qu'il est capable de filtrer proprement le ftp.

Pour cela il garde en mémoire une table des connexions établies, qu'il peut communiquer au reste du monde, autrement appelé espace utilisateur. Il expose ces infos dans /proc/net/ip_conntrack* (entre autre, mais n'hésitez pas à regarder le contenu de ce répertoire pour plein de choses intéressantes).

La commande conntrack, du paquet éponyme sert à manipuler la table en question. Toute machine ayant un firewall, ou presque, on peut s'amuser à l'utiliser sur son PC. Mais c'est bien plus rigolo de faire ça sur un routeur ;->

D'ailleurs, si vous avez un serveur qui ne fait pas firewall et qui gère beaucoup de connexions (un serveur de twitter par exemple), vous pouvez désactiver le "connection tracking" pour soulager le noyau de cette tâche. Mais il faut entièrement désactiver le module, ce qui n'est pas des plus simple.

Conntrack

D'abord, commençons par lister les connexions connues :

$ conntrack -L

Pour une machine qui ne fait pas routeur, la liste est similaire à celle obtenue par netstat -atu. Notez les informations intéressantes : état de la connexion, détail de la connexion (remarquez la répétition nécessaire pour le NAT), et surtout nombre de paquets et d'octets passés par cette connexion. Ce compteur peut être réinitialisé avec l'option -z de conntrack :

$ conntrack -L -z

Pratique quand on veut détecter les changements.

Vous pouvez aussi regarder ce qui se passe en direct sur votre routeur :

$ conntrack -E

Mais lisez bien le manuel, pour limiter la sortie, car sur un vrai routeur, il faut filtrer. Man conntrack contient toutes les explications.

Et le plus rigolo sur un routeur partagé, on enlève l'entrée :

# Attention, il faut tout spécifier pour être sûr qu'on parle de la bonne connexion
$ conntrack -D -s 1.2.3.4 -d 4.3.2.1 -p tcp --orig-port-src 5678 --orig-port-dst 22

Cela devrait couper la connexion si le firewall est bien configuré (et probablement aussi s'il est mal configuré). C'est tout de même moins artisanal que l'ancienne technique.

Niveau :
Résumé : ethernet ; ip ; tcp

Aujourd'hui quelques explications de base sur le fonctionnement d'internet pour ceux qui voudraient mieux comprendre l'article précédent. On va parler simplement, experts, passez votre chemin.

Les couches réseau

Le réseau est conçu comme des lasagnes, chaque protocole s'appuie sur un autre protocole de couche inférieure. Ces couches ont été modélisées par l'iso sous le nom de modèle osi, lequel ne sert à rien (si ce n'est une numérotation bizarre) mais qu'il faut connaître (c'est idiot l'informatique parfois).

En pratique les couches sont donc les suivantes :

• 1 physique : câble branché, des ondes passent dessus, on les transforme ensuite en bits -> pour les électriciens, électroniciens, microondistes, opticiologues et optoélectroniciens
• 2 liaison : envoyer des données à l'autre bout du câble (chez vous c'est l'ethernet qui fait ça)
• 3 réseau : envoyer des données partout sur le réseau (sur internet et quasiment partout c'est IP)
• 4 transport : gestion d'une communication avec une autre machine sur la durée (souvent TCP ou UDP)
• 7 au dessus chacun se démerde, ce sont les applications qui implémentent leur protocole (http, smtp ...)

Exemple d'un paquet (à ce niveau on dit une trame) qui passe sur le réseau :

Chaque couche mérite un livre (voire une bibliothèque) à elle seule, je vais donc être nécessairement court. En fait, je vais me concentrer sur les différents équipements qu'on trouve sur chaque couche.

Switch

Le switch c'est ce qui permet d'aller un peu plus loin que le câble tout en restant au niveau ethernet. A partir de l'adresse MAC "to XX:XX" il envoie le paquet sur le bon port et à la bonne machine sans toucher au contenu du paquet.

Le hub lui ressemble, mais ne fait que retransmettre les paquets à tous les ports (sauf celui d'où ils viennent) sans réfléchir.

Il n'y a pas que les switchs qui permettent de traverser plusieurs câbles, il y a aussi les ponts (bridge), qui en général ont pour but de passer d'un type de câble à un autre (par exemple du rj45 au wifi) et qui souvent touchent à l'en-tête ethernet au passage.

Le paquet (la trame) est vu sous cette forme dans un switch :

Le routeur

Le routage c'est ce qui permet à une machine de communiquer avec une autre machine sans pour autant avoir un câble (avec ou sans switch) entre les 2 machines. Le routage s'effectue sur des routeurs (fort hein !) situés entre les machines et reliés entre eux par des protocole de niveau 2. Les routeurs décident par où passent les paquets (au niveau IP) pour atterrir sur linux attitude.

Le paquet (on dit aussi datagramme) vu par le routeur ressemble donc à ceci :

Vous comprenez donc pourquoi le from/to de l'en-tête ethernet qui semblait redondant ne peut plus servir. Une autre en-tête niveau 2 sera générée à la sortie du routeur pour que le paquet continue son chemin.

Le routeur a pour seule activité de lire la partie IP et de choisir la prochaine machine à qui il devra envoyer ce paquet. Il dispose donc d'une table de correspondance qui lui dit quoi faire. Notez que certaines règles font parfois intervenir la couche au dessus d'IP.

Firewall

Au dessus de ça on trouve aussi des firewall qui analysent l'ensemble (mais le plus souvent la partie IP+TCP) et fait une action dessus (suppression, modification ...).

Le paquet vu par le firewall ressemble donc à ceci

Lorsqu'ils analysent la partie data on les qualifie plutôt d'ids (Intrusion Detection System).

Application

Et enfin par dessus l'ensemble on trouve les applications, c'est à dire le serveur et le client codés sans se soucier des autres couches.

Les paquets (qu'on appelle ici segments) pour une application ressemblent donc à ça :

Niveau :
Résumé : ip route ; ip addr ; ip link ; ip neigh

Utilisez-vous encore les anciens outils comme ifcong, route, arp ... oui ? alors il serait temps de vous mettre à jour. Le paquet iproute (version2) contient les nouveaux outils de configuration du réseau pour linux. Les autres commandes ne sont pas près de disparaître, mais les nouvelles disposent de quelques fonctionnalités supplémentaires. De plus ces commandes seront exactement les mêmes lorsque vous passerez à ipv6.

Commençons par quelques équivalents :

$ route add default gw 10.0.0.1
$ ip route add default via 10.0.0.1

$ ifconfig eth0
$ ip addr show dev eth0

$ arp -n
$ ip neigh show 

ip est la commande générique dont l'aide en ligne est formatée, elle apparait lorsqu'une commande n'est pas correcte (attention elle n'est pas toujours complète) :

$ ip help
$ ip route help

Pour la plupart des commandes, ne donner aucun paramètre est équivalent à lui passer show comme paramètre :

$ ip route show
$ ip route

On peut faire des choses assez intéressantes avec la commande ip :

• link : gestion, des cartes réseau
• addr : gestion de l'adresse ip (ou des adresses ip)
• route : gestion de la table de routage
• neigh : gestion de la table arp
• tunnel : gestion des tunnels
• rule : gestion des règles indiquant quelle table de routage choisir (hé oui il peut y en avoir plusieurs)

Pour le reste vous trouverez vous-même.

Quelques commandes particulièrement intéressantes. ip link :

# allumer/ éteindre une carte réseau
$ ip link set dev toto up/down
# forcer le mtu d'une carte
$ ip link set dev toto mtu 1492
# forcer l'adresse mac d'une carte
$ ip link set dev toto address xx:xx
# renommer une carte réseau
$ ip link set dev toto name tata

ip addr :

# ajouter une ip (alias ip)
$ ip addr add 10.0.0.1/24 dev eth0
# supprimer toutes les ip
$ ip addr flush dev eth0

ip route :

# ajouter une route
$ ip route add default via 10.0.0.1 dev eth0
# Savoir par où passeraient des paquets à destination de google
$ ip route get 64.233.183.147
# changer le mtu et le ttl d'une route existante
$ ip route change default via 10.0.0.1 dev eth0 mtu 500 hoplimit 10

ip neigh:

# vider la table arp
$ ip neigh flush
# ajouter une entrée statique dans la table arp
$ ip neigh add 10.0.0.1 dev eth0 lladdr 00:11:22:33:44:55 nud permanent
# servir de proxy arp (pour bidouiller des faux bridges)
$ ip neigh proxy 10.0.0.2 dev eth0
$ echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

ip tunnel:

# créer une moitié de tunnel gre (attention, cela ne fait que créer une interface virtuelle, à vous de la configurer)
$ ip tunnel add monTunnel mode gre remote 10.0.1.1 local 10.0.1.2 ttl 255