Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Category: Réseau

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é : tcpdump, wireshark

Il y a quelque temps, un ami me dit qu'il a trouvé comment se faire embaucher en passant ses nuits devant des trames réseau.

Tout comme lire des logs sans filtre, lire les dump réseau est une activité qui bousille le cerveau. Je me suis donc dit qu'il était complètement barré.

Puis il y a quelques jours, il m'envoie le dump d'un accès à un site web, je vous le livre légèrement filtré. Devinez ce qu'on trouve dans l'en-tête HTTP de la réponse ...

GET /index.html HTTP/1.1
Host: xxx.wordpress.com

HTTP/1.0 200 OK
Server: nginx
Date: Sat, 13 Nov 2010 12:30:04 GMT
Content-Type: text/html; charset=UTF-8
X-hacker: If you're reading this, you should visit xxx.com/jobs and apply to join the fun, mention this header.

Du boulot !

Je ne vous ai pas mâché le travail et vous ne retrouverez pas le site si facilement.

Vous aussi, passez vos nuit à lire des trames, ou mieux, mettez la même chose sur votre site, pour être sûr d'embaucher quelqu'un un minimum compétent le jour où vous tomberez dessus.

Pour cela, si vous avez un apache allez dans sa conf et ajoutez :

header set X-Hadopi Enfoiré de pirate je vais te couper ta connexion - Un ministre anonyme

Je vous laisse chercher pour les autres serveurs qu'apache.

Pour continuer dans le même ordre d'idée, on peut gagner des netbook en regardant attentivement des vidéos de google.

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...

Niveau :      
Résumé : iptables -m hashlimit

Aujourd'hui un ami me dit "hey j'ai un truc pour toi" et il me file sa configuration iptables pour limiter les barbares qui viennent lui détruire son serveur et sa connectivité à coup de robots farceurs.

De coup je me suis penché sur son script et je vous le livre avec son accord (toujours accorder un complément d'objet webesque comme dirait la métraisse).

Le script

Il est court mais bref :

IPT=/sbin/iptables
WEBMAXPERMIN="260"
WEBBURST="40"

$IPT -N throttle

# hashlimit-htable-expire en millisecondes 
$IPT -A throttle -m hashlimit \
 --hashlimit-name webthrottle \
 --hashlimit-upto $WEBMAXPERMIN/minute \
 --hashlimit-mode srcip \
 --hashlimit-burst $WEBBURST \
 --hashlimit-htable-expire 300000 \
-j ACCEPT
$IPT -A throttle -j LOG --log-prefix "FREIN " --log-level 1
$IPT -A throttle -j REJECT

#puis dans  le INPUT
$IPT -A INPUT -d $ETH00 -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -j throttle


continue reading...

Niveau :      
Résumé : slirp

Si vous n'êtes pas admin de la machine sur laquelle vous êtes (université ?), mais que vous voudriez partager votre connexion, par exemple pour une machine virtuelle ou pour des amis qui voudraient emprunter votre IP ... Il vous faut du NAT (a moins que vous vous contentiez d'un simple tunnel).

Problème : vous ne pouvez pas le mettre en place puisque vous n'êtes pas admin sur la machine qui partage la connexion.
Solution : slirp.

Hé oui c'est tout simple, slirp décapsule du PPP pour l'injecter dans une socket normale et donc fait l'équivalent du NAT. Mais avec quelques limitations, on ne peut pas faire passer n'importe quel paquet (genre ping) depuis l'espace utilisateur, malgré tout c'est largement suffisant.

Le serveur de NAT (enfin le routeur quoi)

Bon c'est pas si simple mais presque.

Slirp est une commande qui utilise le l'entrée et sortie standard pour communiquer ce qui fait que si on veut l'utiliser à distance il faut le connecter à un "listener", ici nous allons utiliser socat, mais si vous voulez un tunnel chiffré, utilisez stunnel.

Donc vous avez besoin de socat et slirp sur la machine où vous êtes simple utilisateur. Si vous ne les avez pas recompilez les vous avez le droit. Si vous n'avez pas de compilateur copiez-lez depuis une autre machine, si cela ne fonctionne pas, recompilez les chez-vous en statique ... enfin vous êtes grands que diable, ne me posez pas cette question !

Il vous faut un fichier de configuration minimaliste pour slirp (à mettre dans ~/.sliprc) :

ppp
asyncmap 0

Puis lancez le service genre sur le port 2000 (fullbolt = pas de limitation de vitesse) :

$ socat -s tcp4-listen:2000,fork system:/usr/bin/slirp-fullbolt



continue reading...

Niveau :      
Résumé : TCP + RTT + window size = debit

Si je me connecte au réseau local gigabit, que je fais un transfert de fichier ... je n'arrive pas à dépasser 200Mb/s ! Vous rendez-vous compte que c'est normal ?

Vous allez me dire que je ne suis pas doué, mais ce n'est pas moi, ce sont les lois de la physique.

Bon puisque nous somme dans un cas particulier je m'explique.

Temps de réponse

Le débit a beau toujours augmenter, il y a quelque chose qui s'améliore beaucoup moins vite : le temps de réponse. Pour une bonne raison, l'information a une vitesse limite, celle de la lumière. La limite est un peu inférieure sur une fibre optique et encore inférieure sur un câble cuivre.

De plus il faut une certaine électronique pour traiter tous ces paquets et ce débit. Du coup la traversée de switchs et de firewall en fout un coup à la latence. Et pourtant le débit ne change quasiment pas.

Tout ceci se voit avec la commande ping. Si vous lancez un ping sur la machine d'à coté, vous constatez un temps de réponse de l'ordre de la milliseconde.

Par exemple :

PING mamachine (10.0.0.0.1) 56(84) bytes of data.
64 bytes from mamachine (10.0.0.0.1): icmp_seq=1 ttl=61 time=1.16 ms

C'est le temps qu'il a fallu pour créer le paquet ping, l'envoyer à travers le switch, le réceptionner, répondre, repasser dans le switch, lire la réponse. Donc il faut la diviser par deux pour avoir un ordre de grandeur du temps de transfert du paquet.

Pour une machine sur un autre réseau c'est plus dans les 20ms voire 100ms.

Dans cette histoire les plus gros temps de latence dépendent de votre infrastructure, si vous êtes sur une fibre de 100km c'est elle qui contribuera à la latence, si vous êtes sur un réseau local c'est plus le temps de traitement par la carte réseau et le noyau, et s'il y a plusieurs switchs ou un routeurs c'est l'électronique des ces appareils.


continue reading...