Guten Morgen. Ich habe mir mittels VirtualBox eine Netzwerkumgebung aufgebaut. Pro Knoten habe ich ein Bridge-Interface und eines für die interne Verbindung der einzelnen VMs untereinander. In der Folge können die Gäste ins Netz, sich untereinander verbinden und können mittels SSH vom Host angesprochen werden. Für das jeweilige Bridge Interface werden in der /etc/network/interfaces dynamische IPs über DHCP bezogen. Für das Interface 'Internes Netzwerk' weise ich jeweils statische IPs zu. Was ich verzeifelt versuche, bislang aber nie hinbekommen habe ist eine letzte Form der Verbindung, nämlich von einem Knoten zum Host System. Der Host kann sich mittels SSH mit den Knoten verbinden, aber nicht anders herum. Auch mit den Verbindungsmöglichkeiten 'NAT' und 'Host-only-Adapter' hat es bislang nicht funktioniert. Ich nutze daher bislang eine Netzwerkbrücke, da die restlichen Verbindungsmöglichkeiten so zumindest laufen. In der VirtualBox-Dokumentation finde ich genau zu dem Punkt 'Guest to Host' mittels SSH leider nichts. Auch im Netz habe ich bislang immer nur Infos gefunden, welche die oben bereits beschriebenen Fälle behandeln, aber nicht den noch offenen Fall, vom Gast zum Wirt. Für Hinweise oder Verweise auf Dokumentationsstellen etc., die den gesuchten Fall behandeln, wäre ich echt dankbar. Danke im Voraus.
welche ip hat dien host im jeweiligem netz ? normaler weise geht es, wenn du den default-gateway im netz des gastes benutzt, dass ist ja der host ... route -n
Das ist die Ausgabe von 'route -n'
1 | Ziel Router Genmask Flags Metric Ref Use Iface |
2 | 0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 eth1 |
3 | 10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 |
4 | 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 |
Matthias schrieb: > Das ist die Ausgabe von 'route -n' > Ziel Router Genmask Flags Metric Ref Use Iface > 0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 eth1 > 10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 na dann $> ssh root@10.1.2.1
guest0815 schrieb:
> $> ssh root@10.1.2.1
Dann bekomme ich ein 'ssh: connect to host 10.1.2.1 port 22: No route to
host' zurueck.
An der Ausgabe von 'route -n' sieht man, dass 10.1.2.1 'eth1' zugeordnet
wird. Das ist aber mein Netzwerkadapter für das Interne Netzwerk.
Hast Du mal versucht, Dein internes Netzwerk von „Internal“ auf „Host-Only“ umzustellen? Wenn nicht, versuche das mal und weise dem neuen Interface des Hosts eine statische IP des vormals internen Netzwerkes zu.
1 | 6.7. Host-only networking |
2 | Host-only networking is another networking mode that was added with |
3 | version 2.2 of VirtualBox. It can be thought of as a hybrid between the |
4 | bridged and internal networking modes: as with bridged networking, the |
5 | virtual machines can talk to each other and the host as if they were |
6 | connected through a physical Ethernet switch. Similarly, as with |
7 | internal networking however, a physical networking interface need not be |
8 | present, and the virtual machines cannot talk to the world outside the |
9 | host since they are not connected to a physical networking interface. |
10 | |
11 | Instead, when host-only networking is used, VirtualBox creates a new |
12 | software interface on the host which then appears next to your existing |
13 | network interfaces. In other words, whereas with bridged networking an |
14 | existing physical interface is used to attach virtual machines to, with |
15 | host-only networking a new "loopback" interface is created on the host. |
16 | And whereas with internal networking, the traffic between the virtual |
17 | machines cannot be seen, the traffic on the "loopback" interface on the |
18 | host can be intercepted. |
Matthias schrieb: > Das ist die Ausgabe von 'route -n' > > Ziel Router Genmask Flags Metric Ref Use Iface > 0.0.0.0 10.1.2.1 0.0.0.0 UG 0 0 0 eth1 > 10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 Wenn 10.1.2.0 Dein internes Netz ist dann liegt auch Dein default Gateway 10.1.2.1 im internen Netz. Das kann nicht funktionieren, da ein internes Netz nur VMs untereinander verbindet aber weder Verbindungen zum Host noch irgendwohin sonst hat. Die default Route sollte sicher die IP Deines Routers im physischen Netz sein, wahrscheinlich 192.168.2.1, und es wäre logischer auch sie über DHCP zu beziehen. PS: Ich unterstelle, dass das das route -n vom Gast ist, nicht vom Host, oder?
:
Bearbeitet durch User
@A.H. Du unterstellst richtig. Angesichts dessen, was ich machen möchte, wäre die route -n vom host sinnvoller gewesen. Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.2.1 0.0.0.0 UG 1024 0 0 wlan0 168.257.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
ergänzend Ansprechen lässt sich der Host allerdings nach wie vor nicht.
Matthias schrieb: > Kernel-IP-Routentabelle > Ziel Router Genmask Flags Metric Ref Use Iface > 0.0.0.0 192.168.2.1 0.0.0.0 UG 1024 0 0 wlan0 > 168.257.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 wlan0 > 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 Irgendwie fehlt da der Adapter des Host-only Networks. Der müsste dort im Netzwerk 10.1.2.1/255.255.255.0 auftauchen. Kontrolliere doch mal im VBox Manager unter "File" -> "Preferences" -> "Network" -> "Host-only Networks", ob dort ein entsprechender Adapter konfiguriert ist und wie die Settings sind. Der DHCP Server sollte ausgeschaltet und die Netzwerk-Parameter entsprechend eingestellt sein. Welche Betriebssysteme verwendest Du eigentlich? Und das default Gateway im Gast ist geändert?
Der Adapter als solcher wird nun in der Ausgabe von 'route -n' des Hostsystems angezeigt.
1 | 192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0 |
Das stimmt überein mit den Einstellungen in VirtualBox. Hier wird 192.168.56.1 als IPv4 angezeigt. Identisch mit der Ausgabe von 'ip addr' auf dem Hostsystem. Hier wird besagte IP dem Interface vboxnet0 zugeordnet. Probiere ich nun diese IP von meiner VM aus anzusprechen, erhalte ich die Nachricht 'ssh: connect to host 192.168.56.1 port 22: Network is unreachable'. Mein Host ist ein aktuelles Debian 8.1.0 Jessie.
...Deine Frage nach dem Gateway.
Einmal habe ich alle alten Daten aus der '/etc/network/interfaces' mit
einem # versehen.
In einem zweiten Versuch, habe ich nachfolgenden Eintrag in besagte
Datei geschrieben.
auto vboxnet0
iface vboxnet0 inet static
address 192.168.56.2
netmask 255.255.255.0
gateway 192.168.56.1
network 192.168.56.0
broadcast 192.168.56.255
Matthias schrieb: > Probiere ich nun diese IP von meiner VM aus anzusprechen, erhalte ich > die Nachricht 'ssh: connect to host 192.168.56.1 port 22: Network is > unreachable'. Das wundert mich nicht. Der Host hat ja kein Interface im 10.1.2.0/255.255.255.0-er Netzwerk und der Gast keines in 192.168.56.0/255.255.255.0 und der physische Router wird da nicht helfen. Also ändere doch einfach mal das Netzwerk in VirtualBox auf 10.1.2.0/255.255.255.0 (so muss das oben fälschlicherweise 10.1.2.1/255.255.255.0 genante richtig heißen, eventuall auch mal den Host neu booten) oder ändere die statischen IP-Adressen im Gast auf solche im 192.168.56.0/255.255.255.0-er Netz. Es würde auch helfen, mal die konkreten IP-Adressen mit anzugeben.
Matthias schrieb: > ...Deine Frage nach dem Gateway. > > Einmal habe ich alle alten Daten aus der '/etc/network/interfaces' mit > einem # versehen. > > In einem zweiten Versuch, habe ich nachfolgenden Eintrag in besagte > Datei geschrieben. > > auto vboxnet0 > iface vboxnet0 inet static > address 192.168.56.2 > netmask 255.255.255.0 > gateway 192.168.56.1 > network 192.168.56.0 > broadcast 192.168.56.255 Das Gateway auf dem Host (192.168.2.1 nach der obigen Routing-Tabelle) ist OK, das wird die Adresse Deines physischen Routers sein. Das Gateway 10.1.2.1 im Gast ist das Problem. Das müsste den gleichen Eintrag haben, die gebridgen Interfaces hängen ja alle im selben Netz. Für das vboxnet-Interface auf dem Host würde ich nur IP und Netmask angeben. Network und Broadcast Adresse ergeben sich daraus von alleine und ein Gateway ist für dieses Interface nicht erforderlich. Das wird nur gebraucht wenn Pakete über dieses Netz hinaus in ein oder mehrere weitere Netze geroutet werden sollen und das ist hier sicher nicht gewollt. Dazu gibt es ja das physische Netzwerk.
Das Gateway 10.1.2.1 fällt raus. Dies bezog sich ja auf mein Internes Netzwerk im Rahmen meiner Zweierlösung, bestehend aus einer bridge und einem internen Adapter. In einem früheren Post hast Du den Host-only Adapter vorgeschlagen. Insofern habe ich es jetzt nur noch mit einem Gateway, dem mit der IP 192.168.56.1, zu tun.
PS: Auch in den VMs solltest Du den Interfaces mit den statischen IP-Adressen im internen Netz kein Gateway zuweisen. Das muss sich die VM über DHCP vom Router holen.
Matthias schrieb: > Das Gateway 10.1.2.1 fällt raus. Dies bezog sich ja auf mein Internes > Netzwerk im Rahmen meiner Zweierlösung, bestehend aus einer bridge und > einem internen Adapter. Jetzt bin ich ganz verwirrt. Heißt das, es gibt keine zwei Netzwerke mehr? Bislang bin ich davon ausgegangen, dass jede VM ein gebridgetes Interface hat welches über DHCP konfiguriert wird. Das sollte eigentlich out-of-the-box problemlos in beide Richtungen funktionieren, vorausgesetzt Du kennst die gerade zugewiesenen IP der VM. Warum Du überhaupt ein internes Netzwerk brauchst habe ich mir bisher so erklärt, dass Du statische IP-Adressen zuweisen möchtest ohne in Dein bestehendes Heimnetzwerk einzugreifen. Grundsätzlich geht das, mit einem „Internal“ Netzwerk können aber nur VMs untereinander kommunizieren ohne dabei Verbindung zum Host zu haben. Soll auch der Host eingebunden sein muss ein „Host-only“ Netzwerk verwendet werden. Allen Maschinen in internen Netz (VM oder Host) kannst Du dann statische IP-Adressen ohne Gateway zuweisen, das sollte auch funktionieren. Einfacher fände ich es allerdings, den IP-Range Deines DHCP-Server im bestehenden Heimnetzwerk einzugrenzen und die frei werden Adressen aus diesem Netz den VMs statisch direkt zuzuweisen. Alternativ kannst Du die zuzuweisenden IP-Adressen in Abhängigkeit von den MAC-Adresse auch im DHCP-Server konfigurieren. Dazu müssen allerdings alle VMs unterschiedliche MAC-Adressen haben was beim Klonen manchmal vergessen wird.
Angehängte Dateien:
-
interfaces_vm.png
28 KB -
ip_addr_host.png
11 KB -
ip_addr_vm.png
34 KB -
route_n_host.png
9,5 KB -
route_n_vm.png
19 KB -
VB_Adapter_Settings.png
29 KB -
VB_Adapter_Settings2.png
24 KB
Meine bisherige Konfiguration in Form einer bridge und eines internen Netzwerkadapters sollte den Sinn und Zweck erfüllen, dass die VMs a) über ein Gateway nach draußen telefonieren können (Updates etc) und b) sich dann auch noch via ssh untereinander unterhalten können sollten. c. vom host aus, ebenfalls mittels ssh angesprochen werden können. Soweit lief auch alles. Nur von der VM konnte ich mich nicht mittels ssh auf den Host aufschalten. Wobei mir ssh eigentlich auch gar nicht so wichtig gewesen wäre, vielmehr aber dafür scp, um Dateien einfach hin und her zu senden. Ich habe mal ein paar Bilder gemacht und hänge sie an diesen Thread dran. Was mir jetzt aufgefallen ist, obwohl das Interface im Host 'vboxnet0' korrekt angezeigt wird, ist meine route -n in der vm jetzt leer. Sowohl mit meinen Einträgen in der /etc/network/interfaces, als auch ohne sie, scheint er das Interface als solches in der vm nicht zu erkennen/finden. Wovon ich jetzt kein Bild habe... In VB gibt es nur noch einen Adapter, nämlich einen 'Host-only'
Matthias schrieb: > Meine bisherige Konfiguration in Form einer bridge und eines internen > Netzwerkadapters sollte den Sinn und Zweck erfüllen, dass die VMs > a) über ein Gateway nach draußen telefonieren können (Updates etc) und > b) sich dann auch noch via ssh untereinander unterhalten können sollten. > c. vom host aus, ebenfalls mittels ssh angesprochen werden können. Das sollte alles mit einem gebridgeten Interface ohne Problemem funktionieren. > Nur von der VM konnte ich mich nicht mittels ssh auf den Host > aufschalten. Wenn a) bis c) funktioniert sollte netzwerkseitig auch das keine Probleme machen. Hast Du mal geprüft, ob auf dem Host überhaupt ein ssh-Server läuft? Geht ein Ping?
Was mir an Deinen Screenshots auffällt: Das Gastsystem dürfte kein vboxnet-Interface haben. So heißt der Adapter des Host-only Netzes auf dem Host. Im Gast-OS zeigen sich die Adapter als ganz normale eth-Interfaces. Daher klappt die Konfiguration nicht was auch die fehlenden Einträge in der Routing Tabelle erklärt.
:
Bearbeitet durch User
Folgender Vorschlag: - in VB alle Interfaces der VMs auf „Bridged“ zurückstellen“ - Deine Änderungen in /etc/network/interfaces entfernen und auf DHCP zurückstellen - Wie gesagt, wenn a) bis c) funktionieren sollte auch ssh von der VM zum Host gehen - wenn nicht, erst einmal ssh prüfen, "ssh localhost" auf dem Host wäre ein guter Start - wenn das nicht geht, was ist die Fehlermeldung? Geht ping in der Richtung?
A.H. schrieb: >Hast Du mal geprüft, ob auf dem Host überhaupt ein >ssh-Server läuft? Geht ein Ping? Der Server läuft, ich kann mich ja mittels ssh vom Host auf die VM aufschalten. So, alles wieder zurück auf 'bridge'. route -n sehen gut aus, auf der vm und dem host. Kommunikation zwischen den VMs funktioniert. Ebenso kann ich mich mittels ssh vom host auf die VMs aufschalten. Interface wlan0 192.168.2.101 lässt sich von der VM aus anpingen. Interface vboxnet0 192.168.56.1 lässt sich NICHT anpingen. Eigentlich sollte die IP 192.168.2.101 bidirektional funktionieren, da diese auch verwendet wird, wenn sich der Host auf die vm aufschaltet. -> Ausgabe von wireshark zeigt dies. Frage, wenn ich mich auf eine VM aufschalte, dann so... ssh vm_user@vm_ip Den umgekehrten Fall habe ich bislang in diesen Varianten probiert. ssh host_user@192.168.2.101 -> port 22 connection refused ssh root@192.168.2.101 -> port 22 connection refused ssh host_user@localhost -> permission denied ssh root@localhost -> permission denied Doofe Frage, muss ich, bezogen auf die letzten beiden Einträge, vielleicht einen neuen Usereintrag oder so etwas via addgroup hinzufügen? Port forwarding kann eigentlich nicht das Problem sein, da die Kommunikation ja problemlos aus der anderen Richtung durchkommt. Leider geben etwaige Debugmeldungen seitens ssh keinerlei tiefgründigeren Aufschluss darüber, wo es hakt.
Matthias schrieb: > Der Server läuft, ich kann mich ja mittels ssh vom Host auf die VM > aufschalten. Das heist nur, dass der ssh-Client auf dem Host vorhanden ist, nicht aber, dass auch der Server läuft. > ssh host_user@192.168.2.101 -> port 22 connection refused > ssh root@192.168.2.101 -> port 22 connection refused Das heist ziemlich definitiv, dass kein Server läuft, denn es gibt an Port 22 keinen Prozess, der auf eine Verbindungsanfrage antworten könnte. Die Netzwerkverbindung zum Interface 192.168.2.101 besteht aber, sonst käme etwas wie "no route to host". Du kannst das einfach überprüfen wenn Du Dich mit telnet auf einen anderen bekannten Port verbindest, von dem Du weiß, dass der Service läuft, z.B.
1 | telnet 192.168.2.101 25 # mail server |
2 | telnet 192.168.2.101 80 # web server |
Wenn der Service läuft wirst Du eine Antwort bekommen, wenn nicht, "connection refused" > ssh host_user@localhost -> permission denied > ssh root@localhost -> permission denied Hier läuft der Server, sonst könnte er die Permissions nicht prüfen, er ist aber so konfiguriert, dass er die Verbinung nicht zulässt. Mal in der /etc/ssh/sshd_config nachschauen. Ein Root-Login ist meist mit "PermitRootLogin no" explizit verboten. Warum das User-Login nicht funktioniert kann ich von hieraus nicht sagen, auf meinem Debian System geht's. Also mal prüfen, ob überhaupt ein Paket mit ssh-Server auf dem Host installiert ist. Standardmäßig wird meines Wissens nach nur der Client installiert.
:
Bearbeitet durch User
Die /etc/ssh/sshd_config sehe ich mir als Nächstes an. Hewston, ich habe ein Problem, denn sowohl telnet 192.168.2.101 25, wie auch telnet 192.168.2.101 80 ergeben. connection refused und bei beiden Diensten bin ich mir, genauso wie auch bei ssh, sicher, dass die Dienste laufen.
PS: "ssh localhost" solltest Du mal auf dem Host ausführen. Ich wette, auch dort kommt „connection refused“
Du hast Recht. Frage, heißt das, dass ich nur einen ssh 'SERVER' nachinstallieren muss???
sudo apt-get install openssh-SERVER Oh Mann... Ich schäme mich gerade in Grund und Boden!
Matthias schrieb: > Ich schäme mich gerade in Grund und Boden! Na na, dazu gibt es ja nun keinen Grund. Ganz im Gegenteil, solche Erlebnisse sind die schönsten Momente der Erkenntnis. :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.