TNAT64.CONF(5)

🦋 NAME 🦋

okay so this is TNAT64.CONF(5), the manual page for tnat64.conf — the literal configuration file for tnat64(8). she's a file-formats-manual girlie and she's here to spill 💅

---

✨ OVERVIEW ✨

bestie, the config for tnat64 can be anything. like, two lines. like, hundreds of lines. it fully depends on what your site needs at any given moment, no cap. the basic idea is simple tho: you define any networks this machine can reach directly over IPv4, and then you define one or many NAT64 prefixes to use for reaching everything else (including a default prefix, because of course there's a default 🎀).

Local networks get declared with the local keyword in the config file. when an app tries to connect to a machine in a network marked as local, tnat64 will not try to use a NAT64 prefix. she knows the way, she doesn't need the middleman 💅

obviously tho — if a connection is not to a locally accessible network, it's gonna need to be proxied over a NAT64. and here's the plot twist: sometimes you need different NAT64 prefixes to reach different internal (and external) networks. iconic, honestly. that's exactly why the config file lets you define paths and a default NAT64 prefix 🫶

Paths are declared as blocks in the config file. meaning: they start with a path { line and end with a } line. inside that block you use directives to declare a NAT64 proxy (documented further down this page, keep scrolling bestie) and subnet directives to declare networks — and even destination ports inside those networks — that this server should be used to reach.

⚠️ heads up fr fr: each path MUST define a NAT64 prefix and contain one or more subnet directives. that's not a vibe suggestion, that's a requirement 💀

NAT64 prefix declaration directives that are not inside a path block define the default NAT64 prefix. so if tnat64 needs to connect to a machine via a NAT64 (i.e. it isn't a network declared as local) and no path has declared — via a subnet directive — that it can reach that network, then this NAT64 prefix is used to construct IPv6 addresses. she's the fallback queen 👑

---

🌈 CONFIGURATION SYNTAX 🌈

the basic structure of every line in the config file is:

<directive> = <parameters>

the exception to this is path blocks, which look like:

path {
       <directive> = <parameters>
}

Empty lines are ignored. and everything on a line after a # character is ignored too — comment your heart out, bestie ✨

🎀 DIRECTIVES 🎀

these are the directives used in the tnat64 config file:

• nat64_prefix — the prefix of the IPv6 address of the NAT64 (e.g. "nat64_prefix = 64:ff9b::"). Only one NAT64 prefix may be specified per path block, or one outside a path block (which is how you define the default NAT64 prefix). the NAT64 prefix is always /96, periodt.
• local — an IP/subnet pair specifying a network which may be accessed directly, without proxying through NAT64 (e.g. "local = 10.0.0.0/255.0.0.0"). no middleman needed 💖
• subnet — this directive is only valid inside a path block. its parameter is formed as IP[:startport[-endport]]/subnet, and it specifies a network (and a range of ports on that network) that can be accessed through the NAT64 specified in this path block. for example, inside a path block, "subnet = 150.0.0.0:80-1024/255.0.0.0" tells tnat64 that the NAT64 prefix specified in the current path block should be used to access any IPs in the range 150.0.0.0 to 150.255.255.255 when the connection request is for ports 80-1024. that's the whole assignment, slay 🔥

---

🧚 UTILITIES 🧚

tnat64 comes with two utilities that are genuinely useful for creating and verifying the tnat64 configuration file. yes, two. she brought friends 🫶

• tnat64-validateconf — tnat64-validateconf can be used to verify the configuration file. it checks the format of the file and also the contents for errors. once it's read the file, it dumps the configuration to the screen in a formatted, readable manner. this can be extremely useful when you're debugging problems, bestie 😭

tnat64-validateconf can read a configuration file from a location other than the location specified at compile time, using the -f <filename> command line option.

normally tnat64-validateconf just dumps the configuration it read to the screen (in a nicely readable format), but it also has a genuinely useful test mode. when you pass it a hostname/ip on the command line like -t <hostname/ip>, tnat64-validateconf determines which of the NAT64 prefixes specified in the configuration file would be used by tnat64 to access the specified host. it's giving psychic, but make it diagnostics 🔮

---

👑 SEE ALSO 👑

tnat64(8)

---

💜 AUTHORS 💜

Andrej Shadura (andrew@shadura.me), Shaun Clowes (delius@progsoc.uts.edu.au)

---

🌸 COPYRIGHT 🌸

Copyright 2011 Andrej Shadura

Original tsocks manual page, copyright 2000 Shaun Clowes

tnat64 and its documentation may be freely copied under the terms and conditions of version 2 of the GNU General Public License, as published by the Free Software Foundation (Cambridge, Massachusetts, United States of America).

This documentation is heavily based on the documentation for tsocks, transparent SOCKSification library, whose documentation itself is based on the documentation for logwrites, another shared library interceptor. One line of code from it was used in tnat64 and a lot of the documentation :) logwrites is by adam@yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com pub/dist/pkg

---

okay that's the whole page, bestie 💖 this was TNAT64.CONF(5), brought to you by TNAT64 — the source of all this wisdom — and she's filed under section 5, the file formats one, iykyk. go forth and configure responsibly 🎀✨🦋