IPv6 Proxmox (OVH) funktioniert nur teilweise

Vengance

Member
Hallo!

Ich virtualisiere einige KVM VMs auf meinem Server mittels Proxmox.

Nun habe ich aber das Problem, dass nur manche VMs eine IPv6 Verbindung aufbauen können.
Ich habe momentan 3 VMs laufen, zwei verfügen über eine IPv4 Adresse und eine IPv6 Adresse, diese könenn auch problemlos IPv6 Verbindungen aufbauen.
Zusätzlich läuft eine VM, welche nur über eine IPv6 Adresse verfügt, diese kann nur den Gateway anpingen, danach aber nichtsmehr.


Nun das Merkwürdige, nachdem ich manuell folgenden Befehl ausgeführt habe (was ja eigentlich nicht nötig ist, da sich ndppd darum kümmert) konnte die VM google via IPv6 problemlos anpingen, bis die VM neugestartet wurde, danach nicht mehr, auch bei mehrmaligem Ausführen des Befehls.
Code:
ip -6 neigh add proxy 2001:xxxx:2:8054::601 dev vmbr0

Der Server steht bei OVH und ich habe das IPv6 Setup nach der folgenden Anleitung vorgenommen:
https://gist.github.com/panperla/77c169b1a8a1b745277d67f0979c86fd
Ich stehe nun etwas auf dem Schlauch und versuche rauszufinden ob das Problem an OVH liegt, oder Proxmox.



Mein IPv6 Subnet: 2001:xxxx:2:8054::/64
IPv6 des Hosts und gleichzeitig Gateway: 2001:xxxx:2:8054::
Bsp. IPv6 einer VM: 2001:xxxx:2:8054::601


Hier die Sysctl.conf des Hostsystems:
Code:
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

###################################################################
# Magic system request Key
# 0=disable, 1=enable all
# Debian kernels have this set to 0 (disable the key)
# See https://www.kernel.org/doc/Documentation/sysrq.txt
# for what other values do
#kernel.sysrq=1

###################################################################
# Protected links
#
# Protects against creating or following links under certain conditions
# Debian kernels have both set to 1 (restricted) 
# See https://www.kernel.org/doc/Documentation/sysctl/fs.txt
#fs.protected_hardlinks=0
#fs.protected_symlinks=0
# Disable IPv6 autoconf 
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.accept_ra = 0
net.ipv6.conf.vmbr0.autoconf = 0
net.ipv6.conf.default.proxy_ndp = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.vmbr0.accept_ra_defrtr = 0
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.vmbr0.accept_ra_pinfo = 0


net.ipv6.conf.all.router_solicitations = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.proxy_ndp = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv4.ip_forward = 1

/etc/ndppd.conf des Hosts:
Code:
proxy vmbr0 {
          rule 2001:41d0:2:8054::/64 {
  }
}

Netzwerkconfig einer VM:
Code:
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens18
iface ens18 inet6 static
        address 2001:xxxx:2:8054::601
        netmask 64
        gateway 2001:41d0:2:8054::
 
Last edited by a moderator:
Ich habe gerade mal etwas weiter getestet.

Ich habe einer VM, die vorher nur eine IPv6 Adresse hatte und über diese auch keine Verbindung aufbauen konnte zusätzlich eine IPv4 Adresse gegeben und die Mac Adresse auf die im OVH Manager Generierte geändert und siehe da es funktioniert.

Wenn ich nun die IPv4 Adresse aus der Netzwerkconfig entferne funktioniert es auch weiterhin, sobald ich aber die MAC Adresse gegen eine andere tausche, funktioniert es wieder nicht.

Sehr merkwürdig.
Hat irgendjemand eine Idee? Für mich ergibt das irgendwie immer weniger Sinn.

Grüße
 
Probiere mal für den Server anstelle der IP-Adresse 2001:xxxx:2:8054:: die IP-Adresse 2001:xxxx:2:8054::100/64 zu nehmen.

Falls es dann immer noch nicht gehen sollte, kannst du auch mal als Gateway die IP-Adresse fe80::1 nehmen. Ansonsten auch mal im Kundenbreich schauen, welche IP-Adresse für das Gateway genutzt werden soll.
 
Last edited by a moderator:
Probiere mal für den Server anstelle der IP-Adresse 2001:xxxx:2:8054:: die IP-Adresse 2001:xxxx:2:8054::100/64 zu nehmen.

Falls es dann immer noch nicht gehen sollte, kannst du auch mal als Gateway die IP-Adresse fe80::1 nehmen. Ansonsten auch mal im Kundenbreich schauen, welche IP-Adresse für das Gateway genutzt werden soll.

Hallo,
Danke für deine Antwort.

Ich verstehe nicht ganz inwiefern es etwas helfen soll, die IPv6 des Hostsystems zu ändern. Die /64 Netmask ist bereits angegeben.

Ich nehme auch bewusst die IP des Hostsystems als Gateway, da hierrauf der ndppd proxy läuft.


Netzwerkconfig IPv6 Part Hostsystem:
Code:
iface vmbr0 inet6 static
        address 2001:xxxx:0002:8054::
        netmask 64
        post-up /sbin/ip -f inet6 route add 2001:xxxx:0002:80ff:ff:ff:ff:ff dev vmbr0
        post-up /sbin/ip -f inet6 route add default via 2001:xxxx:0002:80ff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del default via 2001:xxxx:0002:80ff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del 2001:xxxx:0002:80ff:ff:ff:ff:ff dev vmbr0
 
Netzwerkconfig IPv6 Part Hostsystem:
Code:
iface vmbr0 inet6 static
        address 2001:xxxx:0002:8054::
        netmask 64
        post-up /sbin/ip -f inet6 route add 2001:xxxx:0002:80ff:ff:ff:ff:ff dev vmbr0
        post-up /sbin/ip -f inet6 route add default via 2001:xxxx:0002:80ff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del default via 2001:xxxx:0002:80ff:ff:ff:ff:ff
        pre-down /sbin/ip -f inet6 route del 2001:xxxx:0002:80ff:ff:ff:ff:ff dev vmbr0

Ok. Dann probiere mal für den Server anstelle der IP-Adresse 2001:xxxx:2:8054:: die IP-Adresse 2001:xxxx:2:8054::100 zu nutzen. Denn Zurzeit hast du dem Server das ganze Netz 2001:xxxx:2:8054::/64 gegeben.
 
Neue Erkenntnis:
Ich erstelle eine VM mit nur einer IPv6 Adresse und einer beliebigen MAC.
Starte sie neu -> keine Verbindung.

Wenn ich nun aber auf dem Host folgendes ausführe:
ip -6 neigh add proxy IPv6_DER_VM dev vmbr0
bekommt Sie eine Verbindung bis die VM rebootet wird.
Danach aber auch nichtmehr, egal wie oft ich den Befehl erneut ausführe.
Ich habe das ganze jetzt zweimal getestet, sollte also reproduzierbar sein.

Mir kommen nun zwei fragen auf, wieso funktioniert der ndppd proxy nicht und ich muss den Befehl manuell ausführen und wieso geht das ganze nur bis zu einem Neustart der VM und danach nichtmehr?


Vielleicht hat ja jemand eine Idee.
Grüße
 
Bei mir läuft es, habe folgende anpassungen am Server vorgenommen:

/etc/sysctl.conf
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1
net.ipv6.bindv6only = 1

/etc/network/interfaces
iface vmbr2 inet6 static
address 2601:xxxx:xx:xxx::2
netmask 64
bridge_ports none
bridge_stp off
bridge_fd 0
post-up echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
post-up echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
post-up echo 1 > /proc/sys/net/ipv6/conf/default/forwarding
post-up /sbin/ip -f inet6 neigh add proxy 2601:xxxx:xx:xxx::2 dev vmbr2
post-up /sbin/ip -f inet6 neigh add proxy 2601:xxxx:xx:xxx::3 dev vmbr0
post-up /sbin/ip -f inet6 route add 2601:xxxx:xx:xxx::3 dev vmbr2

VM:
iface eth0 inet6 static
address 2601:xxxx:xx:xxx::3
netmask 64
gateway 2601:xxxx:xx:xxx::2

VM hängt an vmbr2, bzw an der v6 Bridge, der Traffic geht dann an vmbr0, die von OVH wenn man Proxmox installiert vorkonfiguriert ist.

Quelle: http://hw7.net/?p=252

Das jetzt aber nur 1 VM, ansonsten ein Discovery Service benutzen, macht das einfacher mit mehreren VM's
 
Last edited by a moderator:
Back
Top