IPv6 Traffic forwarding geht nicht

Autchirion

Hallo,

ich habe eine Verbindung zwischen zwei Servern (einer hier der VPS) via wireguard. Ich möchte Traffic der bei dem VPS hier ankommt zu dem anderen Server routen. Das ganze klappt auch großartig für IPv4, nur nicht für IPv6.

Das hier benutze ich um den Traffic zu forwarden:

Code

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv6.conf.all.forwarding=1

# routing Prep
nft add table nat
nft 'add chain nat postrouting { type nat hook postrouting priority 100 ; }'
nft 'add chain nat prerouting { type nat hook prerouting priority -100; }'
nft add table ip6 nat
nft 'add chain ip6 nat postrouting { type nat hook postrouting priority 100 ; }'
nft 'add chain ip6 nat prerouting { type nat hook prerouting priority -100 ; }'


# Port forwarding for IPv4
nft 'add rule nat prerouting ip daddr 1.2.3.4 tcp dport { 80 } dnat 1.2.3.9'
nft 'add rule nat prerouting ip daddr 1.2.3.4 tcp dport { 443 } dnat 1.2.3.9'

nft 'add rule ip6 nat prerouting ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 80 dnat 1:2:3:4:5:6:7:9'
nft 'add rule ip6 nat prerouting ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 443 dnat 1:2:3:4:5:6:7:9'

# Packet masquerading
nft add rule nat postrouting masquerade

Alles anzeigen

Und das hier ist die Ausgabe von ip address:

Code

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ca:6a:75:6d:46:a5 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet 1.2.3.4/22 brd 1.2.3.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 1:2:3:4::c86a:75ff:fe6d:46a6/64 scope global
       valid_lft forever preferred_lft forever
    inet6 1:2:3:4:c86a:75ff:fe6d:46a5/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::c86a:75ff:fe6d:46a5/64 scope link
       valid_lft forever preferred_lft forever

Alles anzeigen

Ich kann alle IPs (also auch die iPv6) von außen pingen, das ist absolut kein Problem, nur der Traffic kommt nicht an.Entsprechend frage ich mich ob ich da irgendwas übersehen habe was vlt. netcup speziell ist oder ob ich sonnst einen Fehler in meiner Config habe.

Danke schon mal

Autchi

KB19

Wenn Du kein zusätzliches IPv6-Subnetz hast (das direkt geroutet wird), brauchst Du wahrscheinlich einen NDP-Proxy. Siehe ip -6 neigh add proxy …, bzw. falls es viele Adressen sind z.B. ndppd.

Autchirion

Ich habe gerade mal ip -6 neigh add proxy 1:2:3:4:c86a:75ff:fe6d:46a5 dev eth0 ausgeführt, bringt leider keine Veränderung im Verhalten.

Habe jetzt aber auch mal ip neighbor show ausgeführt und das hier bekommen:

Code

172.18.0.2 dev br-a5846efba401 lladdr 02:42:ac:12:00:02 REACHABLE
45.142.176.1 dev eth0 lladdr 00:00:5e:00:01:01 REACHABLE
172.17.0.2 dev docker0 lladdr 02:42:ac:11:00:02 STALE
45.142.176.2 dev eth0 lladdr bc:0f:fe:33:fc:e3 STALE
45.142.176.3 dev eth0 lladdr bc:0f:fe:37:fb:a3 STALE
fe80::be0f:fe00:a833:fce3 dev eth0 lladdr bc:0f:fe:33:fc:e3 router STALE
1:2:3::3 dev eth0 FAILED
fe80::1 dev eth0 lladdr 00:00:5e:00:02:02 router REACHABLE
1:2:3::2 dev eth0 FAILED
fe80::be0f:fe00:a837:fba3 dev eth0 lladdr bc:0f:fe:37:fb:a3 router STALE

Was ich jetzt nicht ganz verstehe, ich habe eigentlich nur 1:2:3:4::/64, aber irgendwie sagt es was über die neighbors 1:2:3::3 und 1:2:3::2.

Bin jetzt vollends verwirrt, das Problem ist, ich gehe hier auch mit gefährlichem Halbwissen dran, grundlegendes Verständnis von IPv4 ist da, aber das übertrage ich relativ nur auf IPv6, da kenne ich die Regeln nicht (das war wohl vor 12 Jahren noch "zu neu" um im Studium gelehrt zu werden, aber wird auch jetzt noch nicht).

H6G

Sieht soweit gut aus, wie schauen deine wireguard allowed IPs aus und was passiert, wenn du auf den einzelnen (Tunnel)-Interfaces mit tcpdump dir den Verkehr anguckst?

Evtl. fehlt einfach nur eine Rückroute.

Zitat von Autchirion

Bin jetzt vollends verwirrt, das Problem ist, ich gehe hier auch mit gefährlichem Halbwissen dran, grundlegendes Verständnis von IPv4 ist da, aber das übertrage ich relativ nur auf IPv6, da kenne ich die Regeln nicht (das war wohl vor 12 Jahren noch "zu neu" um im Studium gelehrt zu werden, aber wird auch jetzt noch nicht).

Kann man ganz gut übertragen, außer bei ARP und der spezifischen L2 Implementation.

Autchirion

danke für den tipp mit tcpdump, da hätte ich auch vorher selbst drauf kommen können. Komplett komisches verhalten, ich kann die IP pingen, das wird in tcpdump auch angezeigt, aber sobald ich per http(s) darauf zugreife geht nichts (auch nicht in tcpdump)... habe jetzt auch mal andere Ports probiert geht genau so wenig, irgendwie scheint es mir fast so als würde da noch eine Firewall oder so laufen. Ich habe aber mal sudo ufw status ausgeführt, das gibt mir aus, dass ufw gar nicht installiert ist.

Es wird immer komischer, so sollte IPv6 sich doch nicht verhalten oder übersehe ich da was?

H6G

Zitat von Autchirion

scheint es mir fast so als würde da noch eine Firewall oder so laufen

Naja, du hast ja eine Firewall laufen:

Code

nft 'add rule ip6 nat prerouting ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 80 dnat 1:2:3:4:5:6:7:9'
nft 'add rule ip6 nat prerouting ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 443 dnat 1:2:3:4:5:6:7:9'

Wenn ich jetzt keinen Denkfehler habe: brauchst du dazu nicht noch eine snat Regel? Kann aber auch eine Finte sein.

Was häufig passiert bei ICMP funktioniert, aber TCP nicht: MTU Fehler. Welche MTU haben die Wireguard Interfaces und funktioniert auch ein Ping mit größerer Payload (ggf. mit DNF Bit gesetzt)?

Edit:
snat hast du ja drinne (siehe masquerade nft add rule nat postrouting masquerade) - muss das auch noch explizit für IPv6 gesetzt werden?

Autchirion

ich habe mal nft list ruleset ausgeführt und rein geschaut, für mich sieht es so aus als wäre das bei IPv6 auch drin.

Das mit der MTU ist auch ein guter Gedanke, aber ich bin per Kabel angebunden, das heißt die Default MTU von 1420 sollte perfekt sein. Ich habe mal ping -s 1372 -M do fd00:0:0:0:0042:c0ff:fea8:01c1 durchgeführt, das geht wunderbar durch. Wenn ich es über 1372 drehe geht es natürlich nicht mehr, dann haben wir mehr Protokoll overhead.

Code

table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }
}
# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                masquerade
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                ip daddr 1.2.3.4 tcp dport 80 dnat to 192.168.1.241
                ip daddr 1.2.3.4 tcp dport 443 dnat to 192.168.1.241
        }

        chain DOCKER {
                iifname "docker0" counter packets 0 bytes 0 return
                iifname "br-6a1b61d22aef" counter packets 0 bytes 0 return
                iifname "br-a5846efba401" counter packets 0 bytes 0 return
                iifname != "docker0" tcp dport 9443 counter packets 0 bytes 0 dnat to 172.17.0.2:9443
                iifname != "br-a5846efba401" tcp dport 9393 counter packets 1 bytes 64 dnat to 172.18.0.2:9393
                iifname != "br-a5846efba401" tcp dport 9292 counter packets 0 bytes 0 dnat to 172.18.0.2:9292
                iifname != "docker0" tcp dport 8000 counter packets 0 bytes 0 dnat to 172.17.0.2:8000
        }

        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
                ip saddr 172.17.0.0/16 oifname != "docker0" counter packets 0 bytes 0 masquerade
                ip saddr 172.25.0.0/16 oifname != "br-6a1b61d22aef" counter packets 0 bytes 0 masquerade
                ip saddr 172.18.0.0/16 oifname != "br-a5846efba401" counter packets 2 bytes 120 masquerade
                ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 9443 counter packets 0 bytes 0 masquerade
                ip saddr 172.18.0.2 ip daddr 172.18.0.2 tcp dport 9393 counter packets 0 bytes 0 masquerade
                ip saddr 172.17.0.2 ip daddr 172.17.0.2 tcp dport 8000 counter packets 0 bytes 0 masquerade
                ip saddr 172.18.0.2 ip daddr 172.18.0.2 tcp dport 9292 counter packets 0 bytes 0 masquerade
        }

        chain PREROUTING {
                type nat hook prerouting priority dstnat; policy accept;
                fib daddr type local counter packets 117 bytes 8354 jump DOCKER
        }

        chain OUTPUT {
                type nat hook output priority dstnat; policy accept;
                ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
        }
}
table ip6 nat {
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 80 dnat to fd00::42:c0ff:fea8:1c1
                ip6 daddr 1:2:3:4:c86a:75ff:fe6d:46a6 tcp dport 443 dnat to fd00::42:c0ff:fea8:1c1
        }
}
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
        chain DOCKER {
                ip daddr 172.17.0.2 iifname != "docker0" oifname "docker0" tcp dport 9443 counter packets 0 bytes 0 accept
                ip daddr 172.18.0.2 iifname != "br-a5846efba401" oifname "br-a5846efba401" tcp dport 9393 counter packets 1 bytes 64 accept
                ip daddr 172.18.0.2 iifname != "br-a5846efba401" oifname "br-a5846efba401" tcp dport 9292 counter packets 0 bytes 0 accept
                ip daddr 172.17.0.2 iifname != "docker0" oifname "docker0" tcp dport 8000 counter packets 0 bytes 0 accept
        }

        chain DOCKER-ISOLATION-STAGE-1 {
                iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
                iifname "br-6a1b61d22aef" oifname != "br-6a1b61d22aef" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
                iifname "br-a5846efba401" oifname != "br-a5846efba401" counter packets 113 bytes 49157 jump DOCKER-ISOLATION-STAGE-2
                counter packets 355 bytes 129018 return
        }

        chain DOCKER-ISOLATION-STAGE-2 {
                oifname "docker0" counter packets 0 bytes 0 drop
                oifname "br-6a1b61d22aef" counter packets 0 bytes 0 drop
                oifname "br-a5846efba401" counter packets 0 bytes 0 drop
                counter packets 113 bytes 49157 return
        }

        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                counter packets 355 bytes 129018 jump DOCKER-USER
                counter packets 355 bytes 129018 jump DOCKER-ISOLATION-STAGE-1
                oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
                oifname "docker0" counter packets 0 bytes 0 jump DOCKER
                iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
                iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
                oifname "br-6a1b61d22aef" ct state related,established counter packets 0 bytes 0 accept
                oifname "br-6a1b61d22aef" counter packets 0 bytes 0 jump DOCKER
                iifname "br-6a1b61d22aef" oifname != "br-6a1b61d22aef" counter packets 0 bytes 0 accept
                iifname "br-6a1b61d22aef" oifname "br-6a1b61d22aef" counter packets 0 bytes 0 accept
                oifname "br-a5846efba401" ct state related,established counter packets 125 bytes 56879 accept
                oifname "br-a5846efba401" counter packets 1 bytes 64 jump DOCKER
                iifname "br-a5846efba401" oifname != "br-a5846efba401" counter packets 113 bytes 49157 accept
                iifname "br-a5846efba401" oifname "br-a5846efba401" counter packets 0 bytes 0 accept
        }

        chain DOCKER-USER {
                counter packets 355 bytes 129018 return
        }
}

Alles anzeigen

H6G

Zitat von Autchirion

table ip6 nat { chain postrouting { type nat hook postrouting priority srcnat; policy accept; }

Da fehlt zumindest das masquerade - so kommt das Paket zumindest mit einer Global Routable Address als Source am anderen Ende an.

Ich kenne mich mit nftables nicht aus, aber in der IPv4 Chain ist zumindest das masquerade markiert - unabhängig von der Richtung.

Ich würde hier das NAT auch auf die Tunnelrichtung beschränken.

Auch wenn es theoretisch funktionieren könnte, ist NAT bei IPv6 nicht wirklich verbreitet. Würde hier auch ein Reverse Proxy oder ein Routing Setup mehr Sinn machen?