Hallo Liste,
ich habe bei Hetzner mehrere Server mit einem vSwitch verbunden und dort
ein öffentliches /64-Netz angebunden. Das Gateway ist dabei ein
Juniper-Router bei Hetzner innerhalb des /64-Netzes ($Prefix::1).
vSwitch bedeutet in dem Falle, daß auf der vorhandenen NIC ein
zusätzliches VLAN konfiguriert wird, welches mit dem vSwitch verbunden ist.
Das sieht auf dem Server etwa so aus:
auto vlan4000
iface vlan4000 inet manual
vlan-raw-device enp195s0
auto vswitch0
iface vswitch0 inet6 static
address $Prefix:1001::1/64
bridge_ports vlan4000
bridge_stp on
bridge_maxwait 10
up ip link set $IFACE mtu 1400
up ip -6 rule add from $Prefix:1001::1/64 lookup vswitch0
up ip -6 rule add to $Prefix:1001::1/64 lookup vswitch0
up ip -6 route add default via $Prefix::1 dev $IFACE table vswitch0
down ip -6 route del default via $Prefix::1 dev $IFACE table vswitch0
down ip -6 rule del from $Prefix:1001::1/64 lookup vswitch0
down ip -6 rule del to $Prefix:1001::1/64 lookup vswitch0
Damit VMs darüber angebunden werden können ist das hier als Bridge
konfiguriert. Die zusätzlichen Routen/Rules sind nur für die
Kommunikation außerhalb des Netzes relevant, innerhalb würde es auch
ohne auskommen.
In der VM ist das Netzwerk, abgesehen von der geänderten MTU, ohne
besondere Einstellungen mit einer statischen IP konfiguriert:
allow-hotplug enp3s0
iface enp3s0 inet6 static
address $Prefix:1101::1/64
gateway $Prefix::1
up ip link set $IFACE mtu 1400
Grundsätzlich funktioniert das so, alle Verbindungen in allen Richtungen
sind möglich. Allerdings bricht an einzelnen VMs irgendwann die
Verbindung ab, anscheinend hauptsächlich an VMs, an denen kein ständiger
Traffic verursacht wird. Zuerst ist das Problem hauptsächlich bei
Verbindungen von/nach außen aufgefallen, während intern scheinbar alles
funktionierte. Hetzner bestätigte mir, daß die zugehörigen
Mac/IPv6-Adressen währenddessen nicht im Router gelistet sind, weshalb
ich das Problem zuerst auch dort verortet hatte. Der Support konnte mir
dabei aber auch nicht weiterhelfen.
Bei einem ausgiebigen Ping-Test ist dann aber aufgefallen, daß teilweise
auch interne Verbindungen aussteigen, sodaß ich den Fehler jetzt eher
auf dem Host oder den VMs suchen würde.
Folgendes Test-Szenario (alles Debian 11):
2 Server (Hosts) mit jeweils 2 VMs, Einzelpings aller 5s
Pings laufen in beiden Richtungen zwischen allen Beteiligten. Nach
einiger Zeit bricht ausschließlich 1 Verbindung ab, manchmal sogar nur
eine Richtung davon. Mal ist es die Verbindung von und/oder zum Host,
während sich die VMs untereinander als auch mit dem 2. Server weiterhin
erreichen, manchmal ist es auch eine VM-Verbindung innerhalb des
Servers, während die Verbindung vom/zum Host noch steht.
Das Problem tritt aber auch älteren Hostsystemen (Debian 9/10) auf.
Die Firewall kann ebenso ausgeschlossen werden, da das Problem auch bei
deaktivierter Firewall auftritt. Allerdings zeigt ein icmp log/count
auch, daß keine Pakete nach der allow-ndp-Regel mehr übrig bleiben.
chain inbound_ipv6 {
icmpv6 type echo-request accept
icmpv6 type { nd-router-advert, nd-neighbor-solicit,
nd-neighbor-advert } accept
ip6 nexthdr ipv6-icmp log prefix "[nftables] ICMPv6 Accept: " counter
packets 0 bytes 0 limit rate 20/second accept
}
Parallel dazu ist ein 2. vSwitch mit einer ähnlichen IPv4-Konfiguration
und eine 2. NIC in den VMs konfiguriert, wo das Problem nicht auftaucht.
Hier fehlt lediglich die IP-Adresse und die zusätzlichen Routen auf dem
Host. Darüber wurden die VMs auch während des Tests beobachtet.
Mit gerouteten IPv6-Verbindungen über das zum Server gehörige IPv6-Netz
treten auch keine Probleme auf. Ein allgemeines IPv6- oder
Bridge-Problem sollte damit auch ausgeschlossen sein.
Es wurde auch ohne zusätzliche IPv6-Regeln auf dem Host getestet, um das
als Fehlerquelle auszuschalten.
Das einzige erkennbare Muster sind Zeitspannen. Der Ausfall erfolgt nach
ca. 20-30 min und in den meisten Fällen führte zusätzlicher Traffic auf
noch bestehenden Verbindungen nach kurzer Zeit (20-30s) dazu, daß die
Verbindung wieder funktionierte.
Aufgrund dieses Fehlerbildes vermute ich das Problem im NDP-Bereich,
kenne mich aber damit zu wenig aus, um es weiter zu lokalisieren.
Sind dafür zusätzliche Kerneleinstellungen (sysctl) nötig?
Oder ein zusätzlicher Daemon?
Gruß
Rico
