[GELÖST] IPv6-IPs auf KVM-Host zu den VMs routen

[Kaheto]

Hi,

ich habe eine Frage bezüglich IPv6 bei KVM und KVM-Gästen. Ich habe auf einem Root-Server (Debian 10) mehrere VMs laufen. Die externen Ipv4-Adressen der einzelnen VMs liegen auf der Bridge "vmbr0" und werden über NAT an die internen IPv4-Adressen (192.168.1.0/24) geforwardet. Mittlerweile habe ich jeder VM eine IPv6-Adresse aus dem von Hetzner zur Verfügung gestellten IPv6-64er Subnetz konfiguriert.
Die interfaces auf dem KVM-Host liest sich so:

Code: Alles auswählen

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp0s31f6
iface enp0s31f6 inet manual

# External network, Bridge definitions
auto vmbr0
iface vmbr0 inet static
        bridge-ports enp0s31f6
        bridge_stp off       # disable Spanning Tree Protocol
        bridge_waitport 0    # no delay before a port becomes available
        bridge_fd 0          # no forwarding delay
        label_addresses yes
        address 87.56.85.85
        pointopoint 87.56.85.65
        gateway 87.56.85.65
        up ip addr add 194.8.125.241/32 dev vmbr0
        down ip addr delete 194.8.125.241/32 dev vmbr0
        post-up ip route add 194.8.125.242/32 via 87.56.85.85 table srvnet
        post-up ip rule add from 194.8.125.241/32 table srvnet
        post-up ip rule add to 194.8.125.241/32 table srvnet
        up ip addr add 194.8.125.242/32 dev vmbr0
        down ip addr delete 194.8.125.242/32 dev vmbr0
        post-up ip rule add from 194.8.125.242/32 table srvnet
        post-up ip rule add to 194.8.125.242/32 table srvnet
        up ip addr add 194.8.125.243/32 dev vmbr0
        down ip addr delete 194.8.125.243/32 dev vmbr0
        post-up ip rule add from 194.8.125.243/32 table srvnet
        post-up ip rule add to 194.8.125.243/32 table srvnet
        up ip addr add 194.8.125.244/32 dev vmbr0
        down ip addr delete 194.8.125.244/32 dev vmbr0
        post-up ip rule add from 194.8.125.244/32 table srvnet
        post-up ip rule add to 194.8.125.244/32 table srvnet
        up ip addr add 194.8.125.245/32 dev vmbr0
        down ip addr delete 194.8.125.245/32 dev vmbr0
        post-up ip rule add from 194.8.125.245/32 table srvnet
        post-up ip rule add to 194.8.125.245/32 table srvnet
        up ip addr add 194.8.125.246/32 dev vmbr0
        down ip addr delete 194.8.125.246/32 dev vmbr0
        post-up ip rule add from 194.8.125.246/32 table srvnet
        post-up ip rule add to 194.8.125.246/32 table srvnet                                                                      
        dns-nameservers 213.133.100.100 213.133.98.98 9.9.9.9


# IPv6 configuration
iface vmbr0 inet6 static
        address 2a03:587:140:6268::2
        netmask 64
        gateway fe80::1

und

Code: Alles auswählen

# ip a show

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: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP group default qlen 1000
    link/ether 90:1b:0e:ab:a6:0c brd ff:ff:ff:ff:ff:ff
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 90:1b:0e:ab:a6:0c brd ff:ff:ff:ff:ff:ff
    inet 87.56.85.85 peer 87.56.85.65/32 brd 78.255.255.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.241/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.242/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.243/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.244/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.245/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet 194.8.125.246/32 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2a03:587:140:6268::2/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::921b:eff:feab:a60c/64 scope link 
       valid_lft forever preferred_lft forever
4: virbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:54:00:ff:13:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global virbr1
       valid_lft forever preferred_lft forever
5: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr1 state DOWN group default qlen 1000
    link/ether 52:54:00:ff:13:5f brd ff:ff:ff:ff:ff:ff
6: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:38:a9:16 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe38:a916/64 scope link 
       valid_lft forever preferred_lft forever
7: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:41:75:ad brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe41:75ad/64 scope link 
       valid_lft forever preferred_lft forever
8: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:6c:e7:8f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe6c:e78f/64 scope link 
       valid_lft forever preferred_lft forever
9: vnet3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:ba:83:d8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:feba:83d8/64 scope link 
       valid_lft forever preferred_lft forever
10: vnet4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:f0:16:94 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fef0:1694/64 scope link 
       valid_lft forever preferred_lft forever
11: vnet5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:4c:b2:c8 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe4c:b2c8/64 scope link 
       valid_lft forever preferred_lft forever
12: vnet6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:de:fb:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fede:fbd4/64 scope link 
       valid_lft forever preferred_lft forever

Wie gehe ich jetzt vor, wenn ich die IPv6-Adressen von dem Host zu den VMs routen will? Wäre das analog zu den bisherigen Einträgen?
Für nur IPv6-Adressen:

Code: Alles auswählen

up ip addr add 2a03:587:140:6268::241/64 dev vmbr0
down ip addr delete  2a03:587:140:6268::241/64 dev vmbr0
post-up ip route add  2a03:587:140:6268::241/64 via 87.56.85.85 table srvnet
post-up ip rule add from  2a03:587:140:6268::241/64 table srvnet
post-up ip rule add to  2a03:587:140:6268::241/64 table srvnet

Für IPv4- und IPv6-Adressen:

Code: Alles auswählen

up ip addr add 2a03:587:140:6268::241/64 dev vmbr0
up ip addr add 194.8.125.241/32 dev vmbr0
down ip addr delete  2a03:587:140:6268::241/64 dev vmbr0
down ip addr delete 194.8.125.241/32 dev vmbr0
post-up ip route add  2a03:587:140:6268::241/64 via 87.56.85.85 table srvnet
post-up ip route add 194.8.125.241/32 via 2a03:587:140:6268::2 table srvnet
post-up ip rule add from  2a03:587:140:6268::241/64 table srvnet
post-up ip rule add from 194.8.125.241/32 table srvnet
post-up ip rule add to  2a03:587:140:6268::241/64 table srvnet
post-up ip rule add to 194.8.125.241/32 table srvnet

Oder muss ich auf die virtuellen "vnetX"-Interfaces routen?

Vielen Dank
Kaheto

[Kaheto]

Meine libvirt-Netzwerk-Datei sieht so aus:

Code: Alles auswählen

<network ipv6='yes'>
  <name>network1</name>
  <uuid>d09113dd-070c-4be1-965e-99fb4aa7ce23</uuid>
  <forward dev='vmbr0' mode='nat'>
    <interface dev='vmbr0'/>
  </forward>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:e9:e5:92'/>
  <domain name='example.tld'/>
  <ip address='192.168.1.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.1.128' end='192.168.1.254'/>
    </dhcp>
  </ip>
  <ip family='ipv6' address='2a03:587:140:6268::1' prefix='64'>
    <dhcp>
      <range start='2a03:587:140:6268::100' end='2a03:587:140:6268::1ff'/>
    </dhcp>
  </ip>
</network>

[Kaheto]

Da oben habe ich einen Denkfehler gemacht. Und wenn ich stattdessen für eine IPv6-Adresse

Code: Alles auswählen

ip -6 route add 2a03:587:140:6268::24 dev virbr1

mache, dann kann ich vom KVM-Host diese VM anpingen

Code: Alles auswählen

# ping6 2a03:587:140:6268::24
PING 2a03:587:140:6268::24(2a03:587:140:6268::24) 56 data bytes
64 bytes from 2a03:587:140:6268::24: icmp_seq=1 ttl=64 time=0.307 ms
64 bytes from 2a03:587:140:6268::24: icmp_seq=2 ttl=64 time=0.338 ms

Auf der entsprechenden VM geht der Ping nicht raus

Code: Alles auswählen

# ping6 2a03:587:140:6268::2
PING 2a03:587:140:6268::2(2a03:587:140:6268::2) 56 data bytes
From 2a03:587:140:6268::24: icmp_seq=1 Destination unreachable: Address unreachable

obwohl die Route auf den KVM-Host zeigt:

Code: Alles auswählen

# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via 2a03:587:140:6268::2 dev enp1s0 metric 1024 onlink pref medium

[Kaheto]

Von Hetzner habe ich diese Information erhalten

Die öffentlichen IPv6 Netze werden im Root Bereich auf die local-link Adresse Ihres Servers geroutet, damit Sie das gesamte Netz auch nutzen können. Wir filtern hier nichts, für das Netz erwarten wir aber die Hardware MAC des Servers. Dies ist fest auf dem Router als ndp Zuweisung hinterlegt.

Dann habe ich diesen Artikel gefunden https://kofler.info/kvm-host-mit-ubuntu-einrichten/, unter "MAC-Ärger" wird der Vorschlag gemacht, die internen MAC-Adressen aller weitergeleiteten Pakete mit ebtables einfach zu überschreiben:

Code: Alles auswählen

ebtables -t nat -A POSTROUTING -j snat --to-src MAC-Host

Das habe ich auch durchgeführt, nur dass sich die Routing-Situation nicht geändert hat.

[unitra]

Die Konfiguration des IP Routings mit Linux macht man mit tool "iproute2". MAC Adressen und ebtables --snat haben dem Konfigurieren von IP Routing nichts zu tun. MAC Adressen sind unwichtig im Internet und Router verwerfen diese oder schreiben Sie um, diese Information geht prinzipiell verloren.

Geroutet wird auf IP Ebene (IPv4/IPv6)

Um ein IPv6 Packet weiter zu Routen benötigt man erst einmal das Netz das man routen möchte (hier 2001:0DB8::/32) und das Ziel (hier FE80::1). Alle Angaben sind nur für den lokalen Host. Hier ein Beispiel eine ip route Anweisung für IPv6, man beachte die -6 Option

Code: Alles auswählen

ip -6 route add 2001:0DB8::/32 via fe80::1

Mit der obigen Anweisung, routet die lokale Maschine, lokal das Netz 2001:0DB8::/32 über die lokale Schnittstelle FE80::1.

Von Hetzner habe ich diese Information erhalten

Die öffentlichen IPv6 Netze werden im Root Bereich auf die local-link Adresse Ihres Servers geroutet, damit Sie das gesamte Netz auch nutzen können. Wir filtern hier nichts, für das Netz erwarten wir aber die Hardware MAC des Servers. Dies ist fest auf dem Router als ndp Zuweisung hinterlegt.

Dann habe ich diesen Artikel gefunden https://kofler.info/kvm-host-mit-ubuntu-einrichten/, unter "MAC-Ärger" wird der Vorschlag gemacht, die internen MAC-Adressen aller weitergeleiteten Pakete mit ebtables einfach zu überschreiben:

Code: Alles auswählen

ebtables -t nat -A POSTROUTING -j snat --to-src MAC-Host

Das habe ich auch durchgeführt, nur dass sich die Routing-Situation nicht geändert hat.

[Kaheto]

Die Konfiguration des IP Routings mit Linux macht man mit tool "iproute2". MAC Adressen und ebtables --snat haben dem Konfigurieren von IP Routing nichts zu tun. MAC Adressen sind unwichtig im Internet und Router verwerfen diese oder schreiben Sie um, diese Information geht prinzipiell verloren.

Geroutet wird auf IP Ebene (IPv4/IPv6)

Um ein IPv6 Packet weiter zu Routen benötigt man erst einmal das Netz das man routen möchte (hier 2001:0DB8::/32) und das Ziel (hier FE80::1). Alle Angaben sind nur für den lokalen Host. Hier ein Beispiel eine ip route Anweisung für IPv6, man beachte die -6 Option

Code: Alles auswählen

ip -6 route add 2001:0DB8::/32 via fe80::1

Mit der obigen Anweisung, routet die lokale Maschine, lokal das Netz 2001:0DB8::/32 über die lokale Schnittstelle FE80::1.

Also das funktioniert schon gar nicht, denn "fe80::1" ist das IPv6-Gateway von Hetzner und ich müsste an die Schnittstelle des VM-Gast hier enp1s0 routen

Code: Alles auswählen

2a03:587:140:6268::/64 via 2a03:587:140:6268::::1 dev enp1s0 metric 1024 pref medium

Ich habe auf meinen KVM-Host eine Bridge (vmbr0) bislang konfiguriert, an der alle zusätzlichen IP-Adressen angehängt sind. Via NAT werden dann diese IPv4-Adressen auf die jeweiligen IPv4-Adressen intern genatet die im Netzwerk 192.168.1.0 liegen und über die von libvirt Schnittstelle virbr1 erreichbar sind. Das funktioniert und die MAC-Adressen der VMs stören nicht das Hetzner-Netzwerk, das nur die MAC-Adresse des Root-Servers gestattet.

Dasselbe Problem hatte eben auch der Herr Kofler für IPv4 aufgezeigt und eben die Maskierung der MAC mit ebtables vorgeschlagen. Bei mir hatte das aber nicht geklappt.

[Kaheto]

Ich stelle jetzt generell die Frage. Wie lässt sich bei Hetzner, wo nur die MAC des Servers akzeptiert wird und nicht die MAC einer VM, die aber sichtbar würde, wenn die VM eine IP aus dem Subnet 2a03:587:140:6268::/64 besitzt?

Hetzner schlägt folgende https://community.hetzner.com/tutorials ... figuration Konfiguration vor. Ich habe das auf dem Rootserver versucht umzusetzen. Dabei habe ich für KVM und libvirt das Netzwerk so angepasst:

Code: Alles auswählen

<network>
  <name>net-brouted</name>
  <uuid>bb673354-2888-4ef0-8ba3-bc7ab2e430f2</uuid>
  <forward dev='vmbr0' mode='route'>
    <interface dev='vmbr0'/>
  </forward>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:c8:ee:41'/>
  <domain name='net-brouted'/>
  <ip family='ipv6' address=2a03:587:140:6268::1' prefix='64'>
    <dhcp>
      <range start='2a03:587:140:6268::100' end='2a03:587:140:6268::1ff'/>
    </dhcp>
  </ip>
</network>

Abgeschaltet habe ich zusätzlich die Firewall auf dem Rootserver und damit das NAT über die Firewall und

Code: Alles auswählen

sysctl -w net.ipv4.ip_forward=0
sysctl -w net.ipv6.conf.all.forwarding=0

Und auf der VM habe ich gemäss der Hetzner-Anleitung die Netzwerkkarte konfiguriert und alles durchgestartet. Mit dem Resultat, dass die VM immer noch nicht über IPv6 rauspingen konnte, noch nicht einmal die IPv6 des Rootservers erreichte, sehr wohl die der virbr1, und nicht nicht von aussen auf der IPv6 erreichbar war.

[WinMaik]

Sorry, dass ich nicht auf deine konkrete Config eingehe, aber die ist mir einfach zu konfus.

Hier ein Vorschlag mit dem KVM-Host als Router (IPv4 ignoriere ich komplett):

Auf dem KVM-Host:

Code: Alles auswählen

enp0s31f6 bekommt die 2a03:587:140:6268::2/128 mit Gateway fe80::1
vmbr0 bekommt die 2a03:587:140:6268::2/64

Es handelt sich um die gleiche IP, nur die Netzmaske ist eine Andere.
Außerdem wird net.ipv6.conf.all.forwarding=1 gesetzt, schließlich soll die Kiste ja routen.

In den VMs:

Code: Alles auswählen

2a03:587:140:6268:w:x:y:z/64 mit Gateway 2a03:587:140:6268::2

Wenn eine VM dann in Richtung Internet pingen will, sendet sie das Paket an den KVM-Host, der es wiederum an den Hetzner Router weitergibt. Die Src MAC des zum Hetzner Router gesendeten Pakets ist damit automatisch die des KVM-Hosts. Wenn das Response Paket zurück kommt (adressiert an 2a03:587:140:6268:w:x:y:z), landet es zunächst beim KVM-Host. Der weiß nun aber, dass alle Pakete in das Netz 2a03:587:140:6268::/64 in Richtung vmbr0 müssen, also leitet er es dort hin weiter. Genau hier befindet sich die VM, die das Paket entgegennimmt. Ende der Geschichte.

Es gibt noch diverse andere Möglichkeiten das Ganze zu realisieren, aber genannten Ansatz halte ich für am einfachsten.

[unitra]

Also, FE80::/10 ist eine link-local IPv6 Adresse. Eine lokale Schnittstelle und nicht bei Hetzner. Und ja, man kann auch über die lokale Schnittstelle also in deinem Setup enp1s0 routen, es ist nicht notwendig immer die lokale IP Adresse oder die entfernte am link anliegende IP adresse zu nehmen, man kann auch über den lokalen Schnittstellennamen routen. Und die IPv6 Adresse 2001:db8 ::/32 ist eine Dokumentationsadresse nur für Beispiele und Dokumentationen, ich habe angenommen dass das im Routingbeispiel auffällt dass hier eine Dokumentationsadresse angezeigt wird. Diese IPv6 Dokumentationsadresse wird im Internet nicht geroutet, also ist sie niemals erreichbar. Das ist nur ein Beispiel um die iproute2 Syntax zu veranschaulichen.

Die Rede ist im Topic von IPv6 und nicht von IPv4/MAC Adressen und NAT. IPv4 und IPv6 sind meistens gleich aber im Detail unterscheiden sie sich.

Es scheint als ob das grundlegende Wissen bezüglich IPv6 hier fehlt, und zwar das grundlegende Wissen. IPv6 ist doch ein Wenig anders als IPv4 und bestimmte Mechanismen die bei IPv4 zum Zuge kommen, gibt es bei IPv6 so in dieser Form nicht, deswegen sollte man keine Rückschlüsse von IPv4 auf IPv6 ziehen bei der Konfiguration.

...

Code: Alles auswählen

ip -6 route add 2001:0DB8::/32 via fe80::1

Mit der obigen Anweisung, routet die lokale Maschine, lokal das Netz 2001:0DB8::/32 über die lokale Schnittstelle FE80::1.

Also das funktioniert schon gar nicht, denn "fe80::1" ist das IPv6-Gateway von Hetzner und ich müsste an die Schnittstelle des VM-Gast hier enp1s0 routen

Code: Alles auswählen

2a03:587:140:6268::/64 via 2a03:587:140:6268::::1 dev enp1s0 metric 1024 pref medium

Ich habe auf meinen KVM-Host eine Bridge (vmbr0) bislang konfiguriert, an der alle zusätzlichen IP-Adressen angehängt sind. Via NAT werden dann diese IPv4-Adressen auf die jeweiligen IPv4-Adressen intern genatet die im Netzwerk 192.168.1.0 liegen und über die von libvirt Schnittstelle virbr1 erreichbar sind. Das funktioniert und die MAC-Adressen der VMs stören nicht das Hetzner-Netzwerk, das nur die MAC-Adresse des Root-Servers gestattet.

Dasselbe Problem hatte eben auch der Herr Kofler für IPv4 aufgezeigt und eben die Maskierung der MAC mit ebtables vorgeschlagen. Bei mir hatte das aber nicht geklappt.

[Kaheto]

Ich glaube wir reden irgendwie aneinander vorbei. Hier fehlt weder grundlegendes IPv6-Wissen noch ist eine Config zu konfus - vielleicht komplex.
Wir haben folgendes funktionierendes Szenario:
Rootserver im Hetzner-Netzwerk, der als KVM-Host fungiert und neben der Haupt-IP sechs Zusatz-IP-Adressen (IPv4) besitzt. Auf diesem KVM-Host laufen nach diesem Prinzip
https://community.hetzner.com/tutorials ... figuration (Bridge Modus) sechs KVM-VMs. Diese VMs hängen an einer Bridge virbr1 (192.168.1.1), die von KVM erzeugt wird (Nat-Modus). Die Zusatz-IPs hängen an der Bridge vmbr0 und werden via Iptables (shorewall) an die internen VM-IPs weitergeleitet. Das funktioniert seit Jahren.

Jetzt will ich aus obigen Link den Abschnitt "Routed (brouter)" umsetzen, um IPv6 auch an den VMs nutzen zu können. Wenn ich das exakt so nachbaue, dann kommt die VM weder per IPv4 noch IPv6 ins Internet. Ich selber vermute, das hängt an der richtigen Definition des Libvirt-Netzwerkes. Intern sollte zwischen den VMs auch noch Ipv4 mit dem Netzwerk 192.168.1.0 möglich sein.
Und warum geht das nicht mit dem bereits vorhandenen Bridged-Modus? Eben weil hier die MACs der VMs gegenüber dem Hetzner-Netzwerk offengelegt werden, das aber erlaubt Hetzner nicht. Ergo bleibt nur der Routed-Modus, was gerade aber scheitert.

Ich hoffe, ich konnte das jetzt für alle transparent und nachvollziehbar darlegen, um den Routed-Modus erfolgreich umsetzen zu können.

[WinMaik]

Ich hoffe, ich konnte das jetzt für alle transparent und nachvollziehbar darlegen, um den Routed-Modus erfolgreich umsetzen zu können.

Woran scheitert es genau bei meinem Vorschlag?

Falls Du das IPv6 Setup ähnlicher zu dem IPv4 Setup haben willst, kannst Du natürlich auch die IPs für die VMs dem KVM-Host zuweisen und dann NAT verwenden.

[Kaheto]

Ich hoffe, ich konnte das jetzt für alle transparent und nachvollziehbar darlegen, um den Routed-Modus erfolgreich umsetzen zu können.

Woran scheitert es genau bei meinem Vorschlag?

Ich habe das noch nicht getestet, weil ich irgendwo den Eindruck habe, dass das Grundkonstrukt noch nicht ganz klar geworden ist. Wie ich heute bereits erläutert habe, erwartet Hetzner, bei dem was ich vor habe, den Routed-Modus. Du aber scheinst noch auf Basis der Bridge-Methode vorzuschlagen.

[Kaheto]

Ich habe ehrlich noch eine andere Idee, bei der die funktionierende Bridge-Methode beibehalten werden würde. Und zwar wenn man jetzt die externen IPv6-Adressen über NAT6 an die jeweiligen VMs weiterleitet. Dann wären die VM-MACs wieder bisher gegenüber Hetzner maskiert. Wäre das überhaupt realisierbar?

[schorsch_76]

Ich hab das bei meinen LXC Containern ähnlich realisiert: br0 = für intere Container nicht mit eth0 verbunden. br0 nutzt ein fdxx Präfix und Container haben statische IPs. Per nat66 (jaaa, gannnz BÖÖÖÖSE) leitet shorewall bestimte Ports weiter.

https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/

[unitra]

Der Blogartikel von APNIC ist sehr lesenswert, auch in Bezug auf das NAT66, und ja NAT66, lasst uns noch mehr Komplexität auf das Problem werfen, aber wenn es funktioniert ist doch super. Was kann denn schon schief gehen?

Ich hab das bei meinen LXC Containern ähnlich realisiert: br0 = für intere Container nicht mit eth0 verbunden. br0 nutzt ein fdxx Präfix und Container haben statische IPs. Per nat66 (jaaa, gannnz BÖÖÖÖSE) leitet shorewall bestimte Ports weiter.

https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/

[reox]

Ich hab es auch so gemacht wie bei Hetzner beschrieben: https://docs.hetzner.com/de/robot/dedic ... ed-brouter
und das ist eigentlich genau das selbe wie:

Hier ein Vorschlag mit dem KVM-Host als Router

und das klappt ausgesprochen gut. radvd rennt am host und verteilt die IPs in die VMs, in den VMs steht dann fe80:... (die link-local adresse von virbr0) als gateway drin und fertig.

Allerdings habe ich die v6 Adresse für die virbr0 in der libvirt config gesetzt und nicht in /etc/network/interfaces wie bei hetzner beschrieben.

[WinMaik]

Ich habe das noch nicht getestet, weil ich irgendwo den Eindruck habe, dass das Grundkonstrukt noch nicht ganz klar geworden ist. Wie ich heute bereits erläutert habe, erwartet Hetzner, bei dem was ich vor habe, den Routed-Modus. Du aber scheinst noch auf Basis der Bridge-Methode vorzuschlagen.

Wie kommst Du darauf, dass es sich hierbei um eine Bridge-Methode handelt? Jedes Paket von und zu den VMs wird durch den KVM-Host geroutet.

[reox]

Wie kommst Du darauf, dass es sich hierbei um eine Bridge-Methode handelt? Jedes Paket von und zu den VMs wird durch den KVM-Host geroutet.

ich glaube die Verwirrung ist, dass man ja eine Bridge verwendet aber IPv6 sich trotzdem routen lässt.
Hetzner nennt den Modus ja auch "brouter" und zeigt aber auch eine extra konfiguration "bridge" wo tatsächlich die MAC der VM sichtbar wird. Aber das ist hier ja nicht der Fall.

[Kaheto]

Ich hoffe, ich konnte das jetzt für alle transparent und nachvollziehbar darlegen, um den Routed-Modus erfolgreich umsetzen zu können.

Woran scheitert es genau bei meinem Vorschlag?

Falls Du das IPv6 Setup ähnlicher zu dem IPv4 Setup haben willst, kannst Du natürlich auch die IPs für die VMs dem KVM-Host zuweisen und dann NAT verwenden.

Ich habe das gerade getestet, indem ich die Bridge-Version von Hetzner um Deinen Vorschlag am Host ergänzt habe. Das Resultat ist, dass dann von aussen der Host nicht mehr erreichbar ist.
Solange nicht klar ist, wie zum Beispiel bei Dir das Host-Netzwerk konzeptiert ist, mag das zwar bei Dir funktionieren, nicht aber bei mir, weil unsere Configs verschieden sind.

Ich arbeite mich jetzt einmal durch die ganzen Antworten durch.

[Kaheto]

Ich versuche jetzt https://docs.hetzner.com/de/robot/dedic ... ed-brouter für den Host sowie eine VM.

interfaces auf Host:

Code: Alles auswählen

auto lo
iface lo inet loopback
iface lo inet6 loopback

# The primary network interface enp0s31f6
auto enp0s31f6
iface enp0s31f6 inet static
        address 87.56.85.85
        netmask 255.255.255.255
        pointopoint 87.56.85.65
        gateway 87.56.85.65

iface enp0s31f6 inet6 static
        address 2a03:587:140:6268::2
        netmask 128
        gateway fe80::1

auto vmbr0
iface vmbr0 inet static
        address 87.56.85.85
        netmask 255.255.255.255
        bridge-ports none
        bridge_stp off       # disable Spanning Tree Protocol
        bridge_waitport 0    # no delay before a port becomes available
        bridge_fd 0          # no forwarding delay
        label_addresses yes
        up ip addr add 194.8.125.241/32 dev vmbr0
        down ip addr delete 194.8.125.241/32 dev vmbr0
        up ip addr add 194.8.125.242/32 dev vmbr0
        down ip addr delete 194.8.125.242/32 dev vmbr0
        up ip addr add 194.8.125.243/32 dev vmbr0
        down ip addr delete 194.8.125.243/32 dev vmbr0
        up ip addr add 194.8.125.244/32 dev vmbr0
        down ip addr delete 194.8.125.244/32 dev vmbr0
        up ip addr add 194.8.125.245/32 dev vmbr0
        down ip addr delete 194.8.125.245/32 dev vmbr0
        up ip addr add 194.8.125.246/32 dev vmbr0
        down ip addr delete 194.8.125.246/32 dev vmbr0
        dns-nameservers 213.133.100.100 213.133.98.98 9.9.9.9

iface vmbr0 inet6 static
        address 2a03:587:140:6268::2
        netmask 64

routed.xml auf Host

Code: Alles auswählen

<network ipv6='yes'> 
  <name>routed</name> 
  <uuid>4fd5242a-2817-4841-a11e-7063fcf2f9f6</uuid> 
  <forward dev='vmbr0' mode='route'>
    <interface dev='vmbr0'/>
  </forward>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:09:2e:d1'/>
  <domain name='example.com'/>
  <ip address='192.168.1.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.1.100' end='192.168.1.254'/>
    </dhcp>
  </ip>
  <ip family='ipv6' address='2a03:587:140:6268::1' prefix='64'>
    <dhcp>
      <range start='2a03:587:140:6268::100' end='2a03:587:140:6268::1ff'/>
    </dhcp>
  </ip>
</network>

Code: Alles auswählen

# ip r
default via 87.56.85.65 dev enp0s31f6 onlink 
87.56.85.65 dev enp0s31f6 proto kernel scope link src 87.56.85.85 
192.168.1.0/24 dev virbr1 proto kernel scope link src 192.168.1.1

# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::2 dev enp0s31f6 proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev virbr1 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev virbr1 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 metric 1024 onlink pref medium

Auf der VM sieht es so aus:
interfaces

Code: Alles auswählen

auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet static
        address 194.8.125.244
        netmask 255.255.255.255
        pointopoint 87.56.85.85
        gateway 87.56.85.85
        dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9

iface enp1s0 inet6 static
        address 2a03:587:140:6268::24
        netmask 64
        gateway 2a03:587:140:6268::1
        dns-nameservers 2a01:4f8:0:1::add:1010 2620:fe::fe:9

Code: Alles auswählen

# ip -6 r
::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::/64 dev enp1s0 proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 256 pref medium
default via 2a03:587:140:6268::1 dev enp1s0 metric 1024 onlink pref medium

# ip r
default via 87.56.85.85 dev enp1s0 onlink 
87.56.85.85 dev enp1s0 proto kernel scope link src 194.8.125.244 

Die Schnittstelle, die libvirt mit virbr1 ist erreichbar aber die Ip-Adresse des Host nicht.

Code: Alles auswählen

# ping6 2a03:587:140:6268::2
PING 2a03:587:140:6268::2(2a03:587:140:6268::2) 56 data bytes
From 2a03:587:140:6268::24: icmp_seq=1 Destination unreachable: Address unreachable
From 2a03:587:140:6268::24: icmp_seq=2 Destination unreachable: Address unreachable
From 2a03:587:140:6268::24: icmp_seq=3 Destination unreachable: Address unreachable

# ping6 2a03:587:140:6268::1
PING 2a03:587:140:6268::1(2a03:587:140:6268::1) 56 data bytes
64 bytes from 2a03:587:140:6268::1: icmp_seq=1 ttl=64 time=0.237 ms
64 bytes from 2a03:587:140:6268::1: icmp_seq=2 ttl=64 time=0.291 ms
64 bytes from 2a03:587:140:6268::1: icmp_seq=3 ttl=64 time=0.293 ms

Umgekehrt kann ich mich vom Host aus auf der VM 2a03:587:140:6268::24 einloggen und es auch anpingen. Die VM kommt weder über IPv4 noch über Ipv6 ins Internet

Code: Alles auswählen

root@mx ~ # ping 87.56.85.85
PING 87.56.85.85 (87.56.85.85) 56(84) bytes of data.
From 194.8.125.244 icmp_seq=1 Destination Host Unreachable
From 194.8.125.244 icmp_seq=2 Destination Host Unreachable
From 194.8.125.244 icmp_seq=3 Destination Host Unreachable
From 194.8.125.244 icmp_seq=4 Destination Host Unreachable
From 194.8.125.244 icmp_seq=5 Destination Host Unreachable
From 194.8.125.244 icmp_seq=6 Destination Host Unreachable

ich habe jetzt versucht das Ganze strukturiert hier darzustellen. Also irgendwie funktioniert die Brouter-Lösung von Hetzner bei mir nicht.

[Kaheto]

Ich hab es auch so gemacht wie bei Hetzner beschrieben: https://docs.hetzner.com/de/robot/dedic ... ed-brouter
und das ist eigentlich genau das selbe wie:

Hier ein Vorschlag mit dem KVM-Host als Router

und das klappt ausgesprochen gut. radvd rennt am host und verteilt die IPs in die VMs, in den VMs steht dann fe80:... (die link-local adresse von virbr0) als gateway drin und fertig.

Allerdings habe ich die v6 Adresse für die virbr0 in der libvirt config gesetzt und nicht in /etc/network/interfaces wie bei hetzner beschrieben.

Gibt es dazu eine brauchbare Anleitung? Denn ich scheitere bereits an dieser Anleitung bereits nur für IPv4, was auch der Grund seinerzeit war, die Bridge-Methode zu verwenden.

Wie ich es verstehe, liegen zwar die VMs auf dem KVM-Host, sind aber mit Ihren externen IP-Adressen von aussen erreichbar. Bei mir werden die VMs über NAT an die Aussenwelt angebunden.

[reox]

Was mir nicht ganz klar ist: Du schreibst du NATtest die v4 Adressen der VMs aber du hast 194.8.. adressen für die VMs?
dH du hast wirklich öffentlichte v4 Adressen die du in den VMs haben willst?

[Kaheto]

Was mir nicht ganz klar ist: Du schreibst du NATtest die v4 Adressen der VMs aber du hast 194.8.. adressen für die VMs?
dH du hast wirklich öffentlichte v4 Adressen die du in den VMs haben willst?

Nein, das sei jetzt nur maskiert. Intern sind Adressen aus 192.168.1.0. Bei dem ganzen Hin- und Her-Switchen, weil das eigentlich produktive Systeme sind, habe ich versehentlich 192.168.1 auch maskiert. Ich will nicht, dass hier die echten Adressen herumschwirren.

[reox]

aha ok naja dann bau die vmbr0 ab und verwend nur noch die virbr0 von libvirt. IMO brauchst du die vmbr0 gar nicht.

[Kaheto]

aha ok naja dann bau die vmbr0 ab und verwend nur noch die virbr0 von libvirt. IMO brauchst du die vmbr0 gar nicht.

Danke für die Bestätigung, denn das ich mich gestern aufgrund Deiner Bemerkung

Allerdings habe ich die v6 Adresse für die virbr0 in der libvirt config gesetzt

zum Nachdenken gebracht. Allerdings stecken in der Definition von vmbr0 noch diese Parameter drin

Code: Alles auswählen

bridge-ports none
        bridge_stp off       
        bridge_waitport 0   
        bridge_fd 0

Wie werden in der Libvirt-Config berücksichtigt? Oder sind die unter diesen Umständen nicht mehr notwendig? Bzw. meines Verständnisses nach wird dann innerhalb Libvirt auf enp0s31f6 selber geroutet. Oder sehe ich das falsch?