Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Réseau

Niveau :      
Résumé : ip link add link eth0 vlan1 type vlan id 1

Je suis de retour !

Désolé pour le lag ... mais je réponds aux commentaires.

Problème

Aujourd'hui, un problème qu'on m'a posé récemment. Comment faire lorsqu'on a un parc de box (routeur wifi, machine embarquée, ...) et qu'on veut pouvoir à tout moment se connecter physiquement sur son port ethernet et la configurer en utilisant ip (par ssh, snmp ...).

La première solution est d'avoir une configuration réseau immuable sur ces machines ET de répertorier d'une façon ou d'une autre un identifiant unique pour chacune de ces machines qu'on peut alors faire correspondre à une ip. C'est assez contraignant et ça impacte fortement la configuration réseau des machines. Ça risque de nous empêcher de réutiliser ce port pour communiquer dans un réseau existant le reste du temps.

La deuxième solution serait d'utiliser un protocole type zeroconf pour configurer automatiquement le réseau lorsqu'on se branche, l'inconvénient est de réussir à le désactiver lorsque la machine se retrouve dans son réseau de destination qui n'utilise pas nécessairement zeroconf tout en le gardant actif pour le configurateur.

Je vous propose donc une solution différente : l'ip unique. Toutes les machines à configurer ont la même IP. C'est bien beau me direz-vous, mais comment fait-on pour éviter les conflits sur le réseau de destination ? Et comment fait-on pour que ces machines communiquent ensemble ?

C'est tout simple, on met cette IP sur un vlan prédéfini. Ainsi vous n'avez plus aucune contrainte sur la configuration réseau de l'appareil. Ce peut être une box en bridge ou en routeur, une machine physique avec un routage complexe, ou une machine configurée en dhcp.

Solution pour linux

Pour ajouter une interface réseau virtuelle associée à un vlan :

# le vlan 1 sur l'interface eth0 sera dans l'interface virtuelle vlan1 
$ ip link add link eth0 vlan1 type vlan id 1 

# ou, pour ceux qui n'aiment pas le couteau suisse, ip, il y a l'outil d'origine
$ vconfig add eth0 1 # pas le choix, l'interface s'appellera nécessairement eth0.1

Et il suffit de lui configurer une ip choisie en dur et c'est fini, vous pouvez mettre n'importe quelle configuration pour eth0 ...

$ ip addr add 192.168.254.254/28 dev eth0.1

Pour faire ceci en statique, sur une debian like il faut modifier /etc/network/interfaces en nommant l'interface à configurer eth0.1 Pour les redhat like il faut créer le fichier /etc/sysconfig/network-script/ifcfg-eth0.1

Niveau :      
Résumé : ngrep

I'm back ! Ça faisait longtemps ! Vous m'avez manqué.

J'ai quelques petits articles pour vous. Oui c'est vraiment la reprise, même si c'est pas encore du triple A.

Aujourd'hui ngrep. Ngrep est un pote de tcpdump, il sait utiliser les mêmes filtres que tcpdump et stocker les paquets dans un format pcap lisible par wireshark si besoin. Mais son intérêt principal est qu'il sait matcher le contenu des paquets.

Là où en tcpdump vous feriez :

$ tcpdump host 10.0.0.1 and port 80

Vous pouvez utiliser ngrep récupérer un paquet particulier :

$ ngrep 'GET' 'host 10.0.0.1 and port 80'

Dans les options les plus utiles on trouve :

  • -O pour sauvegarder les paquets et les analyser ensuite, par exemple avec wireshark
  • -x pour dumper la version hexadécimale du paquet (pratique pour un protocole binaire)
  • -X pour matcher sur la version hexadécimale du paquet (pratique pour un protocole binaire)
  • -K1 pour tuer la connexion en envoyant un paquet RST à la source du paquet en question (pas de garantie 100% avec cette méthode :)

Et un exemple pour la route pour couper la connexion de celui qui dirait du mal de vous sur un serveur irc :

$ ngrep -K1 'peck sux' 'dst 10.0.0.1 and dst port 6667'

Niveau :      
Résumé : tcpdump, wireshark

Espionnage

Tout le monde le sait, les téléphones nous espionnent. Mais que communiquent-ils ? A qui communiquent-ils ? Que peut-on y faire ?

Aujourd'hui nous somme armés d'une vraie distribution GNU. Nous pouvons donc utiliser des vrais outils.

# on se connecte sur le téléphone
$ ./adb shell
# mettez votre debian dans ce $ROOT
$ chroot $ROOT
$ apt-get install tcpdump
$ nohup tcpdump -i any -s 0 -w /tmp/dump.`date +"%Y-%d-%m"` &

maintenant déconnectez-vous et laissez tourner toute la journée dans son coin après avoir vérifié qu'il reste de la place sur le disque.

Quelque temps plus tard; :

# sur le téléphone
$ chroot debian
$ pkill tcpdump
# sur le pc
$ ./adb get $ROOT/tmp/dump.*

Analyse

Maintenant revenons à notre poste et regardons ce qui s'est passé. Pour cela on utilise wireshark.

On ouvre le fichier dump et c'est parti :

  • on trie par protocole -> LARQ, DNS, ipv6, http, https, ...
  • on trie par adresse -> on a la liste de qui communique avec notre machine
  • on liste des requêtes dns -> on a les noms des précédents

Ce que j'ai découvert pour l'instant

LARQ (limited automatic repeat request) : protocole utilisé pour la retransmission rapide de frame en cas de perte sur la couche de liaison. Très pratique pour améliorer la qualité des transmissions. On ne trouve quasiment pas d'infos sur le net à ce sujet, à part un brevet.

IPv6 : il est activé par défaut chez moi, ouf

DNS : il semble qu'android utilise le resolver public de google (pratique pour ne pas être embêté par les limitations de l'opérateur et les problèmes de configuration).

Cloonix

Jan 18

Niveau :      
Résumé : ./start_cloonix_net ; ./graph

De temps en temps je vous fais un article sur le réseau, et je teste quasiment tous mes articles dans la vraie vie. Et là vous vous dites, mais c'est énorme ! Mais comment que fait-il ? A-t-il l'infrastructure ?

En fait non, enfin si mais non. Pour tester le réseau, j'utilise tout simplement cloonix.

Cloonix n'est pas une distribution, mais un outil permettant de gérer des machines virtuelles et de les mettre en réseau. Pratique, tout se fait graphiquement ou presque.

Installation

La version ubuntu ne marche pas sur ma debian, j'ai donc du utiliser les sources. Ça compile bien, il suffit d'appeler doitall dans le répertoire sources. Par contre faites attention, la version source ne contient pas de vm de démo.

Donc après compilation récupérez le répertoire virtual_platform_configs ainsi que le répertoire bulk du package ubuntu et déposez-les dans le répertoire de cloonix.

Le répertoire bulk contient les images disque de base des distribution à virtualiser.

Le répertoire virtual_platform_configs contient la définition des vm, les personnalisation spécifiques à chaque machine, ainsi que la façon dont les machines sont reliées.

Utilisation

./start_cloonix_net
./graph

Vous pouvez alors cliquer sur le bouton droit et charger une topologie. C'est à dire une infrastructure telle que stockée dans un des répertoires de virtual_platform_configs. Un fois que toutes les vm sont chargées vous obtenez ceci : Cloonix_IHM

Et c'est parti, vous avez plusieurs machines virtuelles préconfigurées directement utilisables. Pour ouvrir un shell sur une des machine, double cliquez dessus. Vous pouvez aussi en ajouter dynamiquement, relier deux cartes réseau ...

Lorsque vous avez fini tuez cloonix et ses vm :

./ctrl -kill

Détails

Très pratique, quasiment rien à faire, cloonix sait utiliser UML ou KVM au besoin.

Pour les tests réseau vous pouvez faire ce que vous voulez, pensez à enregistre votre topologie pour les tests fréquents.

Pensez aussi à modifier la distribution de base dans bulk pour ne plus avoir de modifications a porteriori à faire car tout le contenu d'une vm est perdu dès qu'elle s'éteint.

Enfin pour ceux qui font des tests avec les couches basses du réseau, il est nécessaire d'autoriser le passage des interface en mode promiscuous depuis cloonix avec une commande de la forme :

# le nom de la vm, ne nom de l'interface, 1 pour activer
./ctrl -promisc ROUTER3 eth0 1

La documentation est minimaliste, mais suffit pour s'en sortir.

PS : Si vous avez des idées d'article à me suggérer n'hésitez pas à utiliser la boite à idées.

Niveau :      
Résumé : modprobe bonding ; ifenslave

Récemment nous avons vu l'agrégation sur couche 3, celle d'IP. Naturelle, pratique pour redonder des chemins réseaux, elle n'est pas forcément adaptée pour de la redondance sur réseau local.

Il existe une autre solution qui fonctionne sur la couche du dessous, le bonding (aussi appelé trunking chez les fabriquants de switch, ou etherchannel qui est la cas particulier du mode 802.3ad). Il permet de communiquer à travers 2 chemins physiques différents avec une machine présente sur le même réseau local.

Le principe est très simple, au lieu de mettre un câble réseau on en met 2. Au lieu de mettre une carte, on en met 2

Matériel

Il vous faut :

  • 2 cartes réseau
  • 2 câbles
  • un switch
    • ou 2
    • ou le même matériel sur la machine en face (connexion directe sans switch)

Selon le mode de bonding choisi, il se peut que vous ayez besoin d'un support particulier sur le switch et sur les driver des cartes.

Méthode

C'est simple, on crée un nouvelle interface virtuelle, comme on ferait avec un bridge et on lui affecte 2 cartes physiques.

# bizarrement le bonding se configure au modprobe ... on a vu mieux
# mode actif-passif et détection auto du débranchement du câble en 100ms
$ modprobe bonding mode=1 miimon=100

# Ajout des interfaces au bond
$ ip link set bond0 up
$ ifenslave bond0 eth0
$ ifenslave bond0 eth1

# Configuration comme une carte normale :
$ ip addr add 10.0.0.1/24 dev bond0

Reste plus qu'a faire pareil si besoin de l'autre côté et c'est bon on peut maintenant débrancher un câble sans être coupé du réseau (enfin pas plus de 100ms).

Pour rendre la chose permanente, il faut ajouter le chargement de module avec ses options dans /etc/modules et mettre les lignes ifenslave en post-up dans /etc/network/interfaces.

Bridge, machinbox

Pourquoi ne fait-on pas un bridge, c'est beau un bridge ?
Il faut savoir qu'un bridge n'a pas le même usage que le bonding. Le bridge est là pour relier 2 réseaux différents. Nous voulons seulement relier 2 cartes sur le même réseau. Évitez d'ajouter un bridge là où ce n'est pas nécessaire, ça vous évitera les problèmes de boucle et de spanning tree.

Et si on a un bridge en face ?
Remarquez que c'est le cas de la plupart des machinbox et autres routeurs wifi. Ils installent un bridge entre les ports wifi et les ports ethernet ce qui leur permet de ne pas avoir à router les paquets. Dans ce cas vous êtes sur le même réseau des 2 côtés, comme sur un switch. Vous pouvez alors mettre du bonding sur votre machine.

# cette fois on détecte la coupure avec des envois de paquet arp
# l'adresse ip est celle de votre passerelle juste en face
$ modprobe bonding mode=1 arp_interval=100 arp_ip_target=192.168.0.1 primary=eth0

$ ip link set bond0 up
$ ifenslave bond0 eth0
$ ifenslave bond0 wlan0

# configuration auto tant qu'à faire
$ dhclient bond0

Et voilà vous êtes toujours connectés, de façon automatique, même lors d'un basculement entre wifi et filaire.

Choix de configuration

Avant de mettre en place une solution de bonding, il faut savoir à quoi il va servir, car plusieurs modes sont disponibles, je ne vous ai parlé que du mode 1 ou active-backup.

Si vous avez 2 câbles, 2 cartes et un switch vous vous prémunissez d'une erreur de branchement (humaine) ou d'une carte qui grille (rare), mais aussi d'un port de switch qui grille.

Ajoutez un 2e switch et vous vous prémunissez en plus du cas du switch entier qui grille ou de sa prise qui se retrouve débranchée par erreur.

Il est aussi possible d'avoir pour but de doubler la bande passante de la machine. Dans ce cas choisissez de préférence un switch adapté (pour en profiter dans les 2 sens) et le mode 802.3ad.

Enfin un cas très intéressant est de pouvoir passer d'un mode de transport à un autre automatiquement en fonction des besoins : wifi <-> câble physique.

La liste des modes ainsi que la documentation complète se trouve sur le site de la linux fundation.

Niveau :      
Résumé : ip route add .. nexthop via ...

Aujourd'hui on fait des nœuds.

Comme deux exemples valent mieux qu'un, je vous propose d'étudier 2 cas :

  • la personne qui a 2 cartes réseau (wifi, pas wifi) pointant vers le même routeur
  • la personne qui un routeur (genre pour une résidence) pointant vers plusieurs FAI

Comment faire pour répartir les connexions entre les différentes sorties proposées sans tout casser ?

iproute 2

Heureusement tout est dans le noyal ! La table de routage sait faire ce genre de chose.

Contrairement à ce qu'on pourrait croire mettre 2 routes par défaut ne marche pas. Le noyau n'en choisirait qu'une et la garderait jusqu'à ce que quelqu'un intervienne.

Il est par contre possible d'avoir une route vers une destination pointant vers plusieurs intermédiaires en même temps. C'est ce que fait l'option nexthop de la commande ip route.

Deux cartes réseau

Prenons le cas de la personne qui a 2 interfaces vers le même routeur :

$ ip route add default nexthop  via 10.0.0.1 dev eth0 weight 100 nexthop via 10.0.0.1 dev wlan0 weight 1

On choisit un poids de 100 pour faire en sorte d'utiliser presque toujours la première route plutôt que la deuxième. Bien sûr si une des routes est indisponibles, seul l'autre sera utilisée. Mais le système de routage ne le sait que grâce à l'interface elle même, il faut donc que l'interface supporte miimon pour détecter le débranchement d'un câble ou que vous la désactiviez à la main.

Ce genre de problème serait probablement mieux résolu avec un bridge ou du bonding, mais ce le sujet d'un prochain article.

Deux FAI

Plus difficile, prenons le cas de la personne qui a 2 FAI :

$ ip route add default nexthop  via 10.0.0.1 dev eth0 weight 1 nexthop via 192.168.0.1 dev eth1 weight 1

Et n'oubliez pas que pour que ca marche vraiment, il faudra que vous ayez du NAT quelque part (pour ipv6 on en reparle lorsque ça existe).

Il faut savoir que la table de routage dispose d'un cache. L'avantage est qu'il n'y a pas spécialement besoin de bidouiller avec le source routing pour que ça marche, ça fonctionne tel quel. L'inconvénient est qu'il n'y aura qu'une seule route par destination. Le partage de charge ne sera donc pas nécessairement équilibré puisque si tout le monde va sur youtube, un seul FAI sera utilisé.

Pour équilibrer le transfert de paquet il y a l'option equalize, mais elle nécessite d'une part un patch du noyau et d'autre part de passer un certain temps à faire sa configuration réseau car il faut maintenant router à la main les paquets d'une même connexion vers le même FAI (sinon le destinataire est perdu). C'est une solution plus compliquée mais qui peut être utile si vous n'avez que peu d'utilisateur ou de destinataires.

Enfin le failover ne se fait automatiquement que dans un cas, si le réseau est désactivé sur une carte (laquelle doit suporter mii-tools) . Sinon vous devez le faire manuellement :

$ ip link set dev eth0 down

Et si vous voulez le faire automatiquement lorsqu'un FAI ne répond plus, c'est à vous de mettre un script qui va vérifier la connectivité et faire des modifications si besoin.

Niveau :      
Résumé : ip rule ; ip route

Le routage IP est communément défini en fonction de la destination. Remarquez c'est logique. La fonction d'un routeur est de faire en sorte que les paquets arrivent à bon port (héhé), la route à prendre ne devrait dépendre que de cette destination.

Mais comme pour les GPS, il peut parfois y avoir quelques options à prendre en compte, êtes vous un camion (passage de tunnels) ou un piéton (passage d'escaliers) ? Pour toutes les options de routage qui ne dépendent pas uniquement de la destination, linux utilise ce qu'il appelle "policy based routing" qui est une option qui doit être activée dans le noyau (c'est le cas pour la plupart des distributions).

Le concept est simple. Vous écrivez des règles pour matcher les paquets, lesquelles vont décider de la table de routage à choisir. La table en question étant une table de routage tout ce qu'il y a de plus standard telle que vous connaissez sous linux.

Les tables

Les tables se créent et se gèrent avec ip route (comme d'hab). Exemple :

$ ip route add default via 10.0.0.1 table 1
$ ip route add default via 10.0.0.2 table 2

Vous avez 255 tables à votre disposition, j'espère que vous saurez en profiter.

Vous pouvez donner un nom plutôt qu'un numéro à votre table. C'est tout simple, il suffit d'éditer le fichier /etc/iproute2/rt_tables. Et voila :

$ ip route del default table matable

Remarquez que les fichiers permettent de nommer de nombreuses choses qui sont représentées par des numéros pour la commande ip.


continue reading...