fragen stichworte

IPv6-Verbindung nach 20 Minuten bei KVM-Gast verloren

Ich habe einen KVM-Virtualisierungsserver bei Hetzner. Hetzner bietet mir eine Master-IP (95.xxx.xxx.235) und ein/29 IPv4-Subnetz (95.xxx.xxx.184/29) und ein/64 IPv6-Netzwerk (2a01: xxxx: xxxx: xxxx ::/64).

Der KVM-Guest (Debian Stretch) verliert die IPv6-Verbindung genau nach 20 Minuten Neustart beim Neustart der Netzwerkdienste. Obwohl die Verbindung unterbrochen ist, kann ich das Standardgateway (fe80 :: 1) anpingen. Die IPv4-Konnektivität bleibt ständig aktiv und hat keine Probleme.

Derzeit ist die Schnittstelle im Bridge-Modus als Macvlan festgelegt, und ich habe auch den VEPA- und den privaten Modus ohne Erfolg ausprobiert. Auch der NIC-Typ ist auf e1000 eingestellt, aber ich habe virtio auch ohne Erfolg ausprobiert.

Nach dem Verbindungsverlust habe ich einen TCP-Dump von der physischen NIC auf dem Host entnommen, und es zeigt, dass Echoanforderungen abgehen und Echoantworten an der Schnittstelle ankommen, aber ein Tcpdump der Gast-NIC konnte ich nur sehen Verlassen der NIC.

/etc/network/interfaces auf Host:

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto enp2s0
iface enp2s0 inet static
  address 95.xxx.xxx.235
  netmask 255.255.255.192
  gateway 95.xxx.xxx.193
  up route add -net 95.xxx.xxx.192 netmask 255.255.255.192 gw 95.xxx.xxx.193 dev enp2s0

iface enp2s0 inet6 static
  address 2a01:xxx:xxx:xxx::2
  netmask 64
  gateway fe80::1

/etc/network/interfaces auf Guest:

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto ens3
iface ens3 inet static
    address 95.xxx.xxx.187
    netmask 255.255.255.248
    gateway 95.xxx.xxx.185

iface ens3 inet6 static
    address 2a01:xxx:xxx:xxx::20
    netmask 64
    gateway fe80::1

# route -6 -n auf Host:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2a01:xxxx:xxxx:xxxx::/64          ::                         U    256 8  1162 enp2s0
fe80::/64                      ::                         U    256 0     0 macvtap0
fe80::/64                      ::                         U    256 0     0 enp2s0
::/0                           fe80::1                    UG   1024 8  4534 enp2s0
::/0                           ::                         !n   -1  1 11069 lo
::1/128                        ::                         Un   0   9    81 lo
2a01:xxxx:xxxx:xxxx::/128         ::                         Un   0   1     0 lo
2a01:xxxx:xxxx:xxxx::2/128        ::                         Un   0   9    82 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::/128                     ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:1069/128   ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:22e1/128   ::                         Un   0   1     0 lo
fe80::xxxx:xxxx:xxxx:201/128   ::                         Un   0   2    79 lo
ff00::/8                       ::                         U    256 0     0 macvtap0
ff00::/8                       ::                         U    256 0     0 enp2s0
::/0                           ::                         !n   -1  1 11069 lo

# route -6 -n auf Gast:

Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
2a01:xxxx:xxxx:1414::/64          ::                         U    256 0     0 ens3
fe80::/64                      ::                         U    256 0     0 ens3
::/0                           fe80::1                    UG   1024 2    77 ens3
::/0                           ::                         !n   -1  1  6846 lo
::1/128                        ::                         Un   0   5   525 lo
2a01:xxxx:xxxx:xxx::20/128       ::                         Un   0   3    70 lo
fe80::xxxx:xxxx:xxx:22e1/128   ::                         Un   0   2     6 lo
ff00::/8                       ::                         U    256 0     0 ens3
::/0                           ::                         !n   -1  1  6846 lo

# ip -6 Nachbarn auf dem Host:

2a01:xxxx:xxxx:xxxx::20 dev enp2s0  FAILED
fe80::1 dev enp2s0 lladdr xx:xx:xx:8d:22:06 router STALE

# ip -6 Nachbarn auf Guest:

fe80::1 dev enp2s0 lladdr xx:xx:xx:8d:22:06 router REACHABLE

Wahrscheinlich relevante Dinge aus/etc/sysctl.conf auf dem Host:

net.ipv4.ip_forward=1
net.ipv4.conf.enp2s0.send_redirects=0
net.ipv6.conf.all.forwarding=1

Wahrscheinlich relevante Dinge aus/etc/sysctl.conf in Guest:

net.ipv6.conf.default.accept_ra=2
net.ipv6.conf.default.autoconf=1
net.ipv6.conf.all.accept_ra=2
net.ipv6.conf.all.autoconf=1
net.ipv6.conf.ens3.accept_ra=2
net.ipv6.conf.ens3.autoconf=1

Wahrscheinlich relevanter Abschnitt der Guest libvirt-config:

<interface type='direct' trustGuestRxFilters='yes'>
  <mac address='xx:xx:xx:xx:xx:xx'/>
  <source dev='enp2s0' mode='bridge'/>
  <model type='e1000'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Da ich seit ungefähr zwei Wochen damit zu kämpfen habe und fast jeden relevanten Beitrag mit ähnlichen Problemen gelesen habe, habe ich gesehen, dass Hetzner anscheinend irgendeine Art von fischartiger IPv6-Implementierung durchführt. Ich habe sie bereits kontaktiert, aber sie wunderten sich, dass ich selbst ein Routingproblem hätte. Das könnte wahr sein, da ich nach 20 Minuten immer noch die Echoantworten auf der physischen Netzwerkkarte bekomme, obwohl sie nicht an Guest weitergeleitet werden.

Also, Ideen von IPv6-Kollegen?

Update:

Hetzner hat mir also bestätigt, dass 2a01: xxxx: xxxx: xxxx ::/64 Netzwerk an die Link-Local-Adresse der physikalischen Schnittstelle geroutet wird. Beim Neustart des Netzwerks bleibt der NDP-Eintrag für 20 Minuten erhalten, wird jedoch anschließend entfernt, da die VM nicht mit der korrekten Link-Local-Adresse antwortet, da sie eine andere MAC-Adresse hat.

Es scheint, als ob ich hier keine macvtap-Interfaces verwenden kann, aber dafür muss ich eine Brücke schaffen. Ich frage mich jedoch, warum der Host den Gast nicht mit IPv6 sehen kann (und umgekehrt), wenn der IPv4 noch funktioniert. Ich denke, es würde mir erlauben, den Verkehr direkt von der Hauptadresse der lokalen Adresse zu leiten.

antworten

Ich hatte das gleiche Problem mit dem Hetzner-Server, jedoch mit VirtualBox anstelle von KVM.

Problem:

Hetzner leitet alle IPv6-Pakete mit einer Ziel-IP innerhalb Ihres/64-Subnetzes an die MAC-Adresse Ihres physischen Hosts weiter. Das heißt, wenn Sie einen Ping von irgendwo im Internet an Ihre VM senden, der eine IPv6-Adresse mit demselben Präfix wie der Host hat, führt Hetzers Gateway keine Nachbarsaufforderung aus, um die MAC-Adresse Ihrer VM nachzuschlagen, sondern leitet sie einfach weiter die ICMP-Pakete an die MAC Ihres Hosts. Aus diesem Grund können Sie Echoantworten auf Ihrem physischen Host sehen, jedoch nicht auf Ihrer VM: Sie richten sich an die MAC Ihres Hosts, nicht an die VM der VM.

Es scheint jedoch einen Fehler in der IPv6-Implementierung von Hetzner zu geben (oder kann absichtlich gemacht werden, weiß ich nicht): Wenn die VM eine Nachbaranforderung sendet, um die MAC-Adresse des Gateways nachzuschlagen (z. B. 80 :: 1), und diese globale IPv6-IP-Adresse als Quelladresse der Aufforderung verwendet, scheint das Gateway von Hetzner irgendwie die interne IPv6-zu-MAC-Adresse zu aktualisieren Adressentabelle. In den folgenden 20 Minuten sendet das Hetzner-Gateway alle Pakete, die an die IPv6-Adresse der VMs gerichtet sind, an die MAC-Adresse der VMs. Wenn innerhalb von 20 Minuten keine weitere Anforderung von der globalen IP-Adresse von VM und VM an das Gateway gesendet wird, werden IPv6-Pakete an die MAC des Hosts gesendet.

Nun ist Ihre VM - direkt nach dem Start des Netzwerks - möglicherweise weil die Link-Local-Adresse an dieser Stelle nicht zugewiesen ist - ONCE sendet eine Aufforderung, wobei die globale IPv6-Adresse als Quelle verwendet wird, und aktualisiert die MAC-Adresstabelle von Hetzner einmal "versehentlich" . Während der Laufzeit sendet die VM immer noch ständig Ansagen, um die MAC-Adresse des Gateways nachzuschlagen, um die MAC-Adresstabelle auf dem neuesten Stand zu halten. Die lokale IPv6-Adresse wird jedoch verwendet (dies ist aus der Sicht von IPv6 völlig in Ordnung) das aktualisiert die MAC-Adresstabelle von Hetzner nicht. Aus diesem Grund scheint IPv6 nach dem Start der VM vollständig zu funktionieren, jedoch nur für 20 Minuten.

Lösungen:

Es gibt eine schmutzige Lösung und eine saubere Lösung:

  • Dirty-Lösung: Ihre VM muss von Zeit zu Zeit eine Anfrage nach der MAC-Adresse des Gateways über ihre globale IPv6-Adresse senden (beispielsweise alle 5 Minuten). Das ist knifflig: Ihre VM sendet Ansagen, verwendet jedoch Link-Local-IPv6. Also habe ich hier einen billigen Trick benutzt: Ich entferne die Link-Local-IP von der Schnittstelle, sende eine Aufforderung (die dann gezwungen wird, die globale IP zu verwenden) und verbinde die Link-Local-IP erneut:

    ip -6 addr del fe80::a00:27ff:fecf:e270/64 dev enp0s3
    ndisc6 fe80::1 enp0s3
    ip -6 addr add fe80::a00:27ff:fecf:e270/64 dev enp0s3
    
  • Saubere Lösung: Keine Überbrückung verwenden. Ich verwende jetzt nur Host-Only-Networking. Das heißt, die VM ist mit einer separaten NIC (vboxnet0) verbunden. Ich habe eine IPv6-Route hinzugefügt, die den gesamten Datenverkehr vom Host an die IPv6-Adresse der VM weiterleitet:

    ip -6 route add <my IPv6 pefix>::20 dev vboxnet0
    

Auf der VM verwende ich die linklokale IPv6-Adresse des Hosts als Standard-GW. Damit der Host die VM über seine globale IPv6-IP-Adresse verbinden kann, habe ich vboxnet0 eine weitere IP aus demselben/64-Subnetz zugewiesen. Für mich funktioniert das perfekt.