[gelöst] Schnittstellen-Traffic-Probleme

[TomL]

Moin

Angeregt durch diesen Thread und mit dem Hintergedanken, dass mich genau dieses Problem vor einigen Wochen auch schon mal beschäftigt hat (erfolglos), versuch ich jetzt doch noch mal ne Lösung zu finden... vielleicht klappt das ja mit etwas Hilfe....

Ich habe meinem PC eine Bridge verpasst und dafür gesorgt, dass alles im gleichen Netzwerk abläuft. Die Idee war, die VM soll als regulärer LAN-Client mit eigener LAN-IP im Netz adressiert werden können. Mit dem macvtap-Device klappt das wie gewünscht, aber mit der Einschränkung, dass keine direkte Kommunikation zwischen Host und VM möglich ist. Jetzt hatte ich die Idee, das mit einer tun/tap-Bridge nachzubilden, ohne NAT... klappt aber nicht.

So sieht das im Überblick aus... und dann auch mit dem Nachweis, dass Ping-Pakete tatsächlich auch ankommen. Aber anscheinend verschwinden die TCP-Pakete in irgendein Loch, es gibt nämlich keinen Response.

Code: Alles auswählen

Netzwerk            :   172.100.1/24
Default-GW          :   172.100.1.1
PC       (thomaspc) :   172.100.1.20
└─> Bridge          :   172.100.1.200
└─> VM   (virtpc)   :   172.100.1.207

root@virtpc:~
# ping 172.100.1.1 -c 1 -w 1
    PING 172.100.1.1 (172.100.1.1) 56(84) bytes of data.
    --- 172.100.1.1 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms

    # ping 172.100.1.20 -c 1 -w 1
    PING 172.100.1.20 (172.100.1.20) 56(84) bytes of data.
    --- 172.100.1.20 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms

    # ping 172.100.1.200 -c 1 -w 1
    PING 172.100.1.200 (172.100.1.200) 56(84) bytes of data.
    --- 172.100.1.200 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms


root@thomaspc:~
# ip r s
    default via 172.100.1.1 dev enp2s0 
    172.100.1.0/24 dev enp2s0 proto kernel scope link src 172.100.1.20 
    172.100.1.0/24 dev br0 proto kernel scope link src 172.100.1.200 

# tcpdump -n -i br0
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
    16:14:05.071090 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28
    16:14:06.086028 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28
    16:14:07.110002 ARP, Request who-has 172.100.1.1 tell 172.100.1.207, length 28

    16:14:13.464864 IP 172.100.1.207 > 172.100.1.20: ICMP echo request, id 901, seq 1, length 64
    16:14:18.566080 ARP, Request who-has 172.100.1.20 tell 172.100.1.207, length 28
    16:14:18.566107 ARP, Reply 172.100.1.20 is-at 52:54:00:9d:e9:4a, length 28

    16:14:20.361278 IP 172.100.1.207 > 172.100.1.200: ICMP echo request, id 902, seq 1, length 64
    16:14:25.478115 ARP, Request who-has 172.100.1.200 tell 172.100.1.207, length 28
    16:14:25.478144 ARP, Reply 172.100.1.200 is-at 52:54:00:9d:e9:4a, length 28

# ping 172.100.1.207 -c 1 -w 1
    PING 172.100.1.207 (172.100.1.207) 56(84) bytes of data.
    --- 172.100.1.207 ping statistics ---
    1 packets transmitted, 0 received, 100% packet loss, time 0ms

Mein Problem ist, ich weiss nicht, ob dieses Modell grundsätzlich 'ne Unmöglichkeit ist oder ob ich hier nur was vergessen oder missachtet habe. Die Interpretation dieser Antwort-Erklärung ist leider auch ne Nummer zu hoch für mich.

[novalix]

Hi Thomas,

eine Lösung könnte sein, noch einmal einen Schritt zurück zu gehen und auf dem Host an Stelle eines macvtab ein macvlan device als zentralen Knotenpunkt einzurichten.

A quick workaround is to create a macvlan (not macvtap) interface on the host, which will then be visible from the guests.

[jessie]

https://unix.stackexchange.com/question ... host-model

[TomL]

@novalix

Danke für den Link... ich habe mich jetzt gut 2 Stunden damit befasst... leider erfolglos. Wie Willi das schon an anderer Stelle gesagt hat, und ich kanns nur bestätigen, es zieht sich durch die ganze Materie, die Dokumentation dazu ist schlichtweg sch***e.

Ich habe die Versuche jetzt nach diesem Fundstück im Link abgebrochen. Es scheint so zu sein, dass auch mit macvlan die Host <-> Guest-Kommunikation nicht möglich ist. Siehe Zitat in http://hicu.be/bridge-vs-macvlan
"Mavlan sub-interfaces are not able to directly communicate with the parent interface, i.e. VMs cannot directly communicate with the host. If you require VM-host communication, you should add another macvlan sub-interface and assign it to the host."

Wenn ich also hierbei auch 2 virtuelle Interfaces einrichten muss, isses m.E.n. ja nicht grundsätzlich eine Verbesserung im Vergleich zu macvtap, weil ich da ja für die isolated Bridge ebenso ein 2. NIC benötige. Eine echte Verbesserung wärs natürlich, wenn mit macvlan die IP im LAN in alle Richtungen konsistent wäre... aber ohne Tutorial-Material oder Beispiele ist das für mich unlösbar.

@Jessie
Der Link betrachtet Layer 3.... soviel habe ich mittlerweile verstanden, das ist hier leider aber nicht das Problem, oder anders gesagt, das ist eigentlich gelöst... nur auf der Ebene Layer 2 ist es das noch nicht.....

[habakug]

Hallo,

bist du denn das Debian-Wiki schon durchgegangen?

Gruss, habakug

[1] https://wiki.debian.org/KVM#Manual_bridging
[2] https://wiki.debian.org/QEMU#Host_and_g ... me_network
[3] https://wiki.debian.org/BridgeNetworkConnections --> "Libvirt and bridging"

[dufty2]

Zu macvlan, macvtap, etc. kann ich nichts sagen,
aber falls das physikalische Interface eine IP hat, dann darf die Bridge selbst keine haben
und umgekehrt.

[TomL]

Zu macvlan, macvtap, etc. kann ich nichts sagen,....

Ok, dann nehme ich das mal zum Anlass zu versuchen, den Sachverhalt etwas besser zu beschreiben... so wie ich das bisher verstanden habe.

bist du denn das Debian-Wiki schon durchgegangen?

Ja, sicher, und nicht nur diese Beiträge..... sondern auch quer durchs Netz

Ums vorweg zu nehmen.... eine normale Bridge, wie sie dort überall beschrieben steht, war bisher gar nicht das Problem. Eine Bridge zu erstellen, um 2 Subnetze zu verbinden ist eigentlich relativ easy. Das Manko an allen Beiträgen im Web zur Erstellung von Bridges ist, dass sie alle immer nur den gleichen traditonell alten (und imho überholten) Kram wiederholen... sie bauen auf die /etc/network/interfaces auf und verwenden brctl aus dem Paket bridge-utils. Das Problem ist hier, dass ich gar keine Programme nutze, die die /etc/network/interfaces und deren Einstellungen lesen, ebensowenig benötige ich das Paket bridge-utils. Ich customize das Netz via iproute2-Tools manuell und direkt und verwende dazu einfache systemd-service-Units. Ich brauche keinen Networkmanager, kein ifupdown, das funktioniert via service-units direkt und dadurch bestens nachvollziehbar und phänomenal einfach. Was ist die Besonderheit an 2 Subnetzen, 1 x das reale und 1 x das der VM? Nix besonderes, es sind einfach nur 2 unterschiedliche /24-Subnets, die via Bridge verbunden sind. Das funktioniert gut und ist einfach einzurichten.

Nun das macvtap-Device. Damit ist die VM nicht mehr nur VM, sondern durch die Verwendung des macvtap-Devices wird sie zur Simulation einer physischen Hardware. Das bedeutet, sie wird direkt Client meines DSL-Routers, der sie via DHCP und RA bedient und der gar nicht weiss, dass das gar keine physische Hardware ist. Total spannend ist auch die Erkenntnis, dass ich im oberen Beispiel Layer-3-Möglichkeiten mit Routen und Packetfiltering habe, aber mit macvtap nicht... das läuft rein auf Layer-2 ab... was wiederum bedeutet, auf dem physischen Host, als Gastgeber für die VM, kann ich noch nicht mal die Pakete der VM filtern... die gehen an den Netfilter-Kernelmodulen auf Layer 2 schlichtweg dran vorbei. Und es ist genau diese Situation, die mir durch Nachbildung via tun/tap-Bridge nicht gelingt. Und deswegen hatte ich ja auch im Eingangsposting im Letzten Satz infrage gestellt, ob das nicht vielleicht sogar eine Unmöglichkeit ist, weil macvtap eben nicht nur eine Bridge-tap-Device-Kombi ist, sondern eben noch irgendwas anderes, womit das, was es tut, funktioniert.

[bluestar]

Ich habe meinem PC eine Bridge verpasst und dafür gesorgt, dass alles im gleichen Netzwerk abläuft. Die Idee war, die VM soll als regulärer LAN-Client mit eigener LAN-IP im Netz adressiert werden können. Mit dem macvtap-Device klappt das wie gewünscht, aber mit der Einschränkung, dass keine direkte Kommunikation zwischen Host und VM möglich ist.

Magst du vielleicht mal kundtun, wie du dein macvtap Device angelegt hast?

[TomL]

Magst du vielleicht mal kundtun, wie du dein macvtap Device angelegt hast?

Das ist die manuelle Methode...vorher 'ne MAC per Random-Gen erzeugen.

Code: Alles auswählen

virsh edit vmname
    <interface type='direct'>
      <mac address='52:54:00:f9:aa:bb'/>
      <source dev='macvtap0' mode='bridge'/>
      <model type='virtio'/>
    </interface>

ip link add link enp2s0 macvtap0 address 52:54:00:f9:aa:bb type macvtap mode bridge
ip link set macvtap0 up
ip link show macvtap0

virsh start vmname && virt-viewer vmname

ip link set macvtap0 down
ip link del macvtap0

Oder via KVM-Netzwerk-Conf.... hier UUID und MAC per Random-Gen erzeugen.

Code: Alles auswählen

nano /etc/libvirt/qemu/networks/lanbridge.xml                          # Inhalt siehe unterhalb
virsh net-create /etc/libvirt/qemu/networks/lanbridge.xml

virsh net-edit lanbridge
    <network>
      <name>lanbridge</name>
      <uuid>4244554567-4466-4568f9-9cabcbc-f645643453</uuid>         
      <forward dev='enp2s0' mode='bridge'>                      
        <interface dev='enp2s0'/>
      </forward>
    </network>

virsh edit vmname                                               
    <interface type='network'>
      <mac address='52:54:00:9d:ee:ff'/>
      <source network='lanbridge'/>
      <model type='virtio'/>
    </interface>

virsh net-start lanbridge
virsh start vmname && virt-viewer vmname
virsh net-destroy lanbridge