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 lolop (site web personnel) . Évalué à 3.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: QEmu ?
Posté par lolop (site web personnel) . Évalué à 3.
-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é.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: QEmu ?
Posté par freebourg . Évalué à 0.
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 Julien CARTIGNY (site web personnel) . Évalué à 1.
[^] # Re: QEmu ?
Posté par gentildemon . Évalué à 6.
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)
# Chez nous
Posté par TilK . Évalué à 3.
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 imalip . Évalué à 2.
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 BAud (site web personnel) . Évalué à 7.
[^] # Re: Chez nous
Posté par Romeo . Évalué à 1.
[^] # Re: Chez nous
Posté par Sylvain Rampacek (site web personnel) . Évalué à 1.
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 benoar . Évalué à 2.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Retour d'experience
Posté par xavier thomas . Évalué à 1.
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 Sylvain Sauvage . Évalué à 10.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.