Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

For those if us who do want to run our own NAT64 box, is there a decent Linux option these days? Last time I looked, your options were variations on "this isn't packaged so just compile this source tarball and feed it this non-obvious config"... or OpenBSD which just treats it as a first-class option in pf(?) exactly like nat44. (And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...)

View on HN

It's pretty straightforward. On the router (assuming a recent Debian-based distro):

  mkdir /etc/jool
  echo '{"instance":"nat64-minimal","framework":"netfilter","global":{"pool6":"64:ff9b::/96"}}' > /etc/jool/jool.conf
  apt install jool-dkms jool-tools

On a box behind the NAT:

  curl --resolve one.one.one.one:443:64:ff9b::1.1.1.1 https://one.one.one.one

If you want DNS64, 1.1.1.1 and 8.8.8.8 offer 2606:4700:4700::64 and 2001:4860:4860::6464 respectively or you can configure unbound pretty easily.

    > one.one.one.one:443:64:ff9b::1.1.1.1

Is this a typo or a weird curl-specific address format I've never heard of?

It's the argument to --resolve, not the desired URL.

    --resolve <[+]host:port:addr[,addr]...>
              Provide a custom address for a specific host and port pair. Using this, you can make the curl requests(s)
              use a specified address and prevent the otherwise normally resolved address to be  used.  Consider  it  a
              sort  of  /etc/hosts  alternative provided on the command line.

I looked right past `--resolve`, so yes that now makes sense.

  # apt search jool
  Sorting... Done
  Full Text Search... Done
  jool-dkms/stable 4.1.9-1 all
    kernel-based SIIT and NAT64 (IP/ICMP translation)

  jool-tools/stable 4.1.9-1 amd64
    userspace utilities for the Jool kernel modules

I suppose it is packaged, but dkms is still very much in the "why is does my router need a compiler installed" vibe.

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/nat6...

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?)

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/ 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.

You can refer to 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).

> And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...

If you decide to try OpenBSD I hope you will enjoy it! I personally find it easier to understand and configure than Linux, but I could be biased.

Reply on news.ycombinator.com