File: tnat64.conf.5

package info (click to toggle)
tnat64 0.05-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, jessie, jessie-kfreebsd, stretch, wheezy
  • size: 220 kB
  • ctags: 71
  • sloc: ansic: 1,064; sh: 45; makefile: 41
file content (130 lines) | stat: -rw-r--r-- 4,993 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
.TH TNAT64.CONF 5 "" "TNAT64" \" -*-
 \" nroff -*

.SH NAME
.BR tnat64.conf
\- configuration file for tnat64(8)

.SH OVERVIEW

The configuration for tnat64 can be anything from two lines to hundreds of 
lines based on the needs at any particular site. The basic idea is to define 
any networks the machine can access directly via IPv4
and define one or many NAT64 prefixes to be used to access
other networks (including a 'default' prefix).

Local networks are declared using the 'local' keyword in the configuration 
file. When applications attempt to connect to machines in networks marked
as local tnat64 will not attempt to use a NAT64 prefix.

Obviously if a connection is not to a locally accessible network it will need
to be proxied over a NAT64. However, sometimes you may need to use 
different NAT64 prefixes to access different internal (and external)
networks. For this reason the configuration file allows the definition of 'paths'
as well as a default NAT64 prefix.

Paths are declared as blocks in the configuration file. That is, they begin
with a 'path {' line in the configuration file and end with a '}' line. Inside
this block directives should be used to declare a NAT64 proxy (as documented
later in this manual page) and 'subnet' directives should be used to declare 
networks and even destination ports in those networks that this server should 
be used to reach. Please note that each path MUST define a NAT64 prefix and 
contain one or more 'subnet' directives.

NAT64 prefix declaration directives that are not contained within a 'path' 
block define the default NAT64 prefix. 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 it can reach that network via a 'subnet' directive,
this NAT64 prefix is used to construct IPv6 addresses.

.SH CONFIGURATION SYNTAX

The basic structure of all lines in the configuration file is:

.RS
<directive> = <parameters>
.RE

The exception to this is 'path' blocks which look like:

.RS
path {
.RS
<directive> = <parameters>
.RE
}
.RE

Empty lines are ignored and all input on a line after a '#' character is 
ignored.

.SS DIRECTIVES 
The following directives are used in the tnat64 configuration file:

.TP
.I nat64_prefix
The prefix of 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 (to define the default NAT64 prefix). The NAT64 prefix is always /96.

.TP
.I 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"). 

.TP
.I 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 by through NAT64 specified
in this path block. For example, in a path block "subnet =
150.0.0.0:80\-1024/255.0.0.0" indicates to 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.

.SH UTILITIES
tnat64 comes with two utilities that can be useful in creating and verifying
the tnat64 configuration file. 

.TP
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. Having read the file it dumps 
the configuration to the screen in a formatted, readable manner. This can be 
extremely useful in debugging problems.

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

Normally tnat64-validateconf simply dumps the configuration read to the screen (in
a nicely readable format), however it also has a useful 'test' mode. When
passed 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. 

.SH SEE ALSO
tnat64(8)

.SH AUTHORS
Andrew O. Shadura (bugzilla@tut.by),
Shaun Clowes (delius@progsoc.uts.edu.au)

.SH COPYRIGHT
Copyright 2011 Andrew O. 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