How-to: Routing zwischen einem virtualisierten CSA-Server und einer virtualisierten HOS-Installation

2015-03-10

Machine-translated — the English original is authoritative.

Viele von Ihnen, die Networking-Experten, mögen den Bedarf für einen solchen Beitrag nicht verstehen. Als jemand, der neu in OpenStack und Networking ist, war dieser Prozess für mich nicht klar.

Das folgende Diagramm veranschaulicht die Konfiguration, die ich verwendet habe – Auf einem Windows 7-Laptop habe ich VMware Workstation 10 ausgeführt, und darin hatte ich eine in sich geschlossene Cloud Service Automation (CSA)-VM. Das Netzwerk dieser VM war mit der Schnittstelle meines Laptops gebrückt, wodurch diese VM eine DHCP-Adresse in meinem lokalen Netzwerk 192.168.1.0/24 erhalten konnte. Das zweite System, das ich verwendet habe, war ein DL360G7, der Ubuntu 14.04 als Gastbetriebssystem hatte, ebenfalls an das 192.168.1.0/24-Netzwerk angeschlossen. Dieser DL360G7 war Host einer virtuellen Installation von Helion OpenStack v1.1 [dieser Installationsprozess kann in diesem früheren Beitrag gefunden werden].

Schritt 1

Offensichtlich muss auf dem CSA Windows 2k8 Server-Host eine Route zu den API-Endpunkten des HOS-Dienstes bestehen, den ich nutzen möchte, die sich in einem 192.0.2.0/24-Netzwerk befinden. Diese existiert standardmäßig nicht, was beim Betrachten der Host-Routingtabelle unten ersichtlich ist.

netstat -rn

Ein schneller Ping von der CSA-Server zu einem der HOS-Hosts bestätigt ebenfalls das Routing-Problem.

ping 192.0.2.2 /t

Das 192.0.2.0/24-Netzwerk ist auf dem DL360G7 virtualisiert und kann nur remote über die physische Schnittstelle auf dem DL360G7 erreicht werden, die eine IP-Adresse von 192.168.1.13 hat. Dies wird als Gateway-Adresse bezeichnet.

Öffnen Sie ein Eingabeaufforderungsfenster auf dem CSA-Server: Start -> Ausführen -> cmd
Geben Sie eine Route zum HOS-Netzwerk mit dem folgenden Befehl ein:

route add -p 192.0.2.0 mask 255.255.255.0 192.168.1.13

Die Netzwerk-Routen auf dem CSA-Host sollten jetzt ungefähr so aussehen (wir kümmern uns nur um die neue Hinzufügung von 192.0.2.0 – es ist wahrscheinlich, dass es auf Ihrem System viele andere Routen geben könnte).

netstat -rn

Wenn Sie jetzt einen Server im 192.0.2.0/24-Netzwerk pingen, sollten Sie eine Antwort vom DL360G7-Host-Server sehen. Keine Panik! – Ja, es funktioniert immer noch nicht, aber zumindest können Sie sehen, dass der richtige Host jetzt auf Ihre Anfrage antwortet.

ping 192.0.2.2 /t

Jetzt ist es an der Zeit, zum DL360G7 Ubuntu-Host-Server zu wechseln. Lassen Sie den Ping auf dem CSA-Host-Server [verwenden Sie die Option /t] weiterlaufen.

Schritt 2

Wenn wir uns die Host-Schnittstelle jetzt auf dem DL360G7 HOS-Host-Server ansehen, können wir sehen, dass die Ping-Anfrage eingeht, jedoch keine Antwort erhalten wird.

tcpdump -ni em1 icmp

Die Routing-Tabellen auf dem Ubuntu-Server zeigen an, wo als Nächstes gesucht werden muss.

netstat -rn

Der gesamte Verkehr für das 192.0.2.0/24-Netzwerk wird über die Schnittstelle virbr0 geroutet.
Untersuchen Sie die Ausgabe auf dieser virbr0-Schnittstelle, um zu sehen, was mit dem Verkehr passiert.

tcpdump -c 10 -ni virbr0

Es gibt keine Anzeichen dafür, dass Ping-Anfragen vom CSA-Host 192.168.1.12 so weit kommen.
Das Problem liegt also zwischen der em1-Schnittstelle und der virbr0-virtuellen Schnittstelle – was befindet sich zwischen diesen Schnittstellen? Iptables! auch bekannt als Host-Firewall.
Ein kurzer Blick auf die Iptables auf dem DL360G7 Ubuntu-Host offenbart die letzte Hürde auf dem Weg zu einer Route zwischen den Systemen – Filter, die den externen Verkehr ablehnen.

iptables-save

Das Löschen dieser beiden Filter sollte allen Traffic erlauben, zwischen den beiden Hosts zu routen.

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

Ping erhält jetzt eine Antwort vom Zielserver. Schauen wir uns auch den Verkehr auf der virbr0-Schnittstelle an – wir sollten jetzt das ICMP-Antwortpaket sehen.

tcpdump -ni virbr0

Es besteht jetzt volle Konnektivität zwischen der auf dem Laptop gehosteten CSA-VM und dem auf dem DL360G7-Server gehosteten Helion OpenStack. Nächste Aufgabe – CSA zu starten, um HOS zu orchestrieren….

52.650156
-2.883185

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