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 …