ip6t_NPT go home, you’re drunk

Seriöslich jetzt? IPv6 DNPT verrechnet sich bei der Zieladresse, das ist weniger lustig als es klingt.

Jaja, ich weiß, wer bei IPv6 an NAT auch nur denkt, frißt auch kleine Kinder. Wobei, in töfter Minzsoße … Just kidding.

Anyway. Nachdem ISPs für IPv4-Adressen mittlerweile monatliche Zuschläge verlangen und IPv6 NPT vor ~5 Jahren eigentlich recht schnuckelig lief, dachte ich mir, warum mit teuren v4-Adressen rumärgern, rausgehend kann ich v4 auf die Host-IP NATen und IPv6 einfach prefixtranslaten, darüber habe ich einen bequemen ssh-Rückweg.

Gedacht, konfiguriert:

root@test ~ # ip6tables -L -t mangle -v
Chain PREROUTING (policy ACCEPT 17160 packets, 1536K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   15  1200 DNPT       all      enp9s0 any     anywhere            !test                 DNPT src-pfx 2001:db8:3b:5822::/64 dst-pfx fd00:deca:fbad::/64

Chain INPUT (policy ACCEPT 17145 packets, 1535K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 15 packets, 1200 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 15850 packets, 1581K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 15865 packets, 1583K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNPT       all      any    enp9s0  fd00:deca:fbad::/64  anywhere             SNPT src-pfx fd00:deca:fbad::/64 dst-pfx 2001:db8:3b:5822::/64
 245M   21G LIBVIRT_PRT  all      any    any     anywhere             anywhere            

Chain LIBVIRT_PRT (1 references)
 pkts bytes target     prot opt in     out     source               destination         

Das sollte alles, was aus fd00:deca:fbad::/64 kommt, im POSTROUTING auf 2001:db8:3b:5822::/64 umadressieren — das tut auch mit ping6. Aber UDP (traceroute -6) oder TCP geht gar nicht, egal, in welche Richtung, und das guckte ich mir dann mal »on the wire« an:

04:23:05.590336 IP6 2001:db8:260c:1:88d9:8786:e303:f63d.39890 > 2001:db8:3b:5822:ffff:c0ff:fe58:6304.22: Flags [S], seq 3635894725, win 64320, options [mss 1340,sackOK,TS val 4438358 ecr 0,nop,wscale 7], length 0
04:23:05.599231 IP6 fe80::de:ca:fb:ad > ff02::1:ff58:6304: ICMP6, neighbor solicitation, who has fd00:deca:fbad:0:ffff:70dd:fe58:6304, length 32

Genau: Statt 2001:­db8:­3b:­5822:­ffff:­c0ff:­fe58:­6304 zu fd00:­deca:­fbad:­0:­ffff:­c0ff:­fe58:­6304 zu machen, wird nach fd00:­deca:­fbad:­0:­ffff:­70dd:­fe58:­6304 gesucht. Hä?!

Kernel: Linux test 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Irgendwie scheint sich ip6t_NPT.ko da komplett zu verhaspeln, oder was mache ich falsch?

04:39:36.407306 IP6 2001:db8:260c:1:88d9:8786:e303:f63d.41118 > 2001:db8:3b:5822:0:c0ff:fe58:6304.22: Flags [S], seq 2499456358, win 64320, options [mss 1340,sackOK,TS val 3719926904 ecr 0,nop,wscale 7], length 0
04:39:36.411231 IP6 fe80::de:ca:fb:ad > ff02::1:ff58:6304: ICMP6, neighbor solicitation, who has fd00:deca:fbad:0:afdd:c0ff:fe58:6304, length 32

Ernsthaft jetzt‽

Nachtrag: Mit Kernel 5.13.0-28-generic klappt zumindest ein ausgehender traceroute -6. Eingehende Verbindungen: weiterhin nope.

Aber es steht nun auch das NETMAP-Target zur Verfügung. Allein: das führt zu NDP-Anfragen auf dem externen Interface; mein 2001:db8:3b:5822::/64 ist auf dem internet-facing Interface, fd00:deca:fbad:0::/64 allerdings residiert auf br-nat. Muß ich wirklich noch ndppd hinzuziehen? Meh …