Folgende Konstellation: Host Linux Mint 19 mit qemu/kvm, IP@ 192.168.178.101 Virtueller Ubuntu 18.4 Server, IP@ 192.168.122.16 Ich möchte vom Host aus über Port 9000 mit dem Ubuntu Server kommunizieren. Testweise habe ich auf dem Host netcat als Listener gestartet: nc -l 9000 Auf Ubuntu: nc 192.167.178.101 9000 Netcat nimmt Eingaben an, die kommen aber auf dem Host nicht an. Wenn ich für beide Port 9005 angebe, dasselbe Bild. Wenn ich die Rollen von Host und Ubuntu vertausche, funktioniert es auf Port sowohl auf Port 9000, als auch auf 9005. Wie kann man sich das erklären? Was ist da faul?
Uhu U. schrieb: > Wie kann man sich das erklären? Gar nicht, weil kein Mensch weiß, was Du konfiguriert hast. Für mich sehen die IP-Adressen, ich sag mal vorsichtig, "seltsam" aus. Sind die so von Dir beabsichtigt? MfG
Beitrag #6147650 wurde vom Autor gelöscht.
Uhu U. schrieb im Beitrag #6147650: > Rolf M. schrieb: > Wie sieht denn die Netmask jeweils aus? > > 192.168.122.16 netmask 255.255.255.0 > 192.168.178.101 netmask 255.255.255.0 > > Das wars wohl… Die netmask muss für beide 255.255.0.0 sein. > > Aber wie kann es zu der Asymmetrie kommen? Vermutung: * Host bekommt 192.168.178.101 von der Fritzbox * Zusätzlich gibt's ein virtuelles Netzwerk mit 192.168.122.1 für den Host und 192.168.122.16 für die VM * Somit sind beide im 122er Netz und daher funktioniert's mit 192.168.122.16
Beitrag #6147663 wurde vom Autor gelöscht.
Komisch, nu ist die Frage weg, auf die ich antworten wollte. Na, dann in Kurzform: https://help.ubuntu.com/community/KVM/Networking
Rolf M. schrieb: > Wie sieht denn die Netmask jeweils aus? 192.168.122.16 netmask 255.255.255.0 192.168.178.101 netmask 255.255.255.0 Wie muss die netmask aussehen? 255.255.0.0 vermute ich mal. Aber ist 192.168.122.16 eine legale lokale Adresse?
Uhu U. schrieb: > Wie muss die netmask aussehen? 255.255.0.0 vermute ich mal. Richtig, sofern du nicht die Situation hast, die Jan H. beschrieben hat. > Aber ist > 192.168.122.16 eine legale lokale Adresse? Warum sollte sie das nicht sein?
Isoliert betrachtet ist 192.168.0.0/16 vielleicht eine Lösung für die hier gestellte Frage. Ich wäre aber kein Bisschen erstaunt, wenns danach anderswo im Netz mörderisch klemmt. Bei manchen Fragen zu Networking kommt nur dann eine brauchbare Antwort raus, wenn man das ganze Netz betrachtet. So steht 192.168.178.0/24 für die übliche Fritzbox Standard-Konfiguration. Kann man ändern, aber da sollte man schon sehr genau wissen, was man tut, sonst hat man bei Blindflug schnell eine Situation, aus der eine Factory Reset der Fritzbox der schnellste Weg ist. Bei VM Networking hat man zudem Varianten zur Auswahl. Keine Ahnung, wie es bei qemu/kvm ist, aber bei anderen Virtualisierungen gibts Bridging, NATting und isolierte Netze innerhalb der Virtualisierung. Blindes Raten bringt da nicht weiter.
:
Bearbeitet durch User
A. K. schrieb: > Kann man ändern, aber da sollte man schon sehr > genau wissen, was man tut, sonst hat man bei Blindflug schnell einen > Factory Reset der Fritzbox an der Backe. Das ist mein Problem… Laut https://help.ubuntu.com/community/KVM/Networking hat der Host eine weitere IP 192.168.122.1 – das stimmt. Ich kann sie von der VM aus auch anpingen. Aber nc -v 192.168.122.1 9000 von der VM aus teminiert sofort mit connect to 192.168.122.1 port 9000 (tcp) failed: No route to host Ein ssh 192.168.122.1 von der VM aus funktioniert entgegen den Angaben im genannten Link auch nicht.
Quid pro quo. Du beschreibst erst dein Netz und die Netzdefinition der Virtualisierung, und dann gibts vielleicht sinnvolle Antworten. Nicht andersrum. Wenn beispielsweise in der Virtualisierung ein NAT-Netz rumlungert, dann wirds gerne asymmetrisch, d.h. was in eine Richtung geht, geht in die andere noch lange nicht.
:
Bearbeitet durch User
A. K. schrieb: > Wenn beispielsweise in der Virtualisierung ein NAT-Netz rumlungert, dann > wirds gerne asymmetrisch, d.h. was in eine Richtung geht, geht in die > andere noch lange nicht. Ja, 122.0 ist ein NAT-Netz. Man kommt vom Host aus mit sftp, ssh usw. problemlos in den Guest, aber vom Guest aus ist die 122.1 nicht zugreifbar. (Für Forensik-Zwecke ist das natürlich super, aber nicht, wenn man darüber PHP debuggen will…) Jetzt muss ich erst mal rausbekommen, wie man unter qemu/kvm ein gebridgtes Netz aufbaut. Dann sollte es so laufen, wie ich es von VirtualBox gewöhnt bin. (Dort geht das alles kinderleicht, nicht so unter qemu/kvm.)
"gebridgt" brauchst du aber nur, wenn deine VM auch ins physische Netz kommen soll. Man kann auch ein eigenes virtuelles Netz nur zwischen VM und Host einrichten.
Rolf M. schrieb: > Man kann auch ein eigenes virtuelles Netz nur zwischen VM > und Host einrichten. Es wäre schon gut, wenn die VM ohne große Klimmzüge die System-Repositorien erreichen könnte.
Uhu U. schrieb: > Jetzt muss ich erst mal rausbekommen, wie man unter qemu/kvm ein > gebridgtes Netz aufbaut. Dann sollte es so laufen, wie ich es von > VirtualBox gewöhnt bin. (Dort geht das alles kinderleicht, nicht so > unter qemu/kvm.) Da gibts nix gross rauszufinden, nur eine der vielen Möglichkeiten zu nutzen. Z.B. unter libvirt ein Netzwerkeinrichten, z.B.
1 | <network> |
2 | <name>test</name> |
3 | <forward mode='nat'/> |
4 | <bridge name='virbr1' stp='on' delay='0'/> |
5 | <mac address='66:66:66:66:66:66'/> |
6 | <domain name='test'/> |
7 | <ip address='192.168.66.6' netmask='255.255.255.0'> |
8 | <dhcp> |
9 | <range start='192.168.66.66' end='192.168.66.99'/> |
10 | </dhcp> |
11 | </ip> |
12 | </network> |
In der VM dann unter devices
1 | <interface type='network'> |
2 | <mac address='99:99:99:99:99:99'/> |
3 | <source network='test'/> |
4 | <model type='virtio'/> |
5 | <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> |
6 | </interface> |
Fettich. Oder auf dem Host eine Bridge einrichten und ... Oder openvswitch nehmen und darunter eine Bridge einrichten und ... Oder... Gibt sehr viele Möglichkeiten. Die aufgezeigte ist aber meiner Meinung nach die geeignetste für Dich.
Spongebob schrieb: > Da gibts nix gross rauszufinden, nur eine der vielen Möglichkeiten zu > nutzen. > … > Fettich. Mein Problem sind gerade die vielen Möglichkeiten und noch viel mehr "gute Ratschläge" auf dem Web ohne Erklärung, was da eigentlich getrieben wird und zu allen möglichen Umgebungen, die mit meiner nicht all zu viel gemeinsam haben – ich sehe vor lauter Bäumen den Wald nicht. Ich wüßte gerne, was ich da eigentlich tue. > <mac address='99:99:99:99:99:99'/> Irgendwo habe ich gelesen, dass man die MAC auch weglassen kann, qemu würde dann selbst eine generieren. > <bridge name='virbr1' stp='on' delay='0'/> Meinst du damit wirklich die von qemu/kvm bereits angelegte Bridge virbr1, oder hast du da einfach irgendwas hingeschrieben? Kannst du erklären, was dein Vorschlag genau bewirkt? Die Routing Table sieht im Moment so aus:
1 | $ ip route |
2 | default via 192.168.178.1 dev enp5s0 proto dhcp metric 100 |
3 | 169.254.0.0/16 dev enp5s0 scope link metric 1000 |
4 | 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown |
5 | 172.18.0.0/16 dev br-ca218df37e76 proto kernel scope link src 172.18.0.1 |
6 | 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 |
7 | 192.168.178.0/24 dev enp5s0 proto kernel scope link src 192.168.178.101 metric 100 |
8 | 192.168.179.0/24 dev virbr1 proto kernel scope link src 192.168.179.1 linkdown |
9 | 192.168.180.0/24 dev virbr2 proto kernel scope link src 192.168.180.1 |
Deinen Vorschlag habe ich noch nicht eingebaut.
:
Bearbeitet durch User
Uhu U. schrieb: >> <bridge name='virbr1' stp='on' delay='0'/> > > Meinst du damit wirklich die von qemu/kvm bereits angelegte Bridge > virbr1, oder hast du da einfach irgendwas hingeschrieben? Kann sein, daß qemu schon defaultmäßig eine anlegt. Ich lösche die defaults grundsätzlich direkt nach der Installation, daher kann ich das jetzt so nicht sagen. Mein Beispiel ist aber eine von qemu angelegte Bridge - im Gegensatz zu einer auf dem Hostsystem angelegten Bridge. > Kannst du erklären, was dein Vorschlag genau bewirkt? Naja, es wird ein Netzwerk angelegt, welches Du dann mittels qemu/libvirt in den Definitionen der VMs nutzen kannst. Befehl:
1 | virsh net-list |
2 | virsh net-edit default |
Wie sind denn Deine IP Adressen configuriert?
1 | ip a |
John Doe schrieb: > Wie sind denn Deine IP Adressen configuriert? die werde per dhcp bezogen;
1 | $ ip a |
2 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 |
3 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 |
4 | inet 127.0.0.1/8 scope host lo |
5 | valid_lft forever preferred_lft forever |
6 | inet6 ::1/128 scope host |
7 | valid_lft forever preferred_lft forever |
8 | 2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 |
9 | link/ether 00:40:f4:5c:0f:5a brd ff:ff:ff:ff:ff:ff |
10 | inet 192.168.178.101/24 brd 192.168.178.255 scope global dynamic noprefixroute enp5s0 |
11 | valid_lft 851501sec preferred_lft 851501sec |
12 | inet6 fe80::831b:585b:35d4:496a/64 scope link noprefixroute |
13 | valid_lft forever preferred_lft forever |
14 | 3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 |
15 | link/ether 08:60:6e:c1:29:c3 brd ff:ff:ff:ff:ff:ff |
16 | inet6 fe80::bfd6:a13e:fa42:cd5b/64 scope link noprefixroute |
17 | valid_lft forever preferred_lft forever |
18 | 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 |
19 | link/ether 52:54:00:f9:65:68 brd ff:ff:ff:ff:ff:ff |
20 | inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 |
21 | valid_lft forever preferred_lft forever |
22 | 5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 |
23 | link/ether 52:54:00:f9:65:68 brd ff:ff:ff:ff:ff:ff |
24 | 6: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 |
25 | link/ether 52:54:00:f8:e0:36 brd ff:ff:ff:ff:ff:ff |
26 | inet 192.168.180.1/24 brd 192.168.180.255 scope global virbr2 |
27 | valid_lft forever preferred_lft forever |
28 | 7: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr2 state DOWN group default qlen 1000 |
29 | link/ether 52:54:00:f8:e0:36 brd ff:ff:ff:ff:ff:ff |
30 | 8: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 |
31 | link/ether 52:54:00:aa:45:eb brd ff:ff:ff:ff:ff:ff |
32 | inet 192.168.179.1/24 brd 192.168.179.255 scope global virbr1 |
33 | valid_lft forever preferred_lft forever |
34 | 9: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr1 state DOWN group default qlen 1000 |
35 | link/ether 52:54:00:aa:45:eb brd ff:ff:ff:ff:ff:ff |
36 | 10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr2 state UNKNOWN group default qlen 1000 |
37 | link/ether fe:54:00:f8:24:41 brd ff:ff:ff:ff:ff:ff |
38 | inet6 fe80::fc54:ff:fef8:2441/64 scope link |
39 | valid_lft forever preferred_lft forever |
40 | 11: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default |
41 | link/ether 02:42:3d:dc:9c:44 brd ff:ff:ff:ff:ff:ff |
42 | inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 |
43 | valid_lft forever preferred_lft forever |
44 | 12: br-ca218df37e76: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default |
45 | link/ether 02:42:83:1b:8a:3a brd ff:ff:ff:ff:ff:ff |
46 | inet 172.18.0.1/16 brd 172.18.255.255 scope global br-ca218df37e76 |
47 | valid_lft forever preferred_lft forever |
48 | inet6 fe80::42:83ff:fe1b:8a3a/64 scope link |
49 | valid_lft forever preferred_lft forever |
50 | 14: veth79c6329@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ca218df37e76 state UP group default |
51 | link/ether 16:91:df:ca:58:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 0 |
52 | inet6 fe80::1491:dfff:feca:58b6/64 scope link |
53 | valid_lft forever preferred_lft forever |
54 | 16: veth346ee79@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ca218df37e76 state UP group default |
55 | link/ether 76:5d:b9:7d:e1:19 brd ff:ff:ff:ff:ff:ff link-netnsid 2 |
56 | inet6 fe80::745d:b9ff:fe7d:e119/64 scope link |
57 | valid_lft forever preferred_lft forever |
58 | 18: veth4810d27@if17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-ca218df37e76 state UP group default |
59 | link/ether 26:e8:79:75:30:94 brd ff:ff:ff:ff:ff:ff link-netnsid 1 |
60 | inet6 fe80::24e8:79ff:fe75:3094/64 scope link |
61 | valid_lft forever preferred_lft forever |
Ich hätte gerne ein Diagramm der Netzwerke und wie sie untereinander und mit der Hardware verbunden sind. Wo findet man diese Informationen?
:
Bearbeitet durch User
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.