Face à cette question et après avoir consulté une grande quantité de documentation, essaie de systématiser et d'enregistrer ce que tu as appris pour mieux le mémoriser. Rédige également un guide sur cette question pour ne pas avoir à répéter tout le processus.
La documentation de base se trouve en grande quantité sur
Définition du problème
Le client souhaite regrouper plusieurs serveurs loués en un seul réseau pour éviter d'avoir à payer plusieurs sous-réseaux supplémentaires, connecter tout son matériel à un routeur, leur attribuer des adresses locales internes et se protéger avec un pare-feu. Ainsi, tout le trafic doit circuler à l'intérieur du VLAN. De plus, il veut transférer les machines virtuelles d'un ancien serveur vers un nouveau et se débarrasser de l'ancien, mettre à niveau le matériel utilisé et transférer ses services vers un Proxmox plus récent.
Initialement, le client a 5 serveurs, chacun avec un sous-réseau supplémentaire, la première adresse de chaque sous-réseau étant attribuée à un pont supplémentaire sur Proxmox.
Les VM fonctionnent sous Windows et ont l'adresse 85.x.x.177/29 avec une passerelle 85.x.x.176.
Et dans la même configuration, tous les 5 serveurs ont leurs propres machines virtuelles configurées.
Il est amusant de noter que cette configuration est fondamentalement incorrecte en matière de réseau, car elle utilise l'adresse réseau pour le premier nœud et aussi comme passerelle. Si on essaie de mettre en place cette configuration sur une machine virtuelle sous Ubuntu, le réseau ne fonctionne pas.
Mise en œuvre
- Nous créons un vSwitch dans l'interface, lui attribuons un VlanID, ajoutons ce vSwitch à tous les serveurs nécessaires.
- Nous configurons un serveur de test pour pouvoir établir la configuration sans problèmes.
Nous lançons la première machine virtuelle chr selon .
Si vous utilisez le script fourni, faites attention à ce qu'il vérifie au début la présence du répertoire -d /root/temp, et si celui-ci n'existe pas, il crée le répertoire /home/root/temp, cependant le traitement continue toujours avec le répertoire /root/temp. Il est nécessaire de modifier le script pour créer le répertoire approprié.
- Nous configurons le réseau pour Proxmox.
Nous ajoutons un sous-interface avec le numéro VLAN, en précisant que la configuration des adresses se fera sur les ponts en utilisant inet manual. IMPORTANT. Il ne faut pas configurer d'adresses IP sur les interfaces que vous allez ensuite inclure dans le pont, car on ne sait pas si cela fonctionnera et comment cela fonctionnera.
Nous allons maintenant créer le pont vmbr0 et y associer la première adresse du serveur, fournie par notre fournisseur Hetzner, en indiquant le port du pont – il s'agit du premier interface physique sans VLAN. Nous ajouterons également une commande supplémentaire pour définir une route vers notre réseau additionnel, commandé chez Hetzner pour ce serveur via ce pont. L'ajout de la route sera effectif lorsque l'interface sera activée.
Le second pont sera l'interface pour le trafic local. Nous y ajoutons une adresse pour assurer la connectivité entre différents serveurs Proxmox sur le réseau local sans accès à Internet, en indiquant comme port le sous-interface eno1.4000, dédié à notre VlanID.
Lors de la configuration initiale, des conseils suggèrent d'installer le package ifupdown2 pour éviter de redémarrer complètement le serveur lors des modifications des interfaces réseau. Cependant, cela ne s'applique qu'à la configuration initiale. Lorsque vous utilisez des ponts et configurez déjà des machines virtuelles, vous pouvez rencontrer des problèmes de déconnexion réseau dans les VM. Même si vous avez modifié, par exemple, l'interface vmbr2, l'application de la configuration entraîne une perte de connexion sur toutes les interfaces internes qui ne revient qu'après un redémarrage complet du serveur. La commande ifdown&&ifup ne fonctionne pas. Si quelqu'un a une solution, je vous en serais reconnaissant.
La première interface configurée sur le serveur reste fonctionnelle et accessible.
Assignation d'une adresse pour CHR afin de ne pas perdre d'adresses du pool.
Le pool d'adresses attribué par Hetzner semble assez étrange pour un administrateur réseau, comme suit :
L'étrangeté réside dans le fait que la passerelle suggérée est l'adresse physique du serveur.
La solution classique proposée par Hetzner elle-même est mentionnée dans l'énoncé du problème et a été mise en œuvre par le client de manière autonome. Dans cette solution, le client perd la première adresse pour l'adresse réseau, la deuxième adresse pour le pont Proxmox, qui sera également la passerelle, et la dernière adresse pour le broadcast. Les adresses IPv4 ne sont jamais superflues. Cependant, si vous essayez directement de configurer sur CHR l'adresse IP 136.x.x.177/29 et la passerelle pour 0.0.0.0/0 en 148.x.x.165, vous pourrez le faire, mais la passerelle ne sera pas Direct Connected et donc injoignable.
Il est possible de contourner ce problème en utilisant un réseau de taille 32 pour chaque adresse, en indiquant l'adresse nécessaire comme nom du réseau, qui peut être n'importe laquelle. Cela revient à une connexion point à point.
Dans ce cas, la passerelle sera bien sûr accessible et tout fonctionnera comme nous le souhaitons.
Gardez à l'esprit que dans une telle configuration, il n'est pas recommandé d'utiliser la règle SRC-NAT masquerade, car l'adresse de sortie sera indéfiniment variée. Il est préférable d'indiquer action: src-NAT et l'adresse spécifique à partir de laquelle vous lancerez le client.
- Enfin.
Pour bloquer l'accès à Proxmox depuis Internet, utilisez les outils intégrés : il existe un excellent pare-feu.
Il n'est pas conseillé d'utiliser le pare-feu proposé par Hetzner, afin de ne pas se perdre dans l'emplacement des paramètres. De plus, Hetzner agira sur tous les réseaux, y compris sur ceux créés sur CHR, et pour ouvrir et rediriger les ports, il sera nécessaire de les ouvrir également dans l'interface web du fournisseur.
Source : habr.com
