Journal TP réseau en université

Posté par  (site web personnel) .
Étiquettes : aucune
0
23
fév.
2007
Salut mon journal,

J'essaye de monter un TP de réseaux dans mon université, afin que les étudiants bidouillent des choses simples comme la configuration réseau, mettre en place des services...

Problème: les étudiants ont des machines mais ils ne peuvent être root dessus, difficile donc de faire des choses amusantes avec le réseau. De plus, impossible de les faire booter sur un live CD (pour des raisons de sécurité, le BIOS ne boote pas sur le lecteur CD).

La solution la plus intéressante semble la virtualisation, mais elle a une limitation: je désire que les machines virtuelles répartis sur chaque PC ne puissent communiquer qu'entre-elles (en quelque sorte, il existerait un réseau privé sur le réseau filaire). Ainsi, j'isole les machines vis-à-vis de la structure réseau en production.

Mais aucun produit ne semble répondre à cette demande. La seule chose qui existerait serait une version avancée de vmware qui coûte les yeux de la tête.

Est ce que quelqu'un a du retour d'expérience sur ce genre d'installation ?

  • # QEmu ?

    Posté par  (site web personnel) . Évalué à 3.

    Il y a diverses possibilités de configuration pour le réseau, voir peut-être par là...

    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: QEmu ?

      Posté par  (site web personnel) . Évalué à 3.

      Network options:
      -net nic[,vlan=n][,macaddr=addr][,model=type]
      create a new Network Interface Card and connect it to VLAN 'n'
      -net user[,vlan=n][,hostname=host]
      connect the user mode network stack to VLAN 'n' and send
      hostname 'host' to DHCP clients
      -net tap[,vlan=n][,fd=h][,ifname=name][,script=file]
      connect the host TAP network interface to VLAN 'n' and use
      the network script 'file' (default=/etc/qemu-ifup);
      use 'fd=h' to connect to an already opened TAP interface
      -net socket[,vlan=n][,fd=h][,listen=[host]:port][,connect=host:port]
      connect the vlan 'n' to another VLAN using a socket connection
      -net socket[,vlan=n][,fd=h][,mcast=maddr:port]
      connect the vlan 'n' to multicast maddr and port
      -net none use it alone to have zero network devices; if no -net option
      is provided, the default is '-net nic -net user'
      -tftp prefix allow tftp access to files starting with prefix [-net user]
      -smb dir allow SMB access to files in 'dir' [-net user]
      -redir [tcp|udp]:host-port:[guest-host]:guest-port
      redirect TCP or UDP connections from host to guest [-net user]


      http://compsoc.dur.ac.uk/~djw/qemu.html


      Peut-être en lançant un QEmu "routeur" qui se récupère les paquets... et qui ne route pas vers le réseau.


      Un QEmu sans interface réseau (éventuellement un 'bridge' virtuel ethernet) qui fasse tourner d'autres QEmu qui se basent sur ce bridge - faudra pas être pressé.

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: QEmu ?

        Posté par  . Évalué à 0.

        Version avancée de VMware ?

        Perso, j'ai VMware server, mais mon dernier test sur ce type de réseau s'est déroulé sous VMworkstation sous Windows. C'est censé fonctionner pareil sous Linux.
        L'interface est vraiment simple a utiliser, mais bon, je sais, pour tes étudiants c'est peut-être mieux d'utiliser de préférence des logiciels libres et hyper-portables de sucroît !

        Qemu est très bien niveau performances aussi !
        Mais toujours pas intuitif.

        À quand un clone au niveau de l'interface graphique ?

      • [^] # Re: QEmu ?

        Posté par  (site web personnel) . Évalué à 1.

        J'avais déjà repéré que Qemu pouvait faire une liason entre deux machines, mais je n'avais pas reperé le fait qu"il pouvait aussi faire du multicast, ça pourrait résoudre certains probèmes (le fait d'avoir une machine routeur par exemple).

    • [^] # Re: QEmu ?

      Posté par  . Évalué à 6.

      Je confirme!

      Avec Qemu, il est possible de monter facilement un réseau de 2 machines virtuelles qui n'auront aucun autre accès au réseau physique. En fait, on a simplement un socket ouvert entre les 2 machines virtuelles.

      Exemple tiré de la documentation (http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10)


      # launch a first QEMU instance
      qemu linux.img -net nic,macaddr=52:54:00:12:34:56 \
      -net socket,listen=:1234

      # connect the VLAN 0 of this instance to the VLAN 0
      # of the first instance
      qemu linux.img -net nic,macaddr=52:54:00:12:34:57 \
      -net socket,connect=127.0.0.1:1234

  • # Chez nous

    Posté par  . Évalué à 3.

    Les TP réseaux dans mon école était fait dans une salle réservée à cela.

    Quelques ordi en réseaux, mais coupés du reseau de l'école et le mot de passe root était à afficher au tableau avant le début du TP.

    Pour faire des TPs de réseau, pas besoin d'une grosse config, pas besoin d'interface graphique. Je suis sur qu'il y a plein de vieilles SPARC qui doivent trainer en haut d'armoire et qui ne demandent qu'à être remises en route.

    Et puis vu qu'ils sont coupés du reste du monde, la salle peut servir à faire le TP de sécurité de la semaine d'après :)

    • [^] # Re: Chez nous

      Posté par  . Évalué à 2.

      La facon dont on faisait ca chez nous...

      On avait un profil d'installation dedie, donc la veille du tp, sequence reboot/reinstall auto de toute la salle (merci FAI), suivie d'une deconnexion complete du reseau de la salle en qestion par rapport au reste de l'ecole. Une fois le (enfin les) TP fini, reinstall du systeme standard.

    • [^] # Re: Chez nous

      Posté par  (site web personnel) . Évalué à 7.

      ah, nous on faisait le TP sécurité la 1ère semaine, comme ça la 2ème semaine nous avions déjà le mot de passe root pour faire le TP réseau :p

    • [^] # Re: Chez nous

      Posté par  . Évalué à 1.

      Pour nous, on a une salle avec des postes dédiés à cela, branchés ou non sur le réseau (pour pas foutre en l'air le réseau avec certains tp), mot de passe root/toto. Je crois pas qu'on ai jamais eu de soucis. Le fait d'etre root sur la machine n'amene pas de risque par rapport au réseau.

      • [^] # Re: Chez nous

        Posté par  (site web personnel) . Évalué à 1.

        le fait d'être root sur le réseau te permet de faire de nombreuses choses qu'un utilisateur simple ne peut pas faire...

        faire une capture, un nmap, un traceroute, etc...

        bref, largement assez pour récupérer des informations sensibles.

        En tout cas, dans le cadre de nos TPs réseaux, on a un parc de "vieilles" machines de TPs. On bouscule un peu une des salles de TPs, et on câble le réseau sur un switch (ou plusieurs switchs suivant l'architecture réseau que l'on veut) que l'on met dans la salle (merci aux administrateurs qui sont très performant pour nous aider à faire tout cela).

        Avantage : les étudiants peuvent être root sur une vrai machine physique, ils peuvent voir comment se passent le câblage.

        Et enfin, pour certains TPs, on met une machine en passerelle permettant d'avoir accès à Internet pour tout le monde !

    • [^] # Re: Chez nous

      Posté par  . Évalué à 2.

      Je me disais bien que mes profs avaient quelques problèmes avec la sécu :

      Pour les TPs réseaux, c'était dual-boot "linux pour les TPs"/"linux normal", toujours branché au réseau de l'école mais avec une 2e carte réseau pour le TP. Bien sûr, on avait le mot de passe root du 1er linux pour les TPs.
      Après avoir récupéré la config pour le réseau de l'école sur la 2e partition (et accessoirement le hash md5 du mdp de grub, cassé en 5min, utile pour les autres bécanes en dehors de la salle de TP), j'avais accès au réseau, où je me suis rendu compte que les comptes des profs étaient accessibles en NFS dont le serveur n'avait pas de squash_root. Bon, je me suis arrêté là, parce que je pense que j'aurais découverts encore d'autres trucs inavouables.

      Et non je ne balançerai pas où c'était...

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Retour d'experience

    Posté par  . Évalué à 1.

    J'ai eu un cour pratique d'administration reseau sous linux (15 heures) lors de ma dernière année d'étude. On était un petit groupe (4 personnes) et cela s'ait résumé à configurer un serveur (redhat 7.3) et 4 postes de travail (suze ?.?). Le serveur n'avait que des services ordinaires (DHCP, mail, NFS)

    Bref, pour ne rien chambouller de la config du labo, on avait juste récupéré qque vieux disques durs, qu'on branchait en primary master au debut de chaque labo (et on debranchait le disque windows NT ). Simple rapide et efficace ;)

  • # Halala

    Posté par  . Évalué à 10.

    Après les étudiants qui viennent dans les forums demander qu'on leur fasse leurs devoirs, voilà les profs qui demandent qu'on les aide pour leurs cours…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.