Bitte um Hilfe bei IPv6 in Proxmox-Containern

mcbulba · 24. Dezember 2020

Hallo.

Ich habe jetzt verschiedene Anleitungen u.a. hier aus dem Forum versucht, auf meine Situation anzuwenden, und kriege es trotzdem nicht hin, dass meine Container nach außen kommunizieren können. Vielleicht weiß jemand, wo der Fehler liegt?

Ich habe hier einen KVM RootServer auf dem ich Proxmox-VE 6.3.1 installiert habe. Dort sieht meine /etc/network/interfaces so aus:

Code

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
        address X.X.X.X/22
        gateway X.X.X.1

iface ens3 inet6 static
        address 2a03:4000:X:X::1/128
        gateway fe80::1

        pre-up echo 0 > /proc/sys/net/ipv6/conf/ens3/accept_ra
        pre-up echo 0 > /proc/sys/net/ipv6/conf/ens3/autoconf

auto vmbr0
iface vmbr0 inet static
        address 10.42.1.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0

        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s 10.42.1.0/24 -o ens3 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s 10.42.1.0/24 -o ens3 -j MASQUERADE

iface vmbr0 inet6 static
        address 2a03:4000:X:X:1::1/80

        pre-up echo 0 > /proc/sys/net/ipv6/conf/vmbr0/accept_ra
        pre-up echo 0 > /proc/sys/net/ipv6/conf/vmbr0/autoconf

Alles anzeigen

was zu folgenden Interfaces führt (ip a

Code

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: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether X:X:X:X:X:X brd ff:ff:ff:ff:ff:ff
    inet X.X.X.X/22 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:X:X::1/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::44a8:3eff:fe99:90bb/64 scope link 
       valid_lft forever preferred_lft forever
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether X:X:X:X:X:X brd ff:ff:ff:ff:ff:ff
    inet 10.42.1.1/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:X:X:1::1/80 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5c7a:46ff:fe97:3b2e/64 scope link 
       valid_lft forever preferred_lft forever

Alles anzeigen

Und folgender Routing-Tabelle (ip -6 r

Code

::1 dev lo proto kernel metric 256 pref medium
2a03:4000:X:X::1 dev ens3 proto kernel metric 256 pref medium
2a03:4000:X:X:1::/80 dev vmbr0 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
default via fe80::1 dev ens3 proto kernel metric 1024 onlink pref medium

Außerdem habe ich zwei Container mit debian-10-standard_10.7-1 erstellt, die die Adressen 2a03:4000:X:X:1::2/80 und 2a03:4000:X:X:1::3/80 haben.

Auf dem Host funktioniert nun

Code

ping6 2a03:4000:X:X::1
ping6 2a03:4000:X:X:1::1
ping6 2a03:4000:X:X:1::2
ping6 2a03:4000:X:X:2::3
ping6 google.com

Also Ping zu sich selbst, zu den Containern und nach außen. Soweit so gut.

Von einem Container aus jedoch kann ich z.B. google.com nicht erreichen. Hier habe ich folgende Konfiguration:

Code

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.42.1.2/24
        gateway 10.42.1.1

iface eth0 inet6 static
        address 2a03:4000:X:X:1::2/80
        gateway 2a03:4000:X:X:1::1

Alles anzeigen

ip a:

Code

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: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2e:87:ec:e0:75:62 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.42.1.2/24 brd 10.42.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2a03:4000:X:X:1::2/80 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::2c87:ecff:fee0:7562/64 scope link 
       valid_lft forever preferred_lft forever

Alles anzeigen

ip -6 r:

Code

::1 dev lo proto kernel metric 256 pref medium
2a03:4000:X:X:1::/80 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via 2a03:4000:X:X:1::1 dev eth0 metric 1024 onlink pref medium

Hier funktioniert jetzt auch:

Code

ping6 2a03:4000:X:X::1
ping6 2a03:4000:X:X:1::1
ping6 2a03:4000:X:X:1::2
ping6 2a03:4000:X:X:1::3

Also Pings innerhalb des /80-er Netzes zu den Containern und dem entsprechenden Interface auf dem Host, zum externen Interface vom Host, aber eben nicht nach außen zu google.com

Ich habe auf dem Host auch schon net.ipv6.conf.all.forwarding aktiviert und alles neugestartet. Leider auch kein Erfolg. Kann mir jemand einen Tipp geben, was ich vergessen habe oder falsch mache? iptables-Regeln gibt es bis auf das MASQUERADE für IPv4 keine. Ach ja: und IPv4 funktioniert tadellos.

mcbulba · 24. Dezember 2020

Inzwischen bin ich mal auf die Idee gekommen, mt tcpdump zu schauen, was bei so einem Ping passiert.

Auf dem Host tcpdump -nni ens3 icmp6 während im Container ein Ping6 an google.com läuft:

Code

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
12:54:35.473139 IP6 2a03:4000:X:X:1::2 > 2a00:1450:4001:817::200e: ICMP6, echo request, seq 16, length 64

Also sieht es wohl so aus, als würden die Pakete rausgeschickt werden, aber es kommen schon beim Host keine Antworten mehr an. Ich dachte, durch den Gateway auf meinem Host werden die Pakete von der registrierten MAC-Adresse aus gesendet und entsprechend nicht gefiltert. War das ein Denkfehler und das kann gar nicht ohne NAT funktionieren? Oder dadurch, dass die virtuallen MAC-Adressen registriert und freigeschaltet werden, was aber ja hier keine Option ist.

H6G · 24. Dezember 2020

Zitat von mcbulba

Kann mir jemand einen Tipp geben, was ich vergessen habe oder falsch mache?

NDP Proxy, entweder über den Kernel oder über ndppd: https://www.geeklab.info/2013/05/ipv6-neighbour-proxy/

mcbulba · 24. Dezember 2020

OMG. Vielen Dank. Ich hatte vorher schon in einem Beitrag hier von NDP-Proxy gelesen und hatte das auch über sysctl. aktiviert. Aber ich hatte offenbar den Eintrag für das Device vergessen, denn mit ip -6 neigh add proxy 2a03:4000:X:X:1::2 dev ens3 hat es sofort funktioniert. Danke schön.

Tags