SSHing zu meinem XCP-ng-Server stellt eine Verbindung zu Hypervisor und nicht zu VM her, auch wenn separate IPs verwendet werden

620
James Stone

Ich habe einen alten HP ProLiant DL385 G5p-Server, den ich früher nur als verherrlichtes NAS verwendet habe, aber jetzt möchte ich etwas mehr daran machen, beispielsweise einen DNS-Caching-Server für mein Netzwerk einrichten.

Ich möchte in der Lage sein, meinen Dateiserver und den DNS (und alles andere, woran ich denken kann) auf separaten virtuellen Maschinen über den XCP-ng-Hypervisor auszuführen.

Ich hatte in den letzten Tagen damit angefangen, das einzurichten, zwei meiner Debian-VMs in Betrieb zu nehmen, und es gelang mir sogar, mein Caching-DNS zum Laufen zu bringen. Mein Problem trat jedoch auf, als ich versuchte, mich über SSH mit der Debian-VM zu verbinden, die ich für meinen Dateiserver verwenden wollte. Ich habe die IP-Adresse dieser VM in PuTTY eingegeben (ich hatte zwei Ethernet-Verbindungen zum Server; eine für den Dateiserver und eine für alles andere), und die Verbindung war einwandfrei - mit dem Hypervisor. Das ist das Problem und ich bin wirklich nicht sicher, was hier vor sich geht. Wie mache ich PuTTY und daher das SFTP-Laufwerk, das ich für die Dateiübertragung auf meinen Haupt-PC verwenden werde, eine Verbindung zur VM und nicht zum Hypervisor herzustellen?

Einer meiner Freunde erwähnt, dass ich kann die Portweiterleitung auf dem Hypervisor verwenden zu können, in sie SSH und ich habe in dieser aussehen, aber nichts gefunden, das, wie es scheint, würde helfen, obwohl ich nicht 100% sicher bin, was Ich suche.

Ich habe XCP-ng seitdem erneut installiert und das Caching-DNS und einen Tor-Relay-Knoten für eine Ethernet-Verbindung eingerichtet, muss aber noch eine weitere Debian-Installation für den Dateiserver erstellen.

Danke im Voraus.

Bearbeiten: Dies ist die Ausgabe, die ich bekomme, wenn ich routemit dem Hypervisor laufe :

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default gateway 0.0.0.0 UG 0 0 0 xenbr0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr0

Und das ist die VM-Ausgabe:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.0.1 0.0.0.0 UG 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

Hoffe das kann von Nutzen sein.

Bearbeiten (1): Dies ist die Ausgabe, die route -nauf dem Hypervisor ausgeführt wird:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 xenbr0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 xenbr0

0

2 Antworten auf die Frage

0
Marcelo Roberto Jimenez

Wir müssen das Netzwerkmodell verstehen, das Sie im Hypervisor verwenden.

Wenn die VMs in demselben IP-Netzwerk wie der Hypervisor ausgeführt werden, dh der Hypervisor kein IP-Netzwerkrouting durchführt, ist keine Portweiterleitung erforderlich.

Dies ist jedoch nicht die häufigste Situation. Wenn Sie VMs einrichten, bewahren Sie sie normalerweise in einem separaten Netzwerk auf und verwenden eine Art Portweiterleitung für den Hypervisor, um die Sicherheit ein wenig zu verbessern, indem Sie die Anzahl der freigegebenen Maschinen minimieren.

Daher müssen Sie höchstwahrscheinlich eine Portweiterleitungsregel einrichten iptables, um beispielsweise Port 2022 in der IP des Hypervisors auf Port 22 der VM abzubilden.

Nehmen Sie im folgenden Beispiel an, dass Ihr Hypervisor ein Subnetz 192.168.1.0 mit der Netzmaske 255.255.255.0 (24 Bit, Klasse C) einrichtet. Nehmen Sie außerdem an, dass Ihre VM die Adresse 192.168.1.2 hat. Wenn Sie auf dem Hypervisor eine ordnungsgemäß eingerichtete Firewall eingerichtet haben, die standardmäßig alle Verbindungen ablehnt, sollten die folgenden beiden Zeilen die Aufgabe ausführen:

$ iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 2022 -j DNAT --to 192.168.1.2:22 $ iptables -A FORWARD -p tcp -d 192.168.1.2 --dport 22 -j ACCEPT 

Verweise:

[1] https://www.systutorials.com/816/port-forwarding-using-iptables/

Ehrlich gesagt habe ich keine Ahnung, was der Hypervisor tut. Wie in der Frage erwähnt, schlug einer meiner Freunde vor, dass ich Port-Forwarding machen müsste, um auf die VM zugreifen zu können brauche die "iptables" Route. Wenn dies der Fall ist, füge ich den obigen Code mit meinen IP-Adressen in die Hypervisor-Shell ein? Muss ich ein VLAN einrichten? Ich habe dieses Netzwerk noch nicht eingerichtet, entschuldigen Sie bitte mein mangelndes Wissen. Vielen Dank. James Stone vor 5 Jahren 0
Sie können diese Befehle einfach ausprobieren, indem Sie die IP-Adresse Ihrer VM ersetzen und prüfen, ob sie funktioniert. Es würde jedoch sicherlich sehr hilfreich sein, wenn Sie einige Details zur Netzwerkkonfiguration veröffentlichen und darauf achten, dass keine echte IP-Adresse verfügbar ist. Die Ausgabe des Befehls "route" sollte ein guter Ausgangspunkt sein. Marcelo Roberto Jimenez vor 5 Jahren 0
Ich mache eine Bearbeitung und füge ein, was der Hypervisor beim Ausführen von "route" ausgibt. James Stone vor 5 Jahren 0
Machen Sie dasselbe für die VM. Marcelo Roberto Jimenez vor 5 Jahren 0
Das ist alles zu der Frage hinzugefügt worden, ich hoffe es ist, wonach Sie suchen. James Stone vor 5 Jahren 0
Sieht aus, als befänden sie sich in demselben Netzwerk (192.168.0.0). Sind sie nicht vertauscht, Hypervisor und VM? Ich denke, VM sollte die xenbr1-Schnittstelle haben und der Hypervisor sollte eth1 haben. Führen Sie auf dem Computer mit der Schnittstelle xenbr1 auf jeden Fall eine Route -n aus, um sicherzustellen, dass sich die IP-Adresse von 192.168.0.1 unterscheidet. Wenn Sie unterschiedliche IP-Adressen in demselben Netzwerk haben und SSH für eine IP-Adresse verwenden können, können Sie höchstwahrscheinlich SSH für die andere IP-Adresse verwenden. Wenn die IPs jedoch gleich sind, liegt ein Konfigurationsproblem vor. Übrigens sind in einer solchen Konfiguration die beiden Zeilen, die ich in meiner Antwort gepostet habe, nicht nützlich. Marcelo Roberto Jimenez vor 5 Jahren 0
Der Hypervisor ist definitiv derjenige, der die `xenbr0`-Schnittstelle ausgibt, also werde ich` route -n` ausführen. James Stone vor 5 Jahren 0
0
James Stone

Okay, also nachdem ich Marcelo viel versucht hatte, meine Frage zu beantworten, habe ich herausgefunden, was das Problem war, warum ich keine Verbindung zu meiner VM herstellen konnte.

Spoiler: Es ist peinlich einfach.

Um es kurz zu machen: Ich habe einen Weg gefunden, die IP-Adresse zu überprüfen, die dem Ethernet-Port zugewiesen wurde, den ich verwenden wollte. Dies ip a show eth1wäre eine praktische Sache gewesen.

Es stellt sich heraus, dass der Hypervisor aus irgendeinem Grund etwas Kompliziertes getan hat. Selbst wenn ich die IP-Adresse /etc/network/interfacesals statisch definiere, entschied ich mich für eine andere. Sobald ich die IP-Adresse wusste, konnte sie ohne Probleme in die VM einsteigen.