samedi 15 février 2014, 09:22:44 (UTC+0100)

Dessine moi une interconnexion réseau

Le développement d'exercices sous forme de défi devient une condition importante pour attirer de nouveaux étudiants vers un domaine particulier. Les enseignements sur les systèmes et les réseaux n'échappent pas à cette condition. J'ai donc modifié la progression des travaux pratiques pour les étudiants de 2nde année d'IUT Génie Électrique, et l'introduction d'une séance Dessine moi une interconnexion réseau a été un succès relativement au vécu des années précédentes.

En premier lieu, j'ai révisé le support de travaux pratiques Configuration d'une interface réseau Ethernet en éliminant l'utilisation des outils net-tools au profit de la commande ip du paquet iproute2.

Avec l'utilisation conjointe des protocoles IPv4 & IPv6, une même interface peut avoir de nombreuses adresses. Le recours systématique à la commande ip s'impose donc. J'ai rencontré plusieurs cas où les étudiants ont ajouté manuellement une adresse IPv4 à une interface préalablement configurée via DHCP. Dans un tel cas de figure, la commande ifconfig ne fait apparaître qu'une seule adresse au lieu de deux et induit les étudiants en erreur.

Ce support est de «facture classique» et le jeu de questions proposé correspond à un scénario de lecture simple. Même si ces questions peuvent être traitées avec l'émulateur de terminal Android®, il n'y a pas d'enjeu particulier. Le support ne sert alors que de base documentaire sur les différentes options de la commande ip.

En second lieu, j'ai créé le nouveau support Dessine moi une interconnexion réseau qui est bâti sur le «mode défi». Il s'agit de partir à la découverte d'une interconnexion de réseaux locaux inconnus. Les étudiants doivent identifier les réseaux communs entre les différents routeurs et aboutir à une représentation graphique des liens entre ces routeurs. Le point de départ du défi est une connexion SSH sur un routeur de cette interconnexion.

Pour faciliter le travail des étudiants, qui sont de véritables débutants, j'ai choisi d'utiliser des routes statiques de façon à ce qu'il soit possible de contacter n'importe quelle adresse d'interface depuis n'importe quel routeur. L'utilisation d'un préfixe agrégeant toutes les routes de l'interconnexion permet de diminuer le nombre des entrées dans la table de routage.

Cet exercice est une illustration de l'utilisation du guide Virtualisation système et enseignement : les routeurs sont des machines virtuelles Debian GNU/Linux et l'interconnexion est réalisée avec Open vSwitch. Le script de lancement de l'ensemble des instances est disponible sur GitHub. J'ai volontairement choisi de faire apparaître une interface distincte par lien réseau pour que l'identification des routes soit plus facile. Il aurait été plus simple du point de vue virtualisation de n'utiliser qu'une interface physique par routeur et autant de sous-interfaces que de VLAN utilisé.

Enfin, bien que le défi s'adresse avant tout à des débutants, il renferme quelques questions d'un niveau un tantinet plus élevé. Deux exemples :

  • D'après la table de routage ci-dessous, quelle est l'interface utilisée pour émettre un paquet à destination de l'adresse 172.19.129.21 ?

    Justifier le choix entre eth1 et eth3.

    $ ip route ls
    default via 192.0.2.1 dev eth0 
    172.19.128.0/22 via 172.19.131.169 dev eth3 
    172.19.129.0/26 dev eth1  proto kernel  scope link  src 172.19.129.12 
    172.19.131.0/25 dev eth2  proto kernel  scope link  src 172.19.131.13 
    172.19.131.128/25 dev eth3  proto kernel  scope link  src 172.19.131.142 
    192.0.2.0/26 dev eth0  proto kernel  scope link  src 192.0.2.11
    
  • Pourquoi est-il nécessaire d'appliquer la valeur 2 au paramètre de réglage de la fonction reverse path forwarding de certaines interfaces ?

    Extrait du fichier /etc/network/interfaces d'un routeur.

    auto eth2
    iface eth2 inet static
          address 172.19.131.13/25
          up echo 2 >/proc/sys/net/ipv4/conf/eth2/rp_filter
    

Alors !? Si vous êtes intéressé par ce défi, vous pouvez me contacter par courrier électronique à l'adresse donnée sur la page d'accueil du site inetdoc.

dimanche 26 janvier 2014, 15:08:31 (UTC+0100)

Virtualisation système et enseignement

Une nouvelle édition entièrement revue et corrigée du guide Virtualisation système et enseignement est disponible.

L'angle de construction du guide n'a pas changé. On propose d'accéder aux outils directement en ligne de commande sans passer par une bibliothèque ou une solution de virtualisation intégrée. L'objectif principal est d'identifier et de repérer les fonctions réseau usuelles telles que la commutation de trames et le routage de paquets. À un équipement physique dédié classique, on fait correspondre une fonction ou un outil logiciel de virtualisation. Même si le mot «virtualisation» apparaît sans cesse de nos jours, il n'y a rien de vraiment nouveau sous le soleil ! Les mêmes fonctions se sont simplement déplacées d'un environnement à l'autre. La nouveauté réside dans le fait que ces mêmes fonctions sont de plus en plus génériques et accessibles depuis une grande variété de systèmes. Nous devrions donc bientôt pouvoir parler d'une démocratisation des fonctions réseau.

système hôte et commutation virtuelle

Le nombre des scripts shell de lancement des machines virtuelles a été réduit à deux : un pour le mode utilisateur et un pour le raccordement à Open vSwitch.

L'utilisation des paquets associés à Open vSwitch entraîne une révision des supports de travaux pratiques dont les corrections utilisaient Virtual Distributed Ethernet jusqu'à présent. En bref, il reste beaucoup de travail en perspective !

mardi 21 mai 2013, 22:17:06 (UTC+0200)

NIS, NFSv4, autofs5 & dual stack IPv4 + IPv6

Pour employer une formule marketing à 2€cts, la collection des acronymes donnés dans le titre constitue un «savoureux mélange» entre anachronisme et modernité. Ceci-dit, je me doute bien qu'à la lecture du même titre, d'aucuns auront déjà trouvé que la mixture est on ne peut plus indigeste ! Enfin, n'ayant plus du peur du ridicule, voici une petite introduction sur ce faux-nouveau support : Association NIS, NFSv4 et autofs.

Après avoir adapté les supports de la rubrique développement à IPv6, je me suis posé la question de faire le même travail sur les autres supports de travaux pratiques. Écrire une version IPv6 séparée pour chaque séance de travaux pratiques obligerait à maintenir deux versions pour un même document. Au delà de la quantité de travail, il y a fort à parier qu'une version IPv6 isolée ne serait jamais utilisée vu ce que l'on sait de l'engouement général pour adopter rapidement ce protocole. Il restait donc l'option du document unique double pile ou dual stack dans le jargon. À titre d'entraînement, j'ai repris un vieux support abandonné qui associe trois services.

  • Network Information Service (NIS) permet le partage des paramètres de compte utilisateur. C'est un service démodé qui ne fonctionne qu'avec la pile IPv4 ; ce qui le rend intéressant dans le contexte présent.
  • Network File System (NFS) est le système de fichiers réseau de prédilection dans le monde Unix. Sa version 4 fonctionne très bien avec la pile IPv6.
  • Automounter (autofs) permet l'accès transparent au système de fichiers réseau. On l'utilise lors de la connexion d'un utilisateur pour accéder simplement à son répertoire. Normalement, ce service fonctionne avec IPv6. J'ai découvert avec surprise que son utilisation d'IPv6 est assez singulière puisqu'il semble s'appuyer exclusivement sur les enregistrements DNS.

Même si le but recherché était de «croiser» les usages des deux piles de protocole de couche réseau, le résultat a dépassé mes attentes puisqu'en trois services on dispose de trois modes opératoires distincts.

Pour être complet, il faut ajouter les appels de procédures distants (RPC) sur lesquels sont basés NIS et NFS. C'est justement ce mécanisme qui autorise le mixage entre les deux piles IPv4 et IPv6.

# rpcinfo -s ip6-srvr.fake.domain
   program version(s) netid(s)                         service     owner
    100000  2,3,4     local,udp,tcp,udp6,tcp6          portmapper  superuser
    100004  1,2       tcp,udp                          ypserv      superuser
    100009  1         udp                              yppasswdd   superuser
    100003  4,3,2     udp6,tcp6,udp,tcp                nfs         superuser
    100227  3,2       udp6,tcp6,udp,tcp                -           superuser
    100021  4,3,1     tcp6,udp6,tcp,udp                nlockmgr    superuser
 600100069  1         tcp,udp                          fypxfrd     superuser
    100007  1,2       tcp,udp                          ypbind      superuser
    100005  3,2,1     tcp6,udp6,tcp,udp                mountd      superuser

autofs troubleshooting

Comme je l'ai dit plus haut la version du paquet autofs fourni dans la branche testing semble se baser uniquement sur les enregistrements DNS. Voyons comment je suis parvenu à cette conclusion.

  1. On commence par un montage statique de l'arborescence depuis le poste client.
    # mount -t nfs4 [2001:db8:feb2:10::12]:/home /ahome
    root@clnt:/home/etu# ls -lAh /ahome/etu-nis/
    total 16K
    -rw------- 1 etu-nis etu-nis  385 mai   21  2013 .bash_history
    <snip/>
    
    # mount | grep nfs4
    [2001:db8:feb2:10::12]://home on /ahome type nfs4 \
      (rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp6, \
       timeo=600,retrans=2,sec=sys,clientaddr=2001:db8:feb2:10::11,minorversion=0, \
       local_lock=none,addr=2001:db8:feb2:10::12)
    
    Le montage statique utilisant les adresses IPv6 fonctionne. Rien d'original.
  2. On passe à l'utilisation du démon automount avec des fichiers de configuration complétés directement sur le poste client, toujours avec une adresse IPv6 numérique.
    # cat /etc/auto.master
    /ahome          /etc/auto.home
    
    # cat /etc/auto.home 
    * -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/&
    
    # service autofs start
    [ ok ] Starting automount....
    # automount -m
    
    autofs dump map information
    ===========================
    
    global options: none configured
    
    Mount point: /ahome
    
    source(s):
    
      instance type(s): file 
      map: /etc/auto.home
    
      * | -port=2049,-fstype=nfs4 [2001:db8:feb2:10::12]:/home/&
    
    La configuration a bien été prise en compte par le démon ...
    # ls -lAh /ahome/etu-nis
    ls: impossible d'accéder à /ahome/etu-nis: Aucun fichier ou dossier de ce type
    
    # tail -3 /var/log/syslog 
    clnt automount[3652]: attempting to mount entry /ahome/etu-nis
    clnt automount[3652]: mount(nfs): no hosts available
    clnt automount[3652]: failed to mount /ahome/etu-nis
    
    Catastrophe ! Le montage automatique échoue.
  3. On reprend la même expérience avec un nom d'hôte DNS dont les enregistrements AAAA et PTR sont valides.
    # service autofs start
    [ ok ] Starting automount....
    # automount -m
    
    autofs dump map information
    ===========================
    
    global options: none configured
    
    Mount point: /ahome
    
    source(s):
    
      instance type(s): file 
      map: /etc/auto.home
    
      * | -port=2049,-fstype=nfs4 vm2.fake.domain:/home/&
    
    # dig +short aaaa vm2.fake.domain
    2001:db8:feb2:10::12
    root@clnt:/home/etu# dig +short -x 2001:db8:feb2:10::12
    vm2.fake.domain.
    
    L'adresse IPv6 utilisée est bien identique à celle du test précédent.
    # ls -lAh /ahome/etu-nis
    total 16K
    -rw------- 1 etu-nis etu-nis  385 mai   21 23:44 .bash_history
    <snip/>
    
    # tail -3 /var/log/syslog 
    clnt automount[3759]: mounted indirect on /ahome with timeout 300, freq 75 seconds
    clnt automount[3759]: attempting to mount entry /ahome/etu-nis
    clnt automount[3759]: mounted /ahome/etu-nis
    
    Bingo ! Cette fois-ci le montage se fait correctement. Enfin, si les paramètres de configuration sont publiés via NIS, ça fonctionne aussi.

Voilà. On peut considérer que le choix consistant à associer les trois services est pertinent puisqu'il illustre des usages distincts de la pile IPv6. À mon niveau de connaissances, je ne sais pas si le fait d'imposer l'utilisation des enregsitrements DNS par le démon automount est volontaire.

Dans tous les cours sur IPv6, il est courant de dire que comme le format numérique des adresses IPv6 est très difficile à retenir, l'usage des enregistrements DNS est impératif. Pour généraliser l'utilisation de la double pile réseau, il semble qu'il faille revoir la séquence des travaux pratiques. Je vais devoir aborder le service DNS au tout début de façon à en bénéficier pour le cycle sur le stockage et les systèmes de fichiers réseau. En conclusion, le support de travaux pratiques DNS est le prochain sur la liste !