Apperçu

Le but de cette formation c'est de s'assurer que les participant.e.s peuvent manipuler les commandes de base par rapport à la configuration du routage d'un serveur linux, et de solidifier quelques concepts de base qui permettent de mieux comprendre ce que les configurations signifient.

Formations préalables

Il n'est pas nécessaire d'avoir suivi d'autres formations pour suivre celle-ci. On présume simplement que les participant.e.s sont à l'aise à utiliser la ligne de commande.

Temps estimé

Selon les connaissances préalables des participant.e.s: de 1h à 2h

Objectifs

On vise dans cette formation à discuter seulement du routage "simple" où on configure des routes manuellement sur une machine linux. En effet, on veut comprendre durant cette session les fondements de l'idée de routage.

  1. Comprendre comment les réseaux sont structurés et subdivisés sur Internet et comment on calcule le "numéro du réseau" et les adresses dans ce réseau
  2. Comprendre comment un réseau peut parler à un autre (à l'aide de routes!)
  3. utiliser les commandes qui permettent la configuration de base et la visualisation du routage
    • ip addr

    • ip route

    • traceroute / mtr

  4. utiliser des outils pour tester et visualiser le trafic réseau
    • ping - vérifier qu'un host est rejoignable

    • bmon - voir le débit réseau en terme de nombres de paquets par seconde et de qté de données par seconde

    • iftop - autre outil pour voir le débit réseau. la présentation montre des barres de trafic par combinaison d'IP et port destination

    • tcpdump - outil qui permet de voir une trace de tous les paquets réseau qui passent par une interface réseau

Préparation pour les participant.e.s

Demander à tous.tes les participant.e.s de faire une préparation des outils nécessaires avant la formation: ça accélère la formation puisqu'on peut commencer les exercices directement.

Notez qu'on peut reproduire le setup d'exercices ailleurs dans l'absence des outils si quelques personnes n'ont pas accès au "control-repository" puppet de Koumbit, mais il faudra à ce moment là préparer une façon de reproduire la topologie de réseaux:

laboratoire réseau pour les exercices

  • rtr0 est une VM interposée entre deux réseaux différents

  • rtr_client et rtr_upstream0 sont chacune une machine connectée à un des deux sous-réseau (différent pour chaque).

  • les adresses IP des VMs sont pré-configurées
  • aucune configuration de routage n'est faite: donc au début des exercices on s'attend à ce que rtr_client ne soit pas capable de rejoindre rtr_upstream0 et de même dans le sens inverse.

Outils nécessaires pour rouler les exercices de la formation: dans le control-repository puppet, on vise utiliser les VMs (rtr_client, rtr0, et rtr_upstream0) déjà décrites dans le fichier Vagrantfile qu'on démarera à l'aide de vagrant et libvirt avec KVM comme outil de virtualisation (commandes plus bas). Voir Vagrant pour la mise en place du setup de machines virtuelles.

A faire pour se préparer aux exercices:

Important: les commandes de préparation plus haut doivent être relancées si vous faites un shutdown des VMs ou encore si vous les détruisez. Donc 10 à 15 minutes avant la formation, assurez-vous de relancer les commandes plus haut si c'est nécessaire.

Si vos VMs restent "up" tout le long jusqu'au début de la formation, ce ne sera pas nécessaire de les relancer.

Faites la préparation un ou plusieurs jours avant la formation: ça vous assure que vous aurez trois VMs configurées correctement pour commencer les exercices et du temps pour débugger le setup si vagrant ou d'autre chose ne fonctionne pas bien.

En fait, rien ne vous empêche de commencer les exercices par vous-même avant la formation!

Si vous avez commencé les exercices avant la formation et que vous voulez revenir au point de départ pour suivre les exercices en même temps que tout le monde durant la formation, un truc c'est de faire vagrant shutdown des trois VMs, et relancer les commandes de préparation plus haut juste avant la formation.

  • NB: pendant les exercices sur les VMs vagrant du control repository puppet: on ne veut pas utiliser les hostnames des machines pour les tests: vagrant nous joue un tour, le snoro -- on veut utiliser les IPs directes qui correspondent aux interfaces de la topologie de test.

  • NB: quand vous utilisez tcpdump dans les VMs, pensez à toujours utiliser les paramètres -i ethX pour être sur la bonne interface réseau (déterminer le X selon l'output des commandes qu'on utilisera pendant les exercices)

  • NB: l'interface par défaut, eth0, sur les VMs c'est l'interface de "contrôle" de vagrant, ce qui n'est pas utile pour nos tests. On veut donc ignorer eth0.

  • NB: durant les exercices, vous pouvez utiliser tmux sur les VMs pour pouvoir avoir tcpdump qui continue de rouler en permanence (p-e deux tcpdump sur deux interfaces réseau différentes!) et continuer de pouvoir lancer des commandes pour changer la configuration.

Théorie, concepts et information

On prend de 30 minutes à 1h pour parler des objectifs suivant et expliquer quelques concepts plus "théoriques":

TL;DR le routage c'est:

Le modèle OSI

Le modèle OSI est un modèle conceptuel utilisé pour représenter différentes couches d'opération dans "la stack réseau". Dans les deux images qui suivent, l'ordinateur envoyeur est à gauche et l'ordinateur destinataire est à droite.

OSI-Reference-Model.png

pour encore plus de détails sur le modèle OSI et les différents protocoles réseaux correspondant aux différents niveaux du modèle: https://www.osi-model.com/session-layer/

Pour transmettre des donneés sur le réseau, on doit traverser les niveaux en descendant vers les niveaux plus bas (donc de plus en plus proche du monde physique). A la réception, on doit faire le chemin inverse:

  1. L'application, au niveau 7, créé un paquet de données
  2. Le paquet est envoyé au niveau 6, ce niveau ajoute un peu d'information autour du paquet (l'encapsule)
  3. Le paquet est passé au niveau 5 et un peu plus d'information est ajoutée (le paquet se fait encapsuler encore plus)
  4. Le même processus continue comme ça jusqu'au niveau 1 où les données sont encodées de la bonne façon pour passer à travers le médium présentement branché sur l'ordinateur (e.g. impulsions électriques sur un fil ethernet, impulsions de lumières sur une fibre optique, etc)
  5. Les données sont alors transmises sur le médium réseau (le fil mauve-rose en dessous)
  6. Le paquet arrive alors à l'ordinateur destinataire au niveau 1 et les données sont décodées selon le médium connecté
  7. Le paquet est transmis au niveau 2 où les informations qui y avaient été ajoutées (entre autres l'adresse MAC) pourront être utilisées pour déterminer si la machine est réellement la destinataire à l'intérieur du réseau local
  8. Si la machine décide que le paquet lui est bien destiné, le paquet est envoyé au niveau 3 où l'information ajoutée à ce niveau (entre autres l'adresse IP) permettrat de déterminer si c'est un paquet traversant des réseaux qui est bel et bien à destination de la machine destinataire
  9. Le paquet est ensuite acheminé au niveau 4 où les informations sont reconsituées et mises en ordre
  10. Le processus continue ainsi jusqu'au niveau 7 où l'application destinataire reçoit les informations qui avaient été envoyée par l'application envoyeure.

OSI-Layer-Traversal.png

Le routage s'intéresse surtout au niveau 3 (et le niveau 4 va souvent main dans la main avec le concept)!

Adressage IP: les segments de réseaux, sous-réseaux et netmask/préfixe CIDR

Un sous-réseau c'est simplement une façon "mathématique" de diviser la plage des adresses internet (IP) en blocs plus petits qu'on peut ensuite attribuer à différents organismes/compagnies/bâtisses/racks/autres qui ont besoin d'une présence sur Internet.

https://xkcd.com/195/

Pourquoi on peut/veut prendre certaines décisions de segmenter des réseaux? (même si p-e on considère dans certains cas que ça reste "nos adresses")

Quelques exemples:

  • isoler certaines machines de certaines autres
  • avoir un segment de réseau qui permet le lien vers d'autres réseaux (e.g. nos fournisseurs d'accès à Internet au centre de données nous attribuent un petit sous-réseau qui contient seulement deux adresses IP et qui permet à notre routeur de parler à leur routeur sans communiquer avec l'équipement des autres clients)
  • réduire la taille du "réseau local" pour éviter qu'il n'y ait trop de bruit sur le réseau (ce qui réduirait possiblement la capacité maximale de bande passante et qui pourrait également potentiellement créer des fuites d'informations sensibles!)
  • louer une partie de nos adresses à un client -- c'est exactement le rôle des RIR, mais d'autres le font aussi à leur tour comme par exemple eStruXture pour rendre une plage d'adresses IPs disponibles à un client de leur centre de données.

Koumbit a également subdivisé son bloc d'adresses IPs en plus petits sous-réseaux pour appliquer plusieurs des exemples plus haut. Notre documentation pour cette subdivision est dans la page AllocationIp.

Chaque subdivision possible utilise un bit de subdivision "à gauche" du nombre représentant l'adresse IP: on divise donc les adresses en deux à chaque sub-division.

Ce qui représente la subdivision des adresses IP s'appelle le netmask (masque de sous-réseau).

ccna-analyzing-subnet-masks.jpg

Le netmask est utilisé dans une opération ET bit-par-bit avec l'adresse IP (e.g. netmask AND adresse IP) pour calculer c'est quoi la partie "sous-réseau" d'une adresse.

Un netmask est toujours représenté par un nombre de bits à 1 consécutifs à partir de "la gauche" (donc en terme de nombre binaire, "les valeurs les plus grandes" qui sont à un). Les bits à droite de ce nombre sont toujours à 0. Vu qu'on fait une opération ET binaire entre le netmask et l'adresse IP, le netmask sert donc à déterminer quels bits de l'adresse IP sont conservés pour connaître le numéro du réseau.

subnetting.png

Comme un netmask représente en fait simplement un nombre avec un certain nombre de bits à gauche à 1, une notation plus courte a été développée: la notation de préfixe CIDR. Avec la notation de préfixe CIDR, on note une adresse, un "/", puis le nombre de "bits à gauche" contenus dans le netmask.

ipcalc peut aider à mieux comprendre et à calculer plus rapidement quand on a besoin de le faire. Malheureusement l'outil ne calcule pas les sous-réseaux IPv6.

  • lancer ipcalc 199.58.83.129/26 et inspecter les informations que ça donne à l'écran. la ligne "wildcard" n'est pas super intéressante pour la formation.

  • c'est également possible de spécifier à la commande le netmask avec la notation netmask et non CIDR pour obtenir la même information (ça vous montrera également combien de bits de netmask ça contient pour pouvoir facilement transformer un netmask en notation CIDR.
    • par exemple: ipcalc 199.58.83.129/255.255.255.192

Exercices

Le restant du temps de formation sera passé à expérimenter avec les commandes dans les trois VMs pour bien ancrer les concepts.

Rejoindre un réseau local

Sur rtr_client, lister les routes connues par le kernel:

ip r

On a déjà une route! (ici on ignore par exprès celle sur eth0). C'est une route statique pour un réseau local qui a été ajoutée automatiquement quand l'adresse IP de l'interface a été configurée.

En effet, quand on configure une adresse IP sur une interface réseau on spécifie toujours l'adresse et son netmask. Donc on peut présumer qu'il est possible de rejoindre d'autres adresses IP dans le même sous-réseau si on communique via l'interface réseau à laquelle on vient de configurer l'adresse IP.

Sur rtr_upstream0:

# remplacer ethX par le bon nom d'interface réseau:
tcpdump -i ethX host $ip_upstream0

Sur rtr0:

Sur rtr_client:

Sur rtr0:

Rejoindre un réseau distant via une route par défaut

Sur rtr_client:

Comme rtr_client n'a qu'une seule route qui est statique pour un réseau local, rtr_client ne sait pas comment rejoindre le sous-réseau dans lequel l'adresse IP de rtr_upstream0 se trouve (rappelez-vous le premier message d'erreur dans le tout premier traceroute: Network unreachable -- c'est ce que ça indique: il n'y a aucune route qui peut s'appliquer et donc le réseau n'est pas connu/rejoignable).

La route par défaut va indiquer à rtr_client que rtr0, son gateway, lui sait comment retransmettre l'information au bon sous-réseau. L'adresse gateway assignée au routeur est indiquée dans la commande ip avec les paramètres via $IP et celle-ci doit être dans le même sous-réseau que rtr_client.

Sur rtr0:

Sur rtr_upstream0:

Sur rtr0:

Sur rtr0:

Avec la commande sysctl plus haut, la configuration disparaîtra lors d'un reboot. Pour que le IP forwarding soit permanent, on doit ajouter la même option de configuration dans le fichier /etc/sysctl.conf

Si vous voulez jouer à détruire la configuration plus tard pour constater les dégats et débugger à l'aide de tcpdump, mtr et autres commandes, vous pouvez retirer la configuration de IP forwarding avec la commande: sudo sysctl -w net.ipv4.ip_forward=0

Voir note en encadré après les exercices par rapport au IP forwarding pour plus d'information et un exercice complémentaire qu'on peut faire après les exercices de la formation.

Rejoindre un réseau distant sans route par défaut

Sur rtr_upstream0:

A noter: le paramètre `via $IP` a la même fonction que pour la route par défaut: faire passer le trafic réseau par un routeur à l'adresse IP spécifiée. Dans notre cas ici, on doit passer par `rtr0` avant de pouvoir rejoindre le sous-réseau dans lequel `rtr_client` se trouve.

La différence entre une route par défaut et une route comme celle qu'on vient d'ajouter c'est simplement que le (ou les) réseau(x) à rejoindre est beaucoup plus spécifique et restreint: on défini la route dans l'exemple ici seulement pour un sous-réseau alors que la route par défaut défini une route pour tous les sous-réseaux

NB: on aurait pu encore utiliser une route par défaut dans ce cas-ci, mais l'exercice était différent pour permettre de configurer une route d'un type différent.

Les routes par défaut son généralement seulement utilisées sur les "machines finales" (les feuilles de l'arbre du réseau?). Ici, rtr_upstream0 est supposé être conceptuellement le routeur d'un fournisseur d'accès réseau à Internet et donc ce routeur là en pratique n'utiliserait pas une route par défaut (e.g.: tenter de rejoindre "tout ce qui n'a pas de route définie" en envoyant le trafic réseau vers rtr0 n'aurait pas vraiment de sens puisqu'Internet est dans l'autre sens!)

Sur rtr_client:

Visualiser les transferts et des flux de paquets pour différents protocoles

Maintenant qu'on a du routage complètement fonctionnel, on peut trouver de l'information un peu plus détaillée sur les transferts d'information par le réseau.

Faire un test de bandwidth entre rtr_client et rtr_upstream0:

Etablir des connexions de différents protocoles à partir de rtr_client vers rtr_upstream0:

NB: la configuration de "IP Forwarding" n'est utile que dans les cas où on veut retransmettre vers un réseau qui est "local" à la machine qui fait le "forwarding".

  • Dans notre exemple, rtr0 touche aux/a une présence dans les deux réseau locaux qui communiquent avec rtr_client et rtr_upstream0 directement

    • mais l'option ne serait pas utile si on voulait rejoindre qqch qui serait dans un réseau "plus loin" que rtr_upstream0

    • si on conceptualise rtr_upstream0 comme étant EstruXture, on ne pourrait pas utiliser du IP forwarding sur rtr0 pour passer par EstruXture et ensuite rejoindre une machine plus loin sur Internet

    • donc l'exemple donné dans les exercice ne correspond pas à une configuration réelle dans notre centre de données. C'était simplement un exemple pour vous permettre de voir toutes les façons possibles de faire traverser les paquets réseau vers d'autres sous-réseaux.

L'IP forwarding est un raccourci qui permet le pont entre deux (ou plus) réseaux qui sont tous rattachés à un même routeur sans avoir besoin de définir une route pour chaque cas possible (dans les deux directions).

  • ça pourrait donc par exemple être utile sur les routeurs de Koumbit pour simplifier la gestion du pont entre les différents VLANs (donc la communication entre sous-réseaux de Koumbit mais à l'intérieur de notre réseau).
    • Voir dans la section "Informations complémentaires" pour plus d'information sur ce que c'est qu'un VLAN et à quoi ça sert.

Exercice complémentaire:

Sur rtr_client:

  • lancer un ping vers l'adresse IP de rtr_upstream0 qui n'est connectée à rien (conceptuellement, c'est un client sur internet derrière l'upstream0) et constater que les paquets ne sortent pas de rtr0

    • comme décrit plus haut, rtr0 ne sait pas où envoyer ces paquets avec seulement l'IP forwarding parce que ce n'est pas un "réseau local" pour rtr0.

  • on devra donc ajouter une route statique qui n'est pas locale sur rtr0 pour que les paquets puisssent se rendre à destination. Cet exercice est laissé aux lectrices.eurs -- voir l'exemple de route ajoutée à rtr_upstream0 pour une inspiration.

Rétrospective

Pendant un maximum de 15 minutes, les participant.e.s sont invité.e.s à partager les éléments qui ont bien ou moins bien fonctionnés et les idées qui pourraient survenir pour des manières d'améliorer le processus.

Quelques éléments qui peuvent faire partie de la rétrospective, dépendant de la grosseur du projet ou de la formation:

  • Sommaire colletcif (e.g. résumé rapide en termes que tout le collectif peut comprendre)
    • Pas trop utile pour les projets vraiment simples ou les formations.

  • Chronologie des événements marquant pour le projet
    • Surtout utile pour les projet qui se sont étalés sur plusieurs jours ou plus ou bien quand beaucoup de choses se sont produites simultanément, ce qui a rendu la compréhension des influences de chanque événement complexe.

  • Les bons coups -- qu'est-ce qui a bien fonctionné et qu'on veut tenter de reproduire
  • Les problèmes
    • échecs -- avec l'aide de la chronologie (si elle a été faite), tenter de situer les échecs dans un contexte selon ce qui était connu des participant.e.s aux moments qui ont mené à l'échec
    • problèmes techniques
    • manques de ressources
    • perturbations externes
  • Une liste d'actions à court et/ou à plus long terme pour améliorer les choses telles que soulignées pendant les points précédent
    • Transférer les actions dans redmine pour qu'elles puissent être suivies!

N'hésitez pas à partager les échecs à l'extérieur de l'équipe puisqu'on peut apprendre bcoup de ceux-ci, mais surtout évitez de les formuler comme un blame sur la/les personne(s) ayant échoué.

Une rétrospective est surtout utile quand on la partage: ça permet aux autres d'apprendre de nos erreurs et aussi de nos idées d'améliorations. On peut par exemple envoyer une forme écrite par email, ou bien savegardée comme page wiki.

Information complémentaire

Si c'est désiré après la formation et/ou si on a le temps à la fin de la formation, voici un peu plus d'information ou noms de programmes à investiguer pour approfondir votre connaissance (à noter: on a utilisé certains des outils dans les exercices, mais chacun a beaucoup plus de fonctionnalités qui rendent les commandes utiles à bien plus de choses)

configuration "permanente" des interfaces réseau dans debian

La configuration permanente pour le réseau dans debian se trouve dans: /etc/network/interfaces.

outils de tests de réseau

On a tendance à utiliser mtr dans l'équipe comme remplacement de traceroute vu que ça donne des résultats mis à jour à chaque seconde. Cependant c'est important de se rappeler que mtr formule ses paquets un peut différemment et par conséquent donne des résultats un peu fautifs de temps en temps et peut nous induire en erreur par rapport à du supposé "packet loss".

Un exemple de cas où ça nous est arrivé avec l'output différent des deux commandes peut être consulté ici: https://rt.koumbit.net/rt/Ticket/Display.html?id=1312638#txn-10181099

Donc pour cette raison là, c'est toujours mieux de se fier à traceroute comme source finale d'information.

Protocoles réseau additionnels


CategoryFormation

FormationRoutageLinux (last edited 2020-12-16 02:27:27 by gabriel)