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
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
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?
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.
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.
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.
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.
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. :-)
