Commentaire : Commenter le routage entre un serveur CSA virtualisé et une installation HOS virtualisée

2015-03-10

Machine-translated — the English original is authoritative.

Beaucoup d’entre vous, experts en réseau, ne comprendront peut-être pas la nécessité d’un tel article. En tant que débutant à la fois dans OpenStack et dans le domaine du réseau, ce processus n’était pas clair pour moi.

Le diagramme suivant illustre l’installation que j’utilisais : sur un ordinateur portable Windows 7, je faisais fonctionner VMware Workstation 10 et, à l’intérieur de celui-ci, j’avais une machine virtuelle (VM) autonome de Cloud Service Automation (CSA). Le réseau de cette VM était bridgé vers l’interface de mon ordinateur portable, permettant à cette VM d’obtenir une adresse DHCP sur mon réseau local 192.168.1.0/24. Le deuxième système que j’utilisais était un DL360G7 qui avait Ubuntu 14.04 comme système d’exploitation hôte, également connecté au réseau 192.168.1.0/24. Ce DL360G7 hébergeait une installation virtuelle de Helion OpenStack v1.1 [ce processus d’installation peut être trouvé dans cet article précédent].

Étape 1

Évidemment, il doit y avoir une route sur l’hôte Windows 2k8 du serveur CSA vers les points de terminaison de l’API du service HOS que je souhaite consommer, qui se trouvent sur un réseau 192.0.2.0/24. Cela n’existe pas par défaut, comme on peut le voir en regardant la table de routage de l’hôte ci-dessous.

netstat -rn

Un ping rapide depuis le serveur CSA vers l’un des hôtes HOS confirme également le problème de routage.

ping 192.0.2.2 /t

Le réseau 192.0.2.0/24 est virtualisé sur le DL360G7 et ne peut être accédé à distance que par l’interface physique du DL360G7, qui a une adresse IP de 192.168.1.13. C’est ce qu’on appelle l’adresse de passerelle.

Ouvrez une fenêtre d’invite de commandes sur le serveur CSA : Démarrer -> Exécuter -> cmd
Entrez une route vers le réseau HOS en utilisant la commande suivante :

route add -p 192.0.2.0 mask 255.255.255.0 192.168.1.13

Les routes réseau sur l’hôte CSA devraient maintenant ressembler à ceci (nous ne nous préoccupons que de la nouvelle addition de 192.0.2.0 – il est probable qu’il y ait de nombreuses autres routes sur votre système).

netstat -rn

Maintenant, lorsque vous pinguez un serveur sur le réseau 192.0.2.0/24, vous devriez voir une réponse de l’hôte serveur DL360G7. Ne paniquez pas ! – Oui, cela ne fonctionne toujours pas, mais au moins vous pouvez voir que l’hôte correct répond désormais à votre demande.

ping 192.0.2.2 /t

Il est maintenant temps de passer au serveur hôte Ubuntu DL360G7. Laissez le ping en cours d’exécution sur le serveur hôte CSA [utilisez l’option /t].

Étape 2

Si nous regardons l’interface hôte maintenant sur le serveur hôte HOS DL360G7, nous pouvons voir que la demande de ping arrive, mais qu’elle ne reçoit pas de réponse.

tcpdump -ni em1 icmp

Les tables de routage sur le serveur Ubuntu indiquent où chercher ensuite.

netstat -rn

Tout le trafic pour le réseau 192.0.2.0/24 est routé via l’interface virbr0.
Examinez la sortie sur cette interface virbr0 pour voir ce qui arrive au trafic.

tcpdump -c 10 -ni virbr0

Il n’y a aucun signe de demandes de ping provenant de l’hôte CSA 192.168.1.12 arrivant jusqu’ici.
Le problème se situe donc entre l’interface em1 et l’interface virtuelle virbr0 – qu’y a-t-il entre ces interfaces ? Iptables ! également connu sous le nom de pare-feu hôte.
Un rapide coup d’œil aux iptables sur l’hôte Ubuntu DL360G7 révèle l’obstacle final dans la quête d’une route entre les systèmes – des filtres rejetant le trafic externe.

iptables-save

La suppression de ces deux filtres devrait permettre à tout le trafic de router entre les deux hôtes.

iptables -t filter -D FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable

iptables -t filter -D FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable

Le ping reçoit désormais une réponse du serveur cible. Regardons également le trafic sur l’interface virbr0 – nous devrions désormais voir le paquet de réponse ICMP.

tcpdump -ni virbr0

Il y a désormais une connectivité complète entre la VM CSA hébergée sur l’ordinateur portable et Helion OpenStack hébergé sur le serveur DL360G7. Tâche suivante – commencer à utiliser CSA pour orchestrer HOS….

52.650156
-2.883185

Originally published on allthingscloud.eu (2015-03-10).