Étude du déploiement de réseaux virtuels à destination de 300 étudiants.

Rappel :

• VDN ne prend en charge que la distribution Debian et peut-être quelques dérivées, dont Kali.
• Les systèmes COW peuvent êtres modifiés dans la limite de la taille du disque initial et du quota disque. Ils sont souples pour l'utilisateur mais gourmand en espace disque.
• Les systèmes TGZ peuvent êtres modifiés dans la limite de quelques dizaines de Mo maximum pour cause de temps de chargement/déchargement longs au démarrage/arrêt du système. Ils sont limités en modifications mais leur sauvegarde est très économe en espace disque .

Chaque étudiant(e) dispose de 3 Go d'espace de sauvegarde (300 x 3 Go = 900 Go au total.

Dans leur espace de 3 Go les étudiant(e)s gèrent chacun(ne) :

• 2 machines virtuelles en mode COW (une Debian et une Kali). On compte environ 1 Go pour chacune d'elles.
• 30 machines virtuelles en mode TGZ (Debian ou Kali). Elles se partagent le Go restant.

A noter qu'il est possible de faire de nombreuses machines virtuelles temporaires (modifications dans /tmp). Pour des TP d'installation par exemple.

• A définir le plus précisément possible et à l'avance car une fois données aux étudiants les machines virtuelles de type COW ne sont plus directement gérables par l'équipe technique/pédagogique. Le type TGZ permet quand à lui de bénéficier à chaque démarrage de la dernière version du disque

• Dans tous les cas, des adaptations éventuelles pourront être faites par l'étudiant ou l'enseignant via des commandes ou des scripts.

• A tout moment un étudiant peut recréer ses machines virtuelles.

• logiciel libre en cours de développement (1 seul développeur)
• utilise KVM/QEMU uniquement
• permet de faire des réseaux de systèmes virtuels en cherchant à optimiser :
  • la sécurité
  • l'occupation disque

Quelques liens :

• Documentation générale
• Quelques schémas

• Systèmes : Debian / Kali
• Quantité d'espace disque nécessaire à l'étudiant
• Quantité de RAM
• Quantité de swap

• Logiciels installés (docker, wireshark, nagios, serveur web, …)
• Utilisateurs supplémentaires (autres que root)
• type d'enregistrement des modifications faites par l'étudiant :
  • persistant : tout au long de sa formation
  • temporaire : le temps d'un TP (les installations/modifications sont faites dans /tmp de l'hôte, avec un problème en cas de coupure de courant)

• direct : chaque étudiant dispose de son propre disque (volume disque important)

• cow : Copy On Write (snapshot). Seuls les blocs disques modifiés du système initial sont sauvegardés :
  • + : gain d'espace disque, à relativiser si le système se met à jour régulièrement).
  • - : le disque initial ne pourra plus être modifié sous peine d'invalider les snapshots ! Donc théoriquement gestion d'un historique de versions sur les 2/3 ans de la formation…

• tgz : (tar.gz) seuls les fichiers modifiés sont sauvegardés (sous forme compressée) :
  • + : gain d'espace disque très important
  • - : spécifique à Debian (Kali fonctionne).
  • - : inadapté pour les gros volumes modifiés (quelques dizaines de Mo seulement). En gros il faut fournir tous les paquets utiles sur le disque de base. La procédure pour ajouter des paquets est simple et décrite ici . A leur prochain démarrage les systèmes de type tgz bénéficieront des logiciels/fichiers installés. Attention cependant aux masquages indésirables de fichiers
  • Masquages indésirables de fichiers]].

La ou les machines virtuelles des étudiants peuvent devoir éventuellement :

• 1. être connectées à Internet. C'est le cas par défaut.

• 2. être connectées entre elles (réseaux virtuels). 256 “hubs” (émulés par un simple canal multicast) sont disponibles par réseau virtuel. Par défaut ces “hubs” sont locaux à la machine hôte (ils ne “polluent” pas le réseau réel)

• 3. avoir la possibilité de joindre les machines/réseaux d'autres étudiants. Un seul hub (NET_G) est commun à tout le réseau local (à portée de multicast). Ce hub peut-être utilisé pour simuler un Internet virtuel entre des machines virtuelles situées sur des hôtes différents (ne pas confondre avec l'accès à Internet (le réel) du point n°1).

Du plus simple : une VM connectée à Internet (via le proxy)

Au moyen : 2 ou 3 VM interconnectées et connectés à Internet

Au plus compliqué : un réseau tout entier

Sous VDN tout est scripts shells bash (exception faite pour l'interface graphique qui est Ruby/GTK2).

• Le logiciel lui même et les commandes qu'il fournit
• La configuration des machines virtuelles, réseaux virtuels (fichiers de définition de variables shell)
• Les scripts de configuration des machines virtuelles/réseaux virtuels

• 1 seul script par réseau pour générer le réseau :

• Se base sur un fichier de définitions communes
• pour générer les fichiers spécifique à chaque machines

Exemple de rôles :

• baseConfigAll : configure la (ou les machines) dans un état initial (adresse IP, …)
• upgradeAll : mise à jour de la machine (installation de paquets, post configuration…)

Mais tout autre rôle possible :

• repairAll : place le réseau dans l'état final
• testAll : test le réseau

Mise en oeuvre :

• Les scripts shells sont lancés par l'utilisateur sur l'hôte
• ** les scripts shells doivent pouvoir faire un ssh (authentification par clés publique/privée) de utilisateur/hôte vers root/système virtuel). L'inverse, root/système virtuel vers utilisateur/hôte n'est pas nécessaire.

#!/usr/bin/env bash 
 
set -eu
 
DESC="Configuration de base de alice et bob (hostname, hosts, interfaces)."
 
run() {
 
    . $VDN_PATH/bin/functions-scripts.sh
 
    setErrorHandler
    echoStart
 
    requireSshGuests alice bob
 
    parallelDisablePause
 
    vdn-scripts baseConfigAlice baseConfigBob
 
    unsetErrorHandler
    echoDone
}

...
 
# Fixer un fichier
 
...
 
# Exécuter une commande sur le système virtuel
 
...

Au département informatique, chaque étudiant dispose déjà de 30 machines virtuelles, sans aucun espace supplémentaire autre que quelques Mo (moins de 10 Mo je pense) dans leur home.

Comment ?

• en minimisant le nombre de systèmes d'exploitations :
• un seul géré actuellement : Debian stable (potentiellement tout système est intégrable si supporté par KVM/QEMU (GNU/Linux, BSD, Windows, ARM (Android, raspberry, …))

• En minimisant l'espaces disque occupé (sauvegardes de type tgz).

• l'équipe technique/pédagogique crée les systèmes de base
• l'équipe technique/pédagogique défini les commandes/scripts (seulement si ssh activé)
• l'étudiant démarre ses machines et éventuellement applique les commandes/scripts

• attention : chaque système d'exploitation à intégrer nécessite
  • une étude particulière (installation, lancement, personnalisation)
  • occupe de la place sur le disque

• Accès à /dev/kvm (modules noyaux kvm, kvm_{intel,amd})

notamment :

• hôte et réseaux de l'hôte protégés
  • aucune élévation de privilège possible actuellement avec /dev/kvm
  • aucune pile IP sur le réseau pédagogique en tant que root pour l'étudiant (utilisation de slirp).

• machines virtuelles protégées entre elles
  • absence de mots de passe par défaut
  • fichier des modifications en lecture seule pour les propriétaires.

Un compte vdn hébergeant :

• le logiciel
• le disque Debian (modifié). Physiquement situé sur londres et importé de façon transparente par NFS
• une liste de réseaux

• L'étudiant lance VDN : ~vdn/vdn/bin/vdn → interface graphique
• il ouvre le réseau de son choix
• démarre les machines virtuelles (et éventuellement applique des scripts).

• Propose une interface graphique

• Génère automatiquement la ligne KVM associée à la machine en tenant compte de ses spécificités :

• type de sauvegarde
• interconnexions réseaux

qemu-system-x86_64 -smp 8 -enable-kvm -cpu host -device virtio-rng-pci,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 -pidfile /tmp/vdn-passerelle-davalan-pid -rtc base=localtime -m 256M -initrd /home/davalan/vdn/files/initrd.img-4.19.0-5-amd64 -kernel /home/davalan/vdn/files/vmlinuz-4.19.0-5-amd64 -append root=/dev/vda1 ro console=ttyS0,115200n8 vdn-emulator=kvm vdn-mode=tgz vdn-nb-disk=1 net.ifnames=0 noresume fastboot -boot order=c -drive file=/home/davalan/vdn/files/DebianBuster-amd64.disk,if=virtio,snapshot=on,format=raw -drive file=/tmp/vdn-passerelle-davalan-config.tgz,if=virtio,media=disk,format=raw -drive file=/home/davalan/vdn-save/fixme/passerelle.tgz,if=virtio,media=disk,format=raw -drive file=/tmp/vdn-passerelle-davalan-part,if=virtio,media=disk,format=raw -drive file=/tmp/vdn-passerelle-davalan-swap,if=virtio,media=disk,format=raw -drive file=/tmp/vdn-passerelle-davalan-out,if=virtio,media=disk,format=raw -device virtio-net-pci,netdev=n1,mac=52:55:25:E8:05:00 -netdev socket,id=n1,mcast=239.2.0.0:2000 -device virtio-net-pci,netdev=n2,mac=52:55:25:E8:05:01 -netdev socket,id=n2,mcast=234.1.37.232:2001 -device virtio-net-pci,netdev=n3,mac=52:55:25:E8:05:02 -netdev socket,id=n3,mcast=234.1.37.232:2002 -device virtio-net-pci,netdev=n0,mac=52:55:25:E8:05:03 -netdev user,id=n0,hostfwd=tcp::5522-:22 -serial mon:stdio -monitor null -vnc unix:/tmp/vdn-vnc-davalan-passerelle-socket

• Au lancement de la VM :
  • Création des fichiers temporaires ou COW ou TGZ nécessaires
  • Calculs dynamiques des adresses MAC, IP, … pour en assurer l'unicité si nécessaire
  • Gère la redirection des ports nécessaire a slirp
  • Active éventuellement le mode graphique de la VM (port pour serveur VNC)
  • … ?

?

• un étudiant root sur sa machine virtuelle peut-il affecter :
  • la machine hôte ?
  • le réseau hôte ?
  • le compte universitaire d'un autre utilisateur ?