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

[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?

[Kaheto]

Ich konnte jetzt zumindest einmal Teilerfolge mit einer VM erzielen. Dazu habe ich auf dem KVM-Host (87.56.85, 2a03:587:140:6268::::2) zuerst die libvirt-Config erstellt.
/etc/libvirt/qemu/networks/routed1.xml

Code: Alles auswählen

<network>
  <name>routed1</name>
  <uuid>b0277bde-555b-49d3-a3b0-b53f6ad1956a</uuid>
  <forward dev='enp0s31f6' mode='route'>
    <interface dev='enp0s31f6'/>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:fb:78:46'/>
  <domain name='example.com'/>
  <ip address='167.9.107.1' netmask='255.255.255.0'>
  </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>

Wobei ich jetzt statt wie üblich die IP-Adresse von virbr0 nicht auf 192.168.1.1 sondern auf 167.9.107.1 gesetzt habe, in der Hoffnung, dass Hetzner diese nicht nutzt.
KVM-interfaces:

Code: Alles auswählen

# The loopback network interface
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
        gateway 87.56.85.65

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

Routing KVM:

Code: Alles auswählen

default via 87.56.85 dev enp0s31f6 onlink 
87.56.85 dev enp0s31f6 proto kernel scope link src 87.56.85.85 
167.9.107.0/24 dev virbr0 proto kernel scope link src 167.9.107.1

Code: Alles auswählen

::1 dev lo proto kernel metric 256 pref medium
2a03:587:140:6268::::/64 dev enp0s31f6 proto kernel metric 256 pref medium
2a03:587:140:6268::::/64 dev virbr0 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev vnet0 proto kernel metric 256 pref medium
fe80::/64 dev virbr0 proto kernel metric 256 pref medium
default via fe80::1 dev enp0s31f6 metric 1024 onlink pref medium

Pings nach aussen funktionieren

Code: Alles auswählen

# ping6  2003:e5:9710:7a00:213:3bff:fe10:773c
PING 2003:e5:9710:7a00:213:3bff:fe10:773c(2003:e5:9710:7a00:213:3bff:fe10:773c) 56 data bytes
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=1 ttl=58 time=20.4 ms
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=2 ttl=58 time=20.6 ms
64 bytes from 2003:e5:9710:7a00:213:3bff:fe10:773c: icmp_seq=3 ttl=58 time=20.5 ms

Code: Alles auswählen

ping www.google.com
PING www.google.com(fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004)) 56 data bytes
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=1 ttl=118 time=5.07 ms
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=2 ttl=118 time=5.11 ms
64 bytes from fra16s42-in-x04.1e100.net (2a00:1450:4001:809::2004): icmp_seq=3 ttl=118 time=5.11 ms

Die VM (Mailserver) hat 167.9.107.244 und 2a03:587:140:6268::::24/64 mit

Code: Alles auswählen

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp1s0
iface enp1s0 inet static
        address 167.9.107.244
        netmask 255.255.255.255
        pointopoint 87.56.85.85
        gateway 87.56.85.85
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 192.168.1.1 213.133.100.100 9.9.9.9
        dns-search example.com

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

Routing auf VM:

Code: Alles auswählen

default via 87.56.85.85 dev enp1s0 onlink 
87.56.85.85 dev enp1s0 proto kernel scope link src 167.9.107.244

Code: Alles auswählen

::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

Von aussen ist die VM via ssh, smtp, http erreichbar, soweit gut. Aber ich kann nicht rauspingen

Code: Alles auswählen

ping6  2003:e5:9710:7a00:213:3bff:fe10:773c
PING 2003:e5:9710:7a00:213:3bff:fe10:773c(2003:e5:9710:7a00:213:3bff:fe10:773c) 56 data bytes

und von aussen

Code: Alles auswählen

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

Also ich weiß nicht, ob das jetzt die richtige Herangehensweise ist. Das Routing sollte noch angepasst werden. Und ich weiß nicht, wie man das mit der IP 167.9.107.1 für die Bridge lösen kann, denn die ist bei Hetzner sicher anders vergeben.

Ich bin dankbar, wenn man mir meine Fehler zeigen kann bzw. was ich besser machen kann.

[Kaheto]

radvd habe ich noch nicht verstanden, was das soll. Denn die IPs 4 wie 6 sollen doch geroutet werden und somit an den VMs wie von aussen zur Verfügung stehen.

[reox]

radvd tut nur das prefix announcen und den clients sagen, dass da ein router ist.
ich bin mir nicht ganz sicher aber glaube das libvirt das auch irgendwie intern kann, habs aber nur mit dem radvd zum laufen gebracht.

[Kaheto]

radvd tut nur das prefix announcen und den clients sagen, dass da ein router ist.
ich bin mir nicht ganz sicher aber glaube das libvirt das auch irgendwie intern kann, habs aber nur mit dem radvd zum laufen gebracht.

Würde das eventuell das oben beschriebene Routingproplem bei den VMs lösen?

[reox]

ah, da hatte ich gar nicht ganz angeschaut

also ich würde als gateway die link-local adresse von der bridge nehmen, also fe80:...usw
Versuch das mal von der VM zu pingen, das muss auch gehen ohne das du eine public v6 IP vergibst.

edit wegen den adressen: in der libvirt doku steht

For IPv6, the default route is established via Router Advertisement.

https://libvirt.org/formatnetwork.html

Aber irgendwie klappt das bei mir nicht. Offenbar gehts nur wenn man auch DHCPv6 verwendet, aber eigentlich mag ich das eher mit der autoconfig haben... ohne das hier kapern zu wollen: Weiß jemand ob man mit libvirt auch SLAAC machen kann ohne extra den radvd anzuwerfen?

[Kaheto]

Also ich habe es jetzt einmal mit

Code: Alles auswählen

gateway fe80::5054:ff:fefb:7846

in der Guest-interfaces ausprobiert. Das Ergebnis bleibt gleich, obwohl ich es wie Hetzner mache

Code: Alles auswählen

# /etc/network/interfaces
### Beispiel für Einzel-IP aus fremden Subnetz
# Loopback device:
auto lo
iface lo inet loopback

# device: ens18
auto ens18
iface ens18 inet static
  [b]address <Zusatz-IP>[/b]
  netmask 255.255.255.255
  [b]pointopoint <Haupt-IP>[/b]
  [b]gateway <Haupt-IP>[/b]

iface ens18 inet6 static
  address <Adresse aus dem IPv6-Subnetz> # z.B. 2001:db8::f001
  netmask 64
  [b]gateway <IPv6-Adresse vmbr0>[/b] # z.B. 2001:db8::3

Respektive, wie müssen das Routing, die Firewall-Rules auf dem KVM-Host aussehen und wie auf der VM?

[reox]

Hast du net.ipv6.conf.all.forwarding=1 in sysctl gesetzt?

Kannst du aus der VM fe80::5054:ff:fefb:7846 pingen?

was macht ein ping6 ff02::2 bzw ping6 ff02::1 (pinge alle router bzw alle hosts)?

[Kaheto]

Hast du net.ipv6.conf.all.forwarding=1 in sysctl gesetzt?

Kannst du aus der VM fe80::5054:ff:fefb:7846 pingen?

was macht ein ping6 ff02::2 bzw ping6 ff02::1 (pinge alle router bzw alle hosts)?

Punkt 1 ist von Anfang an gesetzt.
Punkt 2 funktioniert auch

Code: Alles auswählen

# ping6 fe80::5054:ff:fefb:7846
PING fe80::5054:ff:fefb:7846(fe80::5054:ff:fefb:7846) 56 data bytes
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.192 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.251 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.260 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.249 ms

Punkt 3 ebenfalls

Code: Alles auswählen

root@mx ~ # ping6 ff02::2
PING ff02::2(ff02::2) 56 data bytes
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.273 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.267 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.272 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=5 ttl=64 time=0.252 ms
^C
--- ff02::2 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 77ms
rtt min/avg/max/mdev = 0.099/0.232/0.273/0.069 ms
root@mx ~ # ping6 ff02::1
PING ff02::1(ff02::1) 56 data bytes
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=1 ttl=64 time=0.320 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=2 ttl=64 time=0.374 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=3 ttl=64 time=0.071 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=3 ttl=64 time=0.374 ms (DUP!)
64 bytes from fe80::5054:ff:fe38:a916%enp1s0: icmp_seq=4 ttl=64 time=0.069 ms
64 bytes from fe80::5054:ff:fefb:7846%enp1s0: icmp_seq=4 ttl=64 time=0.285 ms (DUP!)
^C
--- ff02::1 ping statistics ---
4 packets transmitted, 4 received, +4 duplicates, 0% packet loss, time 78ms
rtt min/avg/max/mdev = 0.061/0.203/0.374/0.137 ms

Dieser Ping bleibt so hängen

Code: Alles auswählen

root@mx ~ # ping6 www.google.com
PING www.google.com(fra02s19-in-x04.1e100.net (2a00:1450:4001:808::2004)) 56 data bytes

Das geht allerdings auch, der hat aber auch keinen AAAA-Record sondern nur A:

Code: Alles auswählen

root@mx ~ # ping www.lihas.de
PING www.lihas.de (45.150.154.30) 56(84) bytes of data.
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=1 ttl=53 time=5.96 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=2 ttl=53 time=6.21 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=3 ttl=53 time=6.25 ms
64 bytes from rproxy.lihas.de (45.150.154.30): icmp_seq=4 ttl=53 time=6.19 ms
^C
--- www.lihas.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 5.959/6.151/6.246/0.112 ms

Was bei der Interfaces auf dem Host bei virbr0 (weil über libvirt konfiguiert) fehlt, sind diese 3 Optionen

Code: Alles auswählen

        bridge_stp off       # disable Spanning Tree Protocol
        bridge_waitport 0    # no delay before a port becomes available
        bridge_fd 0          # no forwarding delay

die im Bridge-Modus die vmbr0 erhält.

[reox]

hmm soweit so gut. dH du siehst das korrekt als gateway und connection ist auch da. Dann kann es wohl nur so sein, dass irgendwo der Ping hängen bleibt.
rennt da irgendwo eine firewall? Wenn du vom host pingen kannst, kanns *eigentlich* nur daran liegen.

diese bridge optionen brauchst du IMHO nicht bei der virbr.

[Kaheto]

rennt da irgendwo eine firewall? Wenn du vom host pingen kannst, kanns *eigentlich* nur daran liegen.

Nein, ich schalte die Shorewall auf dem Host ab, da die für die Bridge-Methode und Nat konfiguriert ist. Ich würde ansonsten gar nicht auf den Host kommen. Dennoch sehe ich

Code: Alles auswählen

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:67

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             194.8.125.0/24      
ACCEPT     all  --  194.8.125.0/24       anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

und

Code: Alles auswählen

# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp      anywhere             anywhere             udp dpt:dhcpv6-server
ACCEPT     udp      anywhere             anywhere             udp dpt:domain
ACCEPT     tcp      anywhere             anywhere             tcp dpt:domain

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             2a03:587:140:6268::/64 
ACCEPT     all      2a03:587:140:6268::/64  anywhere            
ACCEPT     all      anywhere             anywhere            
REJECT     all      anywhere             anywhere             reject-with icmp6-port-unreachable
REJECT     all      anywhere             anywhere             reject-with icmp6-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

[Kaheto]

Ich habe jetzt mal recherchiert und gefunden, dass bei libvirt "nwfilter" für Firewallregeln auf dem Host bzw. Gast existiert.

Code: Alles auswählen

# virsh nwfilter-list 
 UUID                                   Name
-----------------------------------------------------------------
 0525f8ed-9b19-4fe8-9f71-3152041ce99c   allow-arp
 d97104ba-5dd2-488a-a361-42caca0176dd   allow-dhcp
 0eb7caaa-1be6-41b4-a336-07b0e4e32534   allow-dhcp-server
 8a076492-d9b5-403c-8a64-bcaf1f47dec6   allow-incoming-ipv4
 bbae4326-2d89-4177-9d49-83ef67316102   allow-ipv4
 c1590c18-f2bd-4717-9375-da162fdd825d   clean-traffic
 6fbe195c-87ef-4fa2-97f3-527ede0c9334   clean-traffic-gateway
 9ab0ceb9-3037-4077-8ef7-470b658d4aff   no-arp-ip-spoofing
 132de347-338c-43e1-bbba-b329a1667f45   no-arp-mac-spoofing
 9bf301a5-0d43-4135-b51b-56ee6af27b71   no-arp-spoofing
 7ba954ec-2b91-44d4-b126-56e9e526a8cc   no-ip-multicast
 b3e9258e-8020-4922-b649-92129e88ba29   no-ip-spoofing
 10437c97-33f8-4112-b243-744ff3dbc1c4   no-mac-broadcast
 10cc4590-9397-4f50-9ca9-7e8e159f4efe   no-mac-spoofing
 8075e4e0-04a2-420e-8f20-446129b86337   no-other-l2-traffic
 0e27c307-e993-491e-9afe-020713c57168   no-other-rarp-traffic
 90f5d653-fab9-4329-b558-8f0641a746b8   qemu-announce-self
 65b2bed5-9aec-4f57-b654-016c48bf0d49   qemu-announce-self-rarp

Zeigt das auch.

Auf der VM wird allerdings nichts dergleichen angelegt:

Code: Alles auswählen

 # ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[Kaheto]

Jetzt habe ich diese Regeln

Code: Alles auswählen

REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

mit

Code: Alles auswählen

iptables -D FORWARD 5
iptables -D FORWARD 4
ip6tables -D FORWARD 5
ip6tables -D FORWARD 4

gelöscht und

Code: Alles auswählen

iptables -A FORWARD -p icmp -j ACCEPT
ip6tables -A FORWARD -p icmp -j ACCEPT

gesetzt. Die Regeln auf dem Host sehen jetzt so aus

Code: Alles auswählen

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:67

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             194.8.125.0/24      
ACCEPT     all  --  194.8.125.0/24       anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootp


# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp      anywhere             anywhere             udp dpt:dhcpv6-server
ACCEPT     udp      anywhere             anywhere             udp dpt:domain
ACCEPT     tcp      anywhere             anywhere             tcp dpt:domain

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all      anywhere             2a03:587:140:6268::/64 
ACCEPT     all      2a03:587:140:6268::/64  anywhere            
ACCEPT     all      anywhere             anywhere            
ACCEPT     icmp     anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

IPv4 von VM nach aussen geht:

Code: Alles auswählen

root@mx ~ # ping  93.220.240.28
PING 93.220.240.28 (93.220.240.28) 56(84) bytes of data.
64 bytes from 93.220.240.28: icmp_seq=1 ttl=57 time=16.5 ms
64 bytes from 93.220.240.28: icmp_seq=2 ttl=57 time=16.6 ms
64 bytes from 93.220.240.28: icmp_seq=3 ttl=57 time=16.5 ms
^C
--- 93.220.240.28 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 16.452/16.528/16.629/0.074 ms

aber nach wie vor nicht mit IPv6

Code: Alles auswählen

ping6  2003:e5:970a:500:213:3bff:fe10:773c
PING 2003:e5:970a:500:213:3bff:fe10:773c(2003:e5:970a:500:213:3bff:fe10:773c) 56 data bytes
^C
--- 2003:e5:970a:500:213:3bff:fe10:773c ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 197ms

An die externe IP-Adresse genauso

Code: Alles auswählen

root@mx ~ # 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

[reox]

da hab ich jetzt leider keine idee

aber was sagt `ip -6 r` auf dem host und in der VM? vllt doch noch irgendwie ein routing problem

[Kaheto]

Ich glaube ich komme der Sache etwa näher, denn auf dem Host hat 2a03:587:140:6268::/64 zwei Routen. Einmal über enp0s31f6 und einmal über virbr0:

Code: Alles auswählen

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

Auf der VM ist es wie folgt.

Code: Alles auswählen

root@mx ~ # 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

Ich setze die Routen bislang nicht manuell, sondern das passiert offensichtlich durch libvirt.

[Kaheto]

Okay, jetzt habe ich eine Teillösung geschafft!

Code: Alles auswählen

ip -6 route del 2a03:587:140:6268::/64 dev enp0s31f6

auf dem Host sorgt dafür, dass die VM via IPv6 ihre Connections bekommt. Jetzt ist natürlich interessant, diese Route erst gar nicht entstehen zu lassen.