4 ms·

I haven't tried NAT64 on a Linux router, so I can't say authoritatively. I did a similar experiment as the submitted article back in 2020, though that was on a

I haven't tried NAT64 on a Linux router, so I can't say authoritatively. I did a similar experiment as the submitted article back in 2020, though that was on a pfSense (FreeBSD) router, not Linux. I used tayga for NAT64 there, which was last released in 2010, but it probably still works on modern Linux. At the very least it's still packaged in Debian. Someone has made a NAT64 implementation using eBPF, though with quite some caveats: https://github.com/xdp-project/bpf-examples/tree/master/nat64-bpf https://github.com/xdp-project/bpf-examples/tree/master/nat6...

qhwudbebd 2y ago
The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware. Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in. I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies. (What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)
yjftsjthsd-h 2y ago
So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work. The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.
- Arnavion 2y ago
  You can refer to https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-network-to-ipv6/#level-4-turn-off-ipv4-aka-how-to-run-tayga-on-pfsense https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-... which is about my pfSense attempt. It has the six-line tayga config and hopefully enough surrounding explanation to make it clear, and then instead of the rc script I had to write you can just make a systemd service or whatever you use. Debian's package already comes with an init.d script (not a systemd unit, but presumably it works with systemctl via sysv-generator).

qhwudbebd 2y ago

The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware. Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in. I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies. (What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)

yjftsjthsd-h 2y ago

So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work. The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.

Arnavion 2y ago
You can refer to https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-network-to-ipv6/#level-4-turn-off-ipv4-aka-how-to-run-tayga-on-pfsense https://www.arnavion.dev/blog/2020-04-18-i-switched-my-home-... which is about my pfSense attempt. It has the six-line tayga config and hopefully enough surrounding explanation to make it clear, and then instead of the rc script I had to write you can just make a systemd service or whatever you use. Debian's package already comes with an init.d script (not a systemd unit, but presumably it works with systemctl via sysv-generator).