--- title: "La virtu pour les nuls : faire un bridge" date: "2019-08-11" author: raspbeguy template: post tags: Non classé --- Je vous avais déjà fait part de ma fascination pour la virtualisation. Et c'est vrai. J'aime la virtualisation. Bon Dieu ce que je l'aime. Aaaaaah. Diantre j'adore ça. Ça me donne envie de sortir dans la rue et de faire des trucs stupides tellement je kiffe ça. Bref. Plus rationnellement et plus décemment, la virtualisation (ou l'isolation de contexte, alias les conteneurs, mais j'ai plus de mal avec ça) est le moyen le plus efficace pour avoir des services propres, maintenables et sûrs. C'est une méthode de travail excellente et très intéressante. La virtualisation nécessite que la machine hôte mette à disposition des machines invitées un certain nombre de ressources : processeurs, mémoire, interfaces... Notamment, nos machines virtuelles ont la plupart du temps besoin de réseau. Il existe au moins deux façons de faire du réseau avec des machines virtuelles, une bonne et une mauvaise une facile et une pratique : - La méthode facile, c'est de mettre toutes les VMs d'un hyperviseur dans un réseau NATé, dont l'hyperviseur est la passerelle. - La méthode pratique, c'est de passer un pont (bridge) liant l'interface physique de l'hôte avec les interface virtuelles des invités. Maintenant un brin d'explication. - La méthode NAT est facile car elle est déployée par défaut par la plupart des hyperviseurs. Elle ne demande aucune modification du réseau de l'hyperviseur. Toutes les requêtes des invités semblent donc émaner de l'hôte, de la même manière que dans votre réseau local dans votre maison, toutes vos machines passent leurs requêtes à votre box-routeur. Cela pose un problème de taille lorsque les invités ont besoin d'être accessible de l'extérieur, ce qui nécessite de gérer des règles d'ouvertures de ports (et donc deux machines ne peuvent pas écouter sur le même port, vu de l'extérieur). D'autre part, il arrive souvent que l'hôte soit lui même derrière un NAT (par exemple si vous ne disposez que d'une seule IP publique pour votre foyer comme c'est le cas dans 99% des connexions internet des particuliers). Placer donc un deuxième NAT géré par votre hôte apporte donc un niveau de complexité à votre infrastructure réseau. - La méthode Bridge est pratique car, d'un point de vue réseau, vos invitées sont sur le même niveau que votre hôte. Outre le fait que vous avez autre chose à faire de votre vie que de gérer un double NAT et les redirections qui s'ensuivent, ça rend les invités en quelque sortes indépendants de leurs hôtes. Par exemple, imaginons que vous avez deux hôtes H1 et H2 qui font tourner un invité chacun, G1 sur H1 et G2 sur H2. Un client tiers n'a pas besoin de savoir sur quel hôte se situe G1 et G2 pour les contacter car ils ont tous les deux des IPs indépendantes. D'autre part, si vous devez passer H1 en maintenance, il vous suffit de migrer G1 sur H2 sans autre forme de procès, ce sera complètement transparent pour votre infrastructure (pour peu que votre routage de flux soit flexible).eth0 Disons donc que pour faire tourner une distribution desktop ponctuellement pour tester un programme, vous n'avez probablement pas besoin de cet article et vous pouvez très bien vivre avec la solution NAT. Mais pour un parc de machine en production, il est presque toujours indispensable de passer par la solution Bridge. Mais au fait dis moi Jamy, c'est quoi un bridge ? Et bien Fred, un bridge ça veut dire pont en anglais, et comme son nom l'indique, ça va permettre de lier des interfaces réseau. Ici, le but est de lier les interfaces virtuelles des invités à l'interface physique de la machine. Cela implique que l'interface physique sera partagée par plusieurs machines. Mettons nous dans la tête d'un hôte dont on a pas encore configuré le bridge. Disons que son interface réseau physique s'appelle `eth0`. Donc, par défaut et de manière naturelle, cette interface va porter son IP et il ne va pas se poser plus de question que ça. Nous, on veut changer ça. On va créer un bridge, appelons le `br0`, qui va être le maître de `eth0`, que sera donc son esclave (ne me regardez pas comme ça, ce sont là les termes officiels, je vous assure). On configurera notre plateforme de virtualisation préférée (libvirt en ce qui me concerne, proxmox pour d'autres, vmware pour les pêcheurs) pour lui dire d'utiliser `br0` comme périphérique réseau. Alors, lorsqu'on lancera un invité, son interface virtuelle sera esclave de `br0`. Quant à l'hôte, l'interface qui utilisera à présent pour se connecter au réseau sera `br0`. Si votre hôte est sous CentOS, on peut configurer un nouveau bridge, ici en adressage statique sur mon réseau privé derrière mon routeur, en créant le fichier `/etc/sysconfig/network-scripts/ifcfg-br0` contenant ceci : ``` DEVICE=br0 TYPE=Bridge BOOTPROTO=static DNS1=8.8.8.8 DNS2=8.8.4.4 GATEWAY=192.168.1.1 IPADDR=192.168.1.10 NETMASK=255.255.255.0 ONBOOT=yes ``` Pour un hôte sous Debian, on aura ce bloc dans `/etc/network/interfaces` : ``` iface br0 inet static bridge_ports eth0 address 192.168.1.10 broadcast 192.168.1.255 netmask 255.255.255.0 gateway 192.168.1.1 ``` Il ne faut alors pas oublier de changer la configuration de `eth0` pour qu'aucune IP ne lui soit associé. Cette interface n'aura d'autre rôle que de transmettre et recevoir les paquets bruts à notre bridge, qui se chargera de dispatcher les paquets à ses esclaves où à l'hôte. C'est tout pour aujourd'hui. Allez chauffe Marcel, envoie le générique de fin.