[gelöst] Privacy Extension blockt WWW

[TomL]

Und weil es wie Du schreibst eine nicht-produktive Test-VM ist, verstehe ich deine Sorgen bzgl. Kollateral-Auswirkungen nicht ganz.

Das war schlichtweg ein Missverständnis. Ich hatte das fälschlicherweise als Einstellung auf dem Server interpretiert, nicht in der VM.

Meinst Du den mtr? Wenn ja, dann kann man den doch installieren:

Mit net.ipv6.conf.enp1s0.use_tempaddr=2:

Code: Alles auswählen

# mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000
Start: 2019-09-21T14:26:36+0200
HOST: testsystem                  Loss%   Snt   Last   Avg  Best  Wrst StDev
root@testsystem:~

Mit net.ipv6.conf.enp1s0.use_tempaddr=1:
(Bei Kontrolle mit ping -6 auf ein lokales Gerät wird die MAC-Based IPv6 verwendet)

Code: Alles auswählen

# mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000
Start: 2019-09-21T14:33:30+0200
HOST: testsystem                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:72b8:1722:5433:228:6  0.0%     1    2.4   2.4   2.4   2.4   0.0
  2.|-- ???                        0.0%     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 2001:1438:0:1::2:151       0.0%     1  218.7 218.7 218.7 218.7   0.0
  4.|-- ???                        0.0%     1    0.0   0.0   0.0   0.0   0.0
mtr: No route to host
root@testsystem:~

Mit net.ipv6.conf.enp1s0.use_tempaddr=0:

Code: Alles auswählen

# mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000
Start: 2019-09-21T14:38:14+0200
HOST: testsystem                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:72b8:1722:5433:228:6  0.0%     1    1.7   1.7   1.7   1.7   0.0
  2.|-- 2001:1438::62:214:63:85    0.0%     1   20.2  20.2  20.2  20.2   0.0
  3.|-- 2001:1438:0:1::2:151       0.0%     1   18.9  18.9  18.9  18.9   0.0
  4.|-- 2001:1438:0:1::4:2102      0.0%     1   35.6  35.6  35.6  35.6   0.0
  5.|-- 2001:7f8::3012:0:2         0.0%     1   30.0  30.0  30.0  30.0   0.0
  6.|-- 2a02:2e0:11:16::1          0.0%     1   24.9  24.9  24.9  24.9   0.0
  7.|-- 2a02:2e0:10:4::1           0.0%     1   27.5  27.5  27.5  27.5   0.0
  8.|-- 2a02:2e0:12:32::2          0.0%     1   27.2  27.2  27.2  27.2   0.0
  9.|-- 2a02:2e0:3fe:0:c::1        0.0%     1   30.0  30.0  30.0  30.0   0.0
 10.|-- 2a02:2e0:3fe:1001:302::    0.0%     1   26.7  26.7  26.7  26.7   0.0
root@testsystem:~

Wenn ja, dann geht es doch auch darum festzustellen, wie die PE-IPv6 geblockt wird. Werden die ausgehenden Datenpakete für diese source-PE-IPv6 erst gar nicht produziert oder produziert und nicht gesendet oder gesendet und irgendwo unterwegs geblockt?

Ja, das ist die Kernfrage. Ich bin nur jetzt im Moment ein bisschen so eingestellt, erst mal auf die Antwort von den libvirt-Fachleuten zu warten. Es hilft m.M.n. nix, jetzt unzählige Versuche erfolglos zu probieren, um dann am Montag (oder so) zu erfahren "nee, das ist so gewollt und korrektes Verhalten... aus den und den Gründen". Wenn von dort allerdings der Hinweis kommt "das muss funktionieren", dann ist für mich ein Grund gegeben, dass intensiver zu untersuchen.

Frage: Sind in der VM, die "MAC-Based GUA (2000::/3)" und die "second GUA (PE-Based)" gleichzeitig vorhanden bzw. konfiguriert? Wenn ja, wie ist es wenn nur die "second GUA (PE-Based)" in der VM vorhanden ist bzw. benutzt wird?

Interessante Frage... ich habs gerade mal versucht. Outbound ist die VM dann mit V6 tot ... ich habs dann ohne weiteres nachsehen abgebrochen.

[mat6937]

Mit net.ipv6.conf.enp1s0.use_tempaddr=2:

Code: Alles auswählen

# mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000
Start: 2019-09-21T14:26:36+0200
HOST: testsystem                  Loss%   Snt   Last   Avg  Best  Wrst StDev
root@testsystem:~

Mit net.ipv6.conf.enp1s0.use_tempaddr=1:
(Bei Kontrolle mit ping -6 auf ein lokales Gerät wird die MAC-Based IPv6 verwendet)

Code: Alles auswählen

# mtr -6nr --tcp -P 443 -c 1 2a02:02e0:03fe:1001:0302:0000:0000:0000
Start: 2019-09-21T14:33:30+0200
HOST: testsystem                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:72b8:1722:5433:228:6  0.0%     1    2.4   2.4   2.4   2.4   0.0
  2.|-- ???                        0.0%     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 2001:1438:0:1::2:151       0.0%     1  218.7 218.7 218.7 218.7   0.0
  4.|-- ???                        0.0%     1    0.0   0.0   0.0   0.0   0.0
mtr: No route to host
root@testsystem:~

Versuch mal den traceroute mit mtr auch unter Verwendung der PE-IPv6-Adresse als source-IP.
Mit:

Code: Alles auswählen

net.ipv6.conf.enp1s0.use_tempaddr=2

und mit

Code: Alles auswählen

net.ipv6.conf.enp1s0.use_tempaddr=1

Z. B.:

Code: Alles auswählen

mtr -6nr --tcp -P 443 -c 1 -a <source-PE-IPv6-Adresse-von-enp1s0> 2a02:02e0:03fe:1001:0302:0000:0000:0000

[schorsch_76]

Ich hab jetzt meiner br0 mein eth0 gegeben und im Container damit eine ipv4 und v6 von der FritzBox. Mit und ohne PE funktioniert das alles...

[TomL]

Danke für den Hinweis.

Allerdings habe ich schon so ein bisschen damit gerechnet.... meiner Meinung nach war das für den LXC-Container zu erwarten. Das hat früher mit Virtual Box ja ebenfalls bestens funktioniert, und das wird vermutlich auch mit Qemu funktionieren. Es gibt da nur ein paar -meiner Einschätzung nach relevante- Unterschiede.

Virtualbox und LXC sind keine echte Virtualisierung, sondern nach meinem Verständnis nur emulierte Virtualisierung, die quasi als normale Anwendungen im Betriebssystem laufen, und das vermutlich mit entsprechend höherer Last. Qemu ist im Vergleich dazu schon eine Steigerung und ein Typ-2-Hypervisor, allerdings auch im Userland laufend und als solcher ebenfalls nur eine gehostete Virtualisierung, die allerdings direkt auf die Hardware zugreift.

KVM ist als Linux-Kernelmodul ein Type-1-Hypervisor, der native und direkt auf der Hardware aufsetzt. Und ich glaube, dass das der Grund dafür ist, warum mir das momentan soviel Kopfzerbrechen bereitet.

Nun ja, die Frage bleibt, warum habe ich überhaupt von Virtual Box nach KVM gewechselt, wenn doch VB über Jahre richtig gut gelaufen hat? Zum einen der Umstand, dass VB nicht Debian ist, was mich schon länger gestört hat. Und zum zweiten hat Virtual Box mit zwei VMs zuletzt im Idle-Mode eine permanente Last von 5-7% auf der CPU verursacht, ohne jeglichen Nutzen. Heute mit vier KVM's, die auch noch mehr tun, liegt die Last regelmäßig zwischen 0 und 0,7% mit Spitzen bei 2% im Idle-Mode. Ich fand das also schon beachtenswert, und zwar vor dem Hintergrund, dass das bei mir ganzjährig rund-um-die-Uhr läuft. LXC-Container kenne ich nicht, aber ich vermute (oder befürchte), dass die Emulation durchaus auch hohe Last erzeugt... und das 4 Container meine Toleranz übersteigen würden. Ganz zum Schluss gabs also auch die Überlegung, dass als Beitrag zum Stromsparen zu sehen ... nach dem Motto, dass ganz viel Kleinvieh irgendwann nen vollen Grill ergibt...

Aber wie gesagt, diese Entscheidung beschäftigt mich jetzt eine Woche.

[schorsch_76]

LXC ist im Prinzip nichts anderes als ein chroot mit cgroup Abschottung [3]. Du nutzt den gleichen Kernel wie der Host. Die Container werden mit Kernel namespaces und cgroups getrennt.

VirtualBox und KVM emuliert einen ganzen PC. Der Gast hat eine eigene CPU. Das wird mit Hardwarevirtualisierung (VT oder AMD-V) [1][2] getrennt. Demzufolge hat eine VM einen höheren Overhead als ein Container. Ohne AMD-V oder VT nutzt du halt Qemu. Das stellt per Software alles bereit (ist aber langsamer aka. mehr OVerhead).

Mit KVM nutzt du praktisch den gleichen Netzaufbau wie ich mit dem Container. auch hier wird der VM oder dem Container ein Netzwerkdevice gegeben das auf dem Host meist in einer Bridge steckt.

[1] https://de.wikipedia.org/wiki/Kernel-ba ... al_Machine
[2] https://de.wikipedia.org/wiki/VirtualBox
[3] https://de.wikipedia.org/wiki/LXC

Die Kernel-based Virtual Machine (KVM; deutsch „Betriebssystem-Kern-basierte virtuelle Maschine“) ist eine Infrastruktur des Linux-Kernels zur Virtualisierung, die auf mit den Hardware-Virtualisierungstechniken von Intel (VT) oder AMD (AMD-V) ausgestatteten X86-Prozessoren sowie auf der System-z-Architektur lauffähig ist.

Die Virtualisierungserweiterungen der aktuellen Intel-CPUs mit der Bezeichnung VT-x und dessen AMD-Pendant AMD-V werden, sofern vorhanden, genutzt. Hierbei werden auch neuere Funktionen dieser Befehlssatzerweiterungen wie Nested Paging/Rapid Virtualization Indexing unterstützt.

LXC stellt eine erweiterte chroot-Umgebung zur Verfügung und lässt sich insofern mit FreeBSD-Jails und Linux-VServer vergleichen.

[TomL]

Da ist einiges, was ich anders verstanden habe.... was dann schließlich zu meiner Entscheidung geführt hat, Virtual Box abzulösen und sowohl Docker- als auch LXC-Container konsequent auszuschließen . Aber das ist hier nicht das Thema und und hilft auch nicht bei der Lösung meines Problems, insofern hab ich auch kein großes Interesse daran, mehr über LXC zu erfahren... sorry....

[schorsch_76]

Jetzt hab ich noch eine Debian VM mit KVM/libvirt installiert. Das nutzt auch mein br0 um Netz zu bekommen.

Wie erwartet geht hier auch mit und ohne PE das Netzwerk. WWW hab ich jeweils mit

Code: Alles auswählen

wget -6 google.de -O -

getestet.

[schorsch_76]

Versuch doch mal mit tcpdump oder wireshark zu lauschen was bei dir passiert wenn du mit IPv6+PE versuchst per WWW was zu laden oder lesen.

[TomL]

Jetzt hab ich noch eine Debian VM mit KVM/libvirt installiert. Das nutzt auch mein br0 um Netz zu bekommen.
Wie erwartet geht hier auch mit und ohne PE das Netzwerk. WWW hab ich jeweils mit

Code: Alles auswählen

wget -6 google.de -O -

getestet.

Daran hab ich jedoch großes Interesse. Verräts Du mir bitte die Bridge-Konfiguration auf dem Host? Ich war vor einiger Zeit mit der traditionellen Bridge-Konfiguration nicht hartnäckig genug, ums damit ans Laufen zu bringen.... das klappte zunächst mal nicht, mit dem macvtap-Device hingegen sofort. Und damit war ich dann leider zu vorschnell zufrieden.

[schorsch_76]

Code: Alles auswählen

auto br0
allow-hotplug br0

iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_waitport 0
        bridge_fd 0 

[TomL]

Das war jetzt der entscheidende Hinweis... mit einer 'normalen' Bridge funktioniert es auch mit den PE.

Allerdings habe ich jetzt das gleiche Problem, wie damals, ich weiss nicht, wie man die Bridge einrichtet deswegen habe ich ja auch bis heute das macvtap-Device genutz, was relativ einfach zu handhaben war. Also, ich krieg die bridge eingerichtet, sie funktioniert auch sofort, wie es soll, die VM rennt geradezu perfekt... nur klaut sie dann dem Host das Netzwerk. Mit gestarteter VM frisst sich der Host beispielsweise bei Zugriffen auf entfernte Samba-Laufwerke fest. Sobald ich die VM schließe und die Bridge entferne, läuft es auf dem Host wieder normal. Aber die spannende Erkenntnis ist, mit macvtap-Device funktionieren die PE nicht, mit Bridge-Device hingegen schon.

Jetzt ist nur noch die Frage, wie erstellt man mit iproute-Kommandos eine funktionierende Bridge? Mit der folgenden Kommando-Kette rennt die VM wie'n döppken, aber der Host humpelt:

Code: Alles auswählen

ip link add br0 type bridge; \
ip link set enp2s0 master br0; \
ip link set br0 address 52:54:00:aa:bb:cc; \
ip link set br0 up

Sobald die bridge wieder entfernt ist, rennt auch wieder der Host:

Code: Alles auswählen

ip link del br0 type bridge

[schorsch_76]

Du solltest fd auf 0 setzen und auch STP aus machen.

https://wiki.debian.org/BridgeNetworkConnections

Some other useful options to use in any stanza in a virtualised environment are:
bridge_stp off # disable Spanning Tree Protocol
bridge_waitport 0 # no delay before a port becomes available
bridge_fd 0 # no forwarding delay
bridge_ports none # if you do not want to bind to any ports
bridge_ports regex eth* # use a regular expression to define ports

[TomL]

Du solltest fd auf 0 setzen und auch STP aus machen.

Ja, habe ich jetzt berücksichtigt. Ich habe die Bridge jetzt wie folgt erstellt:

Code: Alles auswählen

sysctl -w net.ipv4.ip_forward=1; \
sysctl -w net.ipv4.ip_forward=1; \
sysctl -w net.ipv6.conf.all.forwarding=1; \
ip link add br0 type bridge; \
ip link set br0 address 52:54:00:9b:f1:89; \
ip link set br0 type bridge stp_state 0; \
ip link set br0 type bridge forward_delay 0; \
ip link set enp2s0 master br0; \
ip link set br0 up

Damit funktioniert die VM perfekt, aber der Host ist vom Netz abgehängt....

Mir ist jetzt hier u.a. unklar, ob br0 selber IP-Adressen haben muss. Ich meine mal gelesen zu haben, dass die Bridge keine eigene IPs haben darf. Und das zweite ist, ich glaube mich zu erinnern, dass eine solche Bridge immer auch ein Tap-Device haben muss. Wie ist das bei Dir mit dem KVM-Setup? Hat die Bridge eigene IPs und gibts da noch ein Tap-Device...?... also BEVOR die VM gestartet wird... denn die generiert ja auch noch ein virtuelles Device.

[schorsch_76]

Hallo Thomas,

bei mir hat das br0 die IP Adresse(n). Die Member haben keine Adressen. Die br0 hat auch keine MAC. Das br0 repräsentiert bei mir die Verbindung zu diesem Netz aus dem Host raus. eth0 ist der physikalische Link zu dem Netz zur FritzBox. Wenn eine Bridge kein Device hat, nutze ich halt "bridge_ports none" beim Setup der Bridge. SIe muss kein tab haben.

Das tap Device wird automatisch von libvirt erstellt und zerstört beim Start der VM. Es wird auch automatisch der br0 hinzugefügt und entfernt. eth0 ist bei mir schon von Systemstart an in der Bridge. Sonst erst mal nichts.

Eine brX ohne IP und ohne Device nutze ich, um ein Netz zwischen VMs zu realisieren die der Host nicht wissen muss/soll. Er hat keine IP, also auch keinerlei Routing. libvirt/lxc erstellt das veth/tap Device und stellt das in die jeweilige Bridge. Damit können die Layer 2 Frames zwischen den Membern ausgetauscht werden.

[unitra]

Die Bridge selbst sollte eine IP Adresse haben, und alle anderen "physischen Schntistellen" die sich der Bridge bedienen sollten in diese "bridge group" hinzugefügt werden. Eine Anleitung ist hier zu finden.

* https://wiki.archlinux.org/index.php/Ne ... h_iproute2

Zur MAC Adresse, der Bridge sollte keine MAC Adresse manuell vergeben werden, also entweder automatische MAC Adresse, oder wenn man denn unbedingt eine MAC Adresse konfigurieren möchte dann darf die NICHT GLEICH der MAC Adresse der eth0 oder der wlan0 Schnittstelle sein. Ansonsten kommen die Ethernet Frames nicht bei der richtigen MAC Adresse an, oder es gibt ein merkwürdiges Verhalten, dass Ethernetframes nicht ankommen da wo sie sollen.

Die Empfehlung wäre die bridge nur mittels iproute2 tool zu konfigurieren.
Eventuell fehlt noch ein:

Code: Alles auswählen

ip link set eth0 up

wenn eth0 bereits der Bridge hinzgefügt wurde. Danach muss es klappen.

...Mir ist jetzt hier u.a. unklar, ob br0 selber IP-Adressen haben muss. ...

[TomL]

@unitra

Danke für den Tip.... und ich habs mir angesehen. Ich bin der Meinung, dass das absolut identisch zu meiner Vorgehensweise ist. Lediglich mit der Bridge-IP und der MAC ist noch unklar. Von alleine zieht br0 keine IPv4, und via SLAAC wird keine gebildet. Und die MAC ist ohne Angabe einfach nur 00:00:00:00:00:00, deswegen habe ich ihre eine Unique-MAC manuell verpasst.

Aber Fakt ist.... mit diesen Statements funktioniert die Bridge ja, auch ohne IPs, die VM hat Netzzugang, IPv6 (SLAAC und PE) funktionieren fehlerfrei, seitens der VM ist geradezu alles perfekt.

Code: Alles auswählen

# ip link add br0 type bridge; \
> ip link set br0 address 52:54:00:9b:aa:aa; \
> ip link set br0 type bridge stp_state 0; \
> ip link set br0 type bridge forward_delay 0; \
> ip link set br0 up

# ip link set enp2s0 master br0

Nur ist mit dem letzten Statement von oberhalb unmittelbar der PC selber vom Netz 'abgehängt'... die VM läuft perfekt, der Host-PC hat aber kein Netz mehr. Erst mit ersten der folgenden Statement hat der PC wieder das Netz verfügbar, aber dann ist die VM abgehängt:

Code: Alles auswählen

# ip link set enp2s0 nomaster; \
> ip link set br0 down; ip link del br0 type bridge

Und weil das offensichtlich bei Schorsch funktioniert, muss hier also noch ein Fehler vorliegen... die Frage ist nur, wo?

[schorsch_76]

Ich starte die br0 immer über /etc/network/interfaces.d/br0. Vielleicht ist es ja das?

[TomL]

Ich starte die br0 immer über /etc/network/interfaces.d/br0. Vielleicht ist es ja das?

Das ist möglich.... ich kanns nur nicht bestätigen, weil es hier keine solche Datei gibt. Ist das ein ausführbares Script? Wo hast Du das runtergeladen?

[schorsch_76]

Code: Alles auswählen

man interfaces

[TomL]

*lol* ... ich hatte gehofft, Du hättest die Ironie der Frage verstanden.... deswegen hatte ich das "ich starte" auch markiert. Ich weiss, was das Verzeichnis tut bzw. welchen Zweck es hat, aber ich weiss nicht, was Du dort eingetragen hast, damit es das tut, was Du möchtest, das es das tut ... und genau das findet man leider auch nicht in der Man-Page.

BTW, ich nutze weder networking.service, noch /etc/init.d/networking, noch ifup@.service, noch den networkmanager..... insofern könnte ich da auch Kochrezepte speichern, würde auch nix kaputt machen. Ich versuche den ganzen Kram ja komplett auf iproute2-Ebene mit den richtigen Statements zu verwirklichen ... um darüber dann am Ende auch die Zusammenhänge besser zu verstehen. Durch Deine Hinweise z.B. auf stp-state und forward-delay habe ich auch dazugelernt. Und fakt ist, alle die gennanten Tools machen auch nix anderes... also muss es gehen... und ich versuch mich da halt mühsam hinzuarbeiten. Also wie gesagt, hilfreich wäre es zu wissen, wie die Bridge parametrisiert wurde und wie das Interface in der $VM.xml eingestellt ist. Vielleicht habe ich dabei einen Fehler gemacht.

[schorsch_76]

Code: Alles auswählen

georg@M4700:~$ sudo cat /etc/network/interfaces.d/br0
[sudo] Passwort für georg: 
auto br0
allow-hotplug br0

iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_waitport 0
        bridge_fd 0 
        
georg@M4700:~$ sudo cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
georg@M4700:~$ 

So erstelle ich die VM bzw binde an das Netzwerk

Code: Alles auswählen

virsh # dumpxml --domain debian-vm
<domain type='kvm'>
  <name>debian-vm</name>
  <uuid>b517882c-e856-4d16-8602-5d5c710d49d0</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://debian.org/debian/9"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/georg/vm/rootfs.qcow2'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='sda' bus='sata'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:c0:d3:a1'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Code: Alles auswählen

georg@M4700:~/vm$ sudo ip link 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether e0:db:55:ea:52:3f brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether e0:db:55:ea:52:3f brd ff:ff:ff:ff:ff:ff

Code: Alles auswählen

georg@M4700:~/vm$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether e0:db:55:ea:52:3f brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e0:db:55:ea:52:3f brd ff:ff:ff:ff:ff:ff
    inet 192.168.160.48/24 brd 192.168.160.255 scope global dynamic br0
       valid_lft 850798sec preferred_lft 850798sec
    inet6 2003:d8:2706:6000:e2db:55ff:feea:523f/64 scope global dynamic mngtmpaddr 
       valid_lft 7036sec preferred_lft 1048sec
    inet6 fe80::e2db:55ff:feea:523f/64 scope link 
       valid_lft forever preferred_lft forever

Code: Alles auswählen

georg@M4700:~/vm$ sudo brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.e0db55ea523f       no              eth0

[TomL]

Mein libber schorsch_76,

als ich heute morgen meinen Rechner eingeschaltet habe, hatte ich den festen Vorsatz, diesen Tread als "[unlösbar abgehakt]" zu markieren und den Sch**ß zu vergessen. Unlösbar vor dem Hintergrund, dass ich hinsichtlich Netzwerk eben kein normales Debian-Setup habe, sondern einen Weg abseits des normalen gehe. Bei mir gibts eben keinen dhcpcd5, networkmanager, ifup, /etc/interfaces, networkd. Ich habe das alles als unerwünschte Bloatware deklariert und deinstalliert. Stattdessen konfiguriere ich das Netzwerk komplett manuell via iproute2-Statements. Und eben alles das, wofür man 1000 Anleitungen im Web findet, ist hier nicht wirklich hilfreich. Mit den Beispiel-Einträgen aus der /etc/network/interfaces ist so gut wie kaum was anzufangen, weil nicht daraus hervorgeht, welches Programm was in welcher Reihenfolge wann damit anstellt.

Es sind halt nur Parameter, die zwar Rückschlüsse auf die Wirkung zu lassen, aber nicht wie diese Wirkung zustande kommt und welches Programm dafür verantwortlich ist. Der networkmanager oder ifup oder bridgectl verwenden diese Parameter, aber sie verbergen, was sie damit tun. Und genau deswegen will ich diese Bloatware nicht ... ich will lieber wissen wie es in der Tiefe funktioniert.

Tja.. und heute morgen sehe ich Dein Posting.... auf einmal wars klar und dann auch ganz einfach.... .... das hat den Knoten gelöst....

Also, das ist die Lösung, die ich Dank Schorsch's Posting gefunden habe, mit der das Netzwerk allgemein und eine Bridge für meine Libvirt-VM's funktioniert, und alles korrekt mit IPv4 (NAT), IPv6 (PE + MAC) als reguläre LAN-Clients. Das Netzwerk ist nach dem Systemstart unkonfiguriert, keine offenen Verbindungen, keine Interface-UPs, keine laufenden Netzwerk-Dienste. Für das phys. NIC ist IPv6 disabled:

Code: Alles auswählen

ip a
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
        valid_lft forever preferred_lft forever
        inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
    2: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
        link/ether 52:54:00:9b:aa:aa brd ff:ff:ff:ff:ff:ff

cat sysctl-ipv6-tpc.conf | grep enp2s0
    net.ipv6.conf.enp2s0.disable_ipv6=1
    net.ipv6.conf.enp2s0.forwarding=0
    net.ipv6.conf.enp2s0.autoconf=0
    net.ipv6.conf.enp2s0.use_tempaddr=0
    net.ipv6.conf.enp2s0.accept_ra=0

Mit den folgenden iproute2-Kommandos die Bridge erstellen und das Netzwerk starten. Achtung, die HW-Adresse der Bridge muss identisch sein, mit der des phys. NICs (s.o.) sein. Dieses Setup ist ein DHCP-Setup.

Code: Alles auswählen

ip link add br0 type bridge; \
ip link set br0 type bridge stp_state 0; \
ip link set br0 type bridge forward_delay 0; \
ip link set br0 address 52:54:00:9b:aa:aa; \
sysctl -w net.ipv4.ip_forward=1; \
sysctl -w net.ipv6.conf.all.forwarding=1; \
sysctl -w net.ipv6.conf.br0.forwarding=1; \
sysctl -w net.ipv6.conf.br0.disable_ipv6=0; \
sysctl -w net.ipv6.conf.br0.autoconf=1; \
sysctl -w net.ipv6.conf.br0.use_tempaddr=2; \
sysctl -w net.ipv6.conf.br0.accept_ra=2; \
ip link set enp2s0 master br0; \
ip link set enp2s0 up; \
ip link set br0 up; \
dhclient -v br0

Bei einen Static-IP-Setup kann unterhalb der Hardware-Adresse Statement 1 eingefügt werden und die dhclient-Zeile durch Statement 2 ausgetauscht werden (LAN = 172.100.1/24, Standard-GW = 172.100.1.1):

Code: Alles auswählen

ip addr add 172.100.1.2/24 dev br0
ip route add default via 172.100.1.1

Der Vorteil hierbei ist, mit diesem obigen Kommandopaket, was ich alles in eine einzige Service-Unit packe, spare ich mir alle sonstigen für den Netzwerkbetrieb eingesetzten Tools. Das finde ich natürlich richtig gut...

Noch mal Danke an mat6937 und schorsch_76, ohne euch hätte ich das Problem nicht lösen können.