ubuntuusers.de

Hallo, ich kämpfe gerade mit mehreren Themen gleichzeitig und komme einfach nicht weiter.

Ich hab einen Server bei Hetzner mit einem ipv6-Subnetz (a:b:c:d::/64), und mehreren, zusätzlichen Einzel-IPv4-Adressen. Ich virtualisiere auf diesem Host mit KVM und hab die Einzel-IPv4-Adressen bisher direkt über eine Bridge verwendet - so weit so gut. Nun möchte ich verstärkt auf ipv6 umschwenken. Die bereits verwendeten ipv4-Adressen möchte ich wie gehabt weiterverwenden. Für jede einzelne ipv4, die ich bei Hetzner gemietet habe, habe ich auch eine virtuelle MAC anfordern können, die ich bei der Verwendung der Bridge benötige, weil nur Pakete mit diesen MACs oder der MAC des Hosts vom Hetzner-Netz transportiert werden. Für das komplette ipv6-Netz gibts aber keine zusätzlichen MACs, weshalb Hetzner für das ipv6-Subnetz Routing empfiehlt. Die ipv4-Adressen will ich allerdings nicht routen, weil der Host bei deren Nutzung völlig transparent sein soll (auch bei einem traceroute); die bestehende Bridge br0 brauch ich also weiterhin.

Deshalb hab ich versucht, mir von libvirt ein zusätzliches geroutetes Netz (virbr2) an die bereits bestehende Bridge br0 generieren zu lassen (in der Hoffnung, dass alle erforderlichen Routen von libvirt selbst erzeugt werden). Das funktioniert so aber nicht.

Die netplan-Konfig auf dem Host sieht aus wie folgt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      match:
         macaddress: <mac>
      dhcp4: no
      dhcp6: no

  bridges:
    br0:
      macaddress: <mac>
      interfaces: [eno1]
      dhcp4: no
      dhcp6: no
      addresses:
        - <externeipv4>
        - a:b:c:d::2/64
      routes:
        - to: 0.0.0.0/0
          via: <ipv4-gateway>
          on-link: true
#        - to: a:b:c:d::affe/128
#          scope: link
      gateway6: fe80::1
      nameservers:
        addresses:
          <ipv4 und ipv6-nameserver>

virtlib xml's auf dem Host:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

<network connections="1">
  <name>host-bridge</name>
  <forward mode="bridge"/>
  <bridge name="br0"/>
</network>

<network connections="1">
  <name>br_ipv6network</name>
  <forward dev="br0" mode="route">
    <interface dev="br0"/>
  </forward>
  <bridge name="virbr2" stp="on" delay="0"/>
  <mac address="mac2"/>
  <domain name="br_ipv6network"/>
  <ip family="ipv6" address="a:b:c:d::1" prefix="64">
    <dhcp>
      <range start="a:b:c:d::100" end="a:b:c:d::1ff"/>
    </dhcp>
  </ip>
</network>

Ein neuer Test-Gast "affe" soll ausschließlich ipv6 bekommen (seine öffentliche, statische Adresse soll hier mal die a:b:c:d::affe sein).

netplan-Konfig auf "affe":

1
2
3
4
5
6
7
8
9

network:
  ethernets:
    enp1s0:
      addresses:
        - "a:b:c:d::affe/64"
      gateway6: "a:b:c:d::2"
      nameservers:
        <ipv6-nameservers>
  version: 2

Die Bridge funktioniert weiterhin problemlos, aber das Routing Host ←→ affe leider überhaupt nicht.

Der Host kommt über ipv6 raus zu google, kann sich aber selbst auf a:b:c:d::2 nicht anpingen. Zum testaffen kommt er ebenfalls nicht.

affe bekommt neben seiner geplanten, statischen ip die testweise vergebene ipv6 über dhcp und kann sich selbst auch auf beiden Adressen anpingen. Er kommt aber nicht raus (merkwürdigerweise scheint beim ping zumindest die Namensauflösung zu funktionieren) und erreicht auch den Host nicht (address unreachable). Von außen ist er nicht erreichbar (traceroute6 kommt bis zur Host-IP a:b:c:d:e:f:g:h).

Ausgabe von "ip a" auf dem Host:

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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether <mac> brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether <mac> brd ff:ff:ff:ff:ff:ff
    inet <ipv4> scope global br0
       valid_lft forever preferred_lft forever
    inet6 a:b:c:d:e:f:g:h/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 86168sec preferred_lft 14168sec
    inet6 fe80::e:f:g:h/64 scope link 
       valid_lft forever preferred_lft forever
11: virbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether <mac> brd ff:ff:ff:ff:ff:ff
    inet6 a:b:c:d::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::e:f:g:h/64 scope link 
       valid_lft forever preferred_lft forever
12: virbr2-nic: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 1000
    link/ether <mac> brd ff:ff:ff:ff:ff:ff
13: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr2 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:1e:4a:8c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe1e:4a8c/64 scope link 
       valid_lft forever preferred_lft forever

Ausgabe von "ip -6 r" auf dem Host:

::1 dev lo proto kernel metric 256 pref medium
a:b:c:d::/64 dev virbr2 proto kernel metric 256 pref medium
a:b:c:d::/64 dev br0 proto ra metric 1024 expires 85946sec pref medium
fe80::/64 dev br0 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev virbr2 proto kernel metric 256 pref medium
default via fe80::1 dev br0 proto static metric 1024 pref medium

Ausgabe von "ip a" auf affe (gekürzt):

enp1s0: ...
  ...
  inet6 a:b:c:d::170/128 scope global dynamix noprefixroute ...
  inet6 a:b:c:d::affe/64 scope global ...
  inet fe80::5054:ff:g:h/64 scope link... 

Ausgabe von "ip -6 r" auf affe:

::1 dev lo proto kernel metric 256 pref medium
a:b:c:d::/64 dev enp1s0 proto kernel metric 256 pref medium
a:b:c:d::/64 dev enp1s0 proto ra metric 1024 expires 2398sec pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default proto static metric 1024 
        nexthop via a:b:c:d::2 dev enp1s0 weight 1
        nexthop via f80::e:f:fef7:e776 dev enp1s0 weight 1 pref medium

Gebe ich virbr2 dieselbe MAC wie br0 (was doch so sein müsste, oder?), dann kann ich das Netzwerk nur starten, wenn ich vorher auf dem Host manuell net.ipv6.conf.br0.accept_ra auf 2 setze. Dauerhaft über die netplan-Konfig des Hosts scheint das aber nicht zu gehen (zumindest nicht durch ein einfaches accept-ra: 2)

Ich hab inzwischen so viele Konfigs ausprobiert und an so vielen Schrauben gedreht, dass ich grad gar nix mehr verstehe. Kann mir jemand helfen?

Wenn Du die Netzwerke der virtuellen Maschinen mit einer Bridge vereinigen möchtest, spricht nichts dagegen und Du benötigst dann auch kein besonderes Routing. Du musst lediglich jedem Server eine vom Provider akzeptierte eineindeutige MAC-Adresse (genauer: Layer-2-Adresse) geben und kannst jedem Server dann so viele Layer-3-Adressen statisch verpassen, wie es Dir zweckmäßig erscheint. Also z.B. auch eine IPv4-Adresse und eine IPv6-Adresse.

Auf den virtuellen Servern benötigst Du nur für IPv4 und IPv6 jeweils einen Leitweg: „Sende alles an die Bridge.“

Auf dem Host jeweils einen Leitweg: „Sende alles an den Provider.“

Vielen Dank kB , für Deine Antwort. Ich glaub, ich hab mich ungenau ausgedrückt. Ich fasse mein Problem nochmal zusammen:

Die Bridge, die ich bislang verwendet habe, funktionierte für meine VMs mit Einzel-IPs (ipv4) sehr gut, weil ich mir von Hetzner für jede einzelne ipv4-Adresse auch eine MAC-Adresse geben lassen kann. Wenn eine VM eine solche MAC verwendet, werden ihre Pakete nicht von Hetzner verworfen (Hetzner verwirft ansonsten alles, was nicht die MAC des Virtualisierungshosts hat).

Leider bietet Hetzner diese Möglichkeit nicht für ein ipv6-Subnetz an. Wenn ich also eine VM erzeuge, die nur ipv6 verwenden soll, hab ich keine Möglichkeit, mir eine weitere virtuelle MAC geben zu lassen. Und mit irgendeiner MAC werden deren Pakete von Hetzner verworfen. Es nützt also nichts, eine solche VM einfach nur mit der Bridge zu verbinden. Hetzner meint dazu lapidar, dass man dann halt routen muss.

Aber ein geroutetes Netzwerk allein nützt mir auch nichts, weil ich die VMs mit den Einzel-IPs aus Gründen nicht routen möchte.

Also brauch ich eine Mischform. Irgendwie sowas wie "ipv4 über die Bridge, ipv6 geroutet" oder "Bridge für alles und ipv6 hinterher noch geroutet" oder ... Und das ganze mit netplan, was es für mich auch nicht gerade einfacher macht. *Kopf kratz*

Da musst du deinen VMs wahrscheinlich zwei getrennte Netzwerkinterfaces geben, eins für IPv4 (bridged) und eins für IPv6 (routed).

Die Bridge frisst eben immer ein ganzes Netzwerkinterface, da kannst du dann IPv4/IPv6 nicht mehr so einfach trennen. Das Ding hängt komplett in der Bridge oder halt nicht.

Hmmm, ich weiß nicht mal ob sich das Problem dadurch löst... kommt drauf an wie die ankommenden Pakete dann verwurstet werden. Hach, Bridge ist kompliziert, warum nicht einfach alles routen?

@frostschutz: Hm.... Wenn ich ein zweites Interface anlege (kann ich das so einfach machen?) kann ich dem vermutlich nicht dieselbe MAC geben, oder?

Ich bin grad über "ebtables" gestolpert und hab den folgenden Satz dazu gefunden:

"ebtables contains following tables: filter and broute

In 'broute' table we do not do firewalling or filtering as such. broute table (esp. BROUTING chain) is used to indicate whether we use brouting and route the packet or whether we do normal bridging and forward the packet as per L2 destination MAC address. If we ACCEPT the packet in BROUTING chaing then packet is brouted, if we DROP the packet in brouting table the packet is still FORWARDED but it is bridged and not routed. Hence this chain / table is not used for filtering but for indicating whether brouting should be used or not." (https://www.sbarjatiya.com/notes_wiki/index.php/Basic_ebtables_configuration)

Das klingt vielversprechend... ich werd mir das mal näher anschauen und berichten.

Alelix schrieb:

[…] weil ich mir von Hetzner für jede einzelne ipv4-Adresse auch eine MAC-Adresse geben lassen kann. Wenn eine VM eine solche MAC verwendet, werden ihre Pakete nicht von Hetzner verworfen (Hetzner verwirft ansonsten alles, was nicht die MAC des Virtualisierungshosts hat).

Wenn Hetzner tatsächlich Layer-2-Adresse (MAC) mit Layer-3-Adresse (IPv4) gepaart hat, kommst Du tatsächlich mit dem bisherigen Ansatz nicht weiter. Ich vermute aber, es wurden weitere Layer-2-Adressen Dir als Kunden zugeordnet; in diesem Fall kannst Du jeder Dir zugeordneten Layer-2-Adresse mit jeder Dir zugeordneten Layer-3-Adresse kombinieren, also auch Deinen IPv6-Adressen. Prüfe das.

[…] Aber ein geroutetes Netzwerk allein nützt mir auch nichts, weil ich die VMs mit den Einzel-IPs aus Gründen nicht routen möchte.

Die Alternative wäre per NAT auf Layer-2 die MAC-Adressen zu ändern. Ich habe noch niemanden getroffen, der so etwas wirklich im produktiven Betrieb einsetzen möchte.

Also brauch ich eine Mischform.

Oder eine Weiterbildung zu IPv6 und Routing.

[…] mit netplan, was es für mich auch nicht gerade einfacher macht.

Niemand muss Netplan verwenden. Man kann es einfach ignorieren und das Netzwerk mit systemd-networkd konfigurieren.

@kB: Ich kann mir zu jeder einzelnen IPv4-Adresse nur eine virtuelle MAC geben lassen. Leider nicht mehr. Und ja, bei einer VM, die eine solche MAC verwendet, kann ich auch ipv6 gebridged verwenden. Das funktioniert, hab ich aber in der Beschreibung weggelassen, weil es die Beschreibung nur zusätzlich noch mehr verkompliziert hätte und weil es mich letztlich nicht weiterbingt. Denn ich werde in zukünftigen VMs mehr IPv6 Adressen verwenden, als ich Einzel-ipv4-Adressen (und damit virtuelle MAC-Adressen) habe. Und ja, eine Weiterbildung zu Routing (nicht nur bzgl. ipv6, sondern zugegebenermaßen auch ipv4) hätte ich unbedingt nötig, aber wie es halt manchmal so ist, muss ich jetzt erst mal recht schnell eine Lösung finden und im Zuge dessen lernen. Deshalb auch meine Anfrage hier.

Aber vlt. weißt Du ja, wie ich das Routing von ipv6 hinbekommen kann (möglichst ohne den Betrieb der bereits bestehenden (gebridgten) VMs längerfristig zu stören)?