kathara:decouverte
Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente | ||
kathara:decouverte [2019/09/08 15:09] – [Etendre les fonctionnalités de l’image Kathara] techer.charles_0870019y.campus.lyceeconnecte.fr | kathara:decouverte [2021/09/05 20:06] (Version actuelle) – techer.charles_educ-valadon-limoges.fr | ||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Cours : infrastructures réseaux | + | ====== Cours : présentation |
===== Présentation de Kathará ===== | ===== Présentation de Kathará ===== | ||
Ligne 43: | Ligne 43: | ||
* De définir le rôle de chaque VM soit comme simple ordinateur** client linux**, comme **serveur** en installant si nécessaire des paquets logiciels supplémentaires, | * De définir le rôle de chaque VM soit comme simple ordinateur** client linux**, comme **serveur** en installant si nécessaire des paquets logiciels supplémentaires, | ||
- | ===== Le jeu de commandes de Kathara ===== | ||
- | Netkit fournit deux groupes de commandes : | + | ====== Retour Accueil |
- | * les **vcommandes**, | + | |
- | * les **lcommandes**, | + | |
- | Si vous souhaitez travailler avec une seule VM, utilisez les vcommandes. Sinon, pour travailler avec plusieurs VMs, il est préférable et bien plus pratique de créer un laboratoire (Lab) et d’utiliser alors les lcommandes. | + | * [[kathara: |
- | + | ||
- | ==== Utilisation de machines autonomes ==== | + | |
- | + | ||
- | === les v-commandes === | + | |
- | + | ||
- | ^ Commande ^ Action ^ | + | |
- | |vstart|-> | + | |
- | |vlist|-> | + | |
- | |vconfig|-> | + | |
- | |vclean|-> | + | |
- | + | ||
- | === Gérer une VM === | + | |
- | + | ||
- | Pour s’assurer du bon fonctionnement de Kathara, vous pouvez créer depuis un terminal une première machine virtuelle avec le nom **sta1**. | + | |
- | **Création d’une VM avec vstart** | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | **Explications :** | + | |
- | * La commande vstart permet de lancer en interactif une VM ; | + | |
- | * **--eth** permet de définir le numéro de l’interface réseau **eth0** associée à au domaine de collision **HubDCA** (hub virtuel) ; Un domaine de collision correspond à un **concentrateur** pour Kathara. | + | |
- | * Le nom de la VM **sta1** est le dernier paramètre | + | |
- | + | ||
- | Voici votre première VM Netkit avec la session root automatiquement ouverte : | + | |
- | + | ||
- | {{ : | + | |
- | + | ||
- | Pour cette VM sta1, aucune adresse IP n’a été définie. C’est le bridge Docker créé par Kathara qui a fourni la configuration IP 172.20.0.2/ | + | |
- | {{ : | + | |
- | + | ||
- | + | ||
- | Pour visualiser le bridge créé par Kathara, tapez la commande suivante dans le terminal de votre serveur Debian/ | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | 1: lo: < | + | |
- | link/ | + | |
- | inet 127.0.0.1/8 scope host lo | + | |
- | | + | |
- | inet6 ::1/128 scope host | + | |
- | | + | |
- | 2: enp0s3: < | + | |
- | link/ether 08: | + | |
- | inet 192.168.1.199/ | + | |
- | | + | |
- | inet6 fe80:: | + | |
- | | + | |
- | 3: br-8edf20a49895: | + | |
- | link/ether 02: | + | |
- | inet 172.20.0.1/ | + | |
- | | + | |
- | 4: docker0: < | + | |
- | link/ether 02: | + | |
- | inet 172.17.0.1/ | + | |
- | | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | <WRAP center round info> | + | |
- | **INFORMATION**\\ | + | |
- | Le sous-réseau 172.0.0.0/8 est réservé pour l’utilisation de Kathara. Il ne faut donc pas l’utiliser pour défi-nir des plans d’adressage de vos sous-réseaux. Lors de la création de VMs autonomes ou dans des labs comme vous le verrez ensuite, Kathara va créer autant de bridges que vous définissez de domaine de colli-sion en leur associant un sous-réseau différent basé sur ce sous-réseau 172.0.0.0/ | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | **Visualisation de la VM créée avec vlist** | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS | + | |
- | 8ceba73bfb3f netkit_1000_sta1 0.00% | + | |
- | NETWORK ID NAME DRIVER | + | |
- | f332c80a9dbd | + | |
- | c28efeb7848e | + | |
- | 2877cae4fa72 | + | |
- | 708458e85954 | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | Vous pouvez visualiser : | + | |
- | * Les caractéristiques de la VM **sta1** : son **ID Docker 8ceba73bfb3f** ainsi que les ressources consommées ; | + | |
- | * La liste des interface réseaux du serveur Debian/ | + | |
- | + | ||
- | Le commande Docker montre le conteneur **8ceba73bfb3f** qui correspond à **sta1** et l’image **kathara/ | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | CONTAINER ID IMAGE COMMAND | + | |
- | 8ceba73bfb3f kathara/ | + | |
- | … | + | |
- | </ | + | |
- | Cette autre commande permet également de visualiser le container Docker créé et vous pouvez le visualiser avec la commande suivante : | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | CONTAINER ID IMAGE | + | |
- | 8ceba73bfb3f kathara/ | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | Pour arrêter la VM avec une commande Kathara ; le container est alors supprimé : | + | |
- | + | ||
- | <WRAP center round info> | + | |
- | **INFORMATION**\\ | + | |
- | La commande **vconfig** semble actuellement ne pas fonctionner convenablement | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | **Arrêter une VM avec vclean** | + | |
- | Le container est alors supprimé : | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | Any network still in use by another machine will not be deleted (and will raise an error instead) | + | |
- | Containers will be deleted | + | |
- | netkit_1000_sta1 | + | |
- | netkit_1000_H | + | |
- | btssio@ubuntudocker: | + | |
- | CONTAINER ID IMAGE | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | + | ||
- | ==== Utilisation des labs ==== | + | |
- | === Pourquoi utiliser les labs ? === | + | |
- | + | ||
- | Quand vous avez à créer et gérer une seule VM, vous utilisez les v-commandes. Pour des infrastructures utilisant plusieurs VMs, il est préférable de créer un laboratoire ou **lab** et de manipuler ce lab avec les **l-commandes**. Ces labs permettent de concevoir mais aussi de conserver une architecture réseau complexe ou que l'on souhaite pouvoir réutiliser et cela d’autant plus facilement qu’un lab se traduit par une arborescence de dossiers contenant des fichiers de configuration. Un lab occupe très peu de place et est facile à sauvegarder et à échanger. Vous trouverez sur Internet des ressources et des exemples de labs. | + | |
- | + | ||
- | **Voici des liens vers les labs proposés par l’équipe de Kathara :** | + | |
- | * https:// | + | |
- | Sur ce site, vous trouverez de la documentation ainsi que des exemples de simulations qui peuvent être très complexes. | + | |
- | + | ||
- | Un Lab **minimaliste** consiste en une arborescence comprenant : | + | |
- | * Obligatoirement un fichier de configuration (**lab.conf**) qui décrit les machines virtuelles qui seront lancées, leurs interfaces et les domaines de collision. | + | |
- | * un **répertoire** par machine virtuelle qui sera lancée, dans lequel on peut stocker des fichiers. Pour l’instant, | + | |
- | * Eventuellement pour les VM des fichiers **VMx.startup** et/ou un fichier **VMx.shutdown** qui indiquent les actions à réaliser lors du lancement ou de l’arrêt de la VMx (VMx correspond au nom de la VM Kathara). Cela permet de configurées automatiquement la VMx lors du lancement du lab à l'aide de scripts shell. Les scripts doivent être exécutables. | + | |
- | + | ||
- | **Les l-commandes** | + | |
- | + | ||
- | Les l-commandes sont utilisables dans le répertoire du lab qui doit contenir au minimum le fichier lab.conf, ex-ception faire de la commande **lwipe**. | + | |
- | + | ||
- | ^ Commande ^ Action ^ | + | |
- | |lstart|-> | + | |
- | |lclean|-> | + | |
- | |linfo|-> | + | |
- | |ltest|-> | + | |
- | |lwipe|-> | + | |
- | + | ||
- | + | ||
- | Dans l' | + | |
- | * la création de l’arborescence des dossiers du lab, | + | |
- | * le contenu du fichier lab.conf, | + | |
- | * la création des fichiers qui permettent de personnaliser le fonctionnement des VMs, | + | |
- | * l’utilisation des l-commandes, | + | |
- | * l’ipmasquerade pour configurer une VM comme routeur NAT. | + | |
- | + | ||
- | + | ||
- | ===== Etendre les fonctionnalités de l’image Kathara ===== | + | |
- | + | ||
- | Lorsque Kathara crée une VM, avec une v-commande ou une l-commande, c’est un conteneur qui est créé par Docker à partir de l’image **kathara/ | + | |
- | + | ||
- | L’équipe de développement de Kathara a intégré à cette image un certain nombre de paquets logiciels de telle sorte que les VMs créées puissent les utiliser. Cependant, si dans la réalisation de votre maquette vous avez besoin d’un paquet logiciel qui n’est pas présent dans les VMs, vous pouvez **l’ajouter** à l’image **kathara/ | + | |
- | + | ||
- | La démarche qu’il faut suivre est la suivante : | + | |
- | * **Créer** un conteneur avec image kathara/ | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | <WRAP center round info> | + | |
- | **INFORMATION**\\ | + | |
- | Le conteneur est créé en lui associant un nom à votre convenance, ce qui sera plus facile pour l’identifier. | + | |
- | </ | + | |
- | + | ||
- | * **Se connecter** à une console du conteneur : | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | root@93e38cf2c65:/# | + | |
- | </ | + | |
- | * **Mettre à jour** le conteneur : | + | |
- | <code shell> | + | |
- | root@93e38cf2c65:/# | + | |
- | </ | + | |
- | * **Installer** les paquets logiciels voulus ; pour cet exemple la bibliothèque scapy pour python : | + | |
- | <code shell> | + | |
- | root@93e38cf2c65:/# | + | |
- | </ | + | |
- | * **Quitter** le conteneur : | + | |
- | <code shell> | + | |
- | root@93e38cf2c65:/# | + | |
- | </ | + | |
- | * **Enregistrer** le conteneur modifié dans l’image **actuelle** ou comme une **nouvelle image**. La deuxième solution sera utilisée car elle permet de garder l’image de base et dans ce cas il faut faudra indiquer le nom de cette nouvelle image, soit pour toutes les VMs, soit uniquement pour celles qui en ont besoin. | + | |
- | + | ||
- | + | ||
- | * **Pour information : enregistrer** le conteneur dans l’image actuelle : | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | * **A faire : enregistrer** le conteneur dans une nouvelle image: | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | * **Utiliser** la nouvelle image pour tous les conteneurs Kathara: | + | |
- | + | ||
- | Il est nécessaire de modifier la directive IMAGE_NAME de Kathara en modifiant à ligne 15 du fichier **/ | + | |
- | <code shell> | + | |
- | btssio@ubuntudocker: | + | |
- | </ | + | |
- | + | ||
- | * **Utiliser** la nouvelle image pour une seule VM d’un lab : | + | |
- | Il suffit d’indiquer dans le fichier lab.conf un paramètre supplémentaire précisant l’image à utiliser : | + | |
- | <code shell> | + | |
- | Routeur[image]=netkit_btssio | + | |
- | </ | + | |
- | + | ||
- | Vous disposez maintenant de deux images pour les VMs de Kathara : | + | |
- | * L’image de base **kathara/ | + | |
- | * Et une image personnalisée **kathara/ | + | |
- | + | ||
- | ====== Retour Accueil SISR3 ====== | + | |
- | + | ||
- | * [[sisr3:accueil|SISR3]] | + | |
kathara/decouverte.1567948186.txt.gz · Dernière modification : 2019/09/08 15:09 de techer.charles_0870019y.campus.lyceeconnecte.fr