1TSOCKS.CONF(5) File Formats Manual TSOCKS.CONF(5)
2
3
4
6 tsocks.conf - configuration file for tsocks(8)
7
8
10 The configuration for tsocks can be anything from two lines to hundreds
11 of lines based on the needs at any particular site. The basic idea is
12 to define any networks the machine can access directly (i.e without the
13 use of a SOCKS server) and define one or many SOCKS servers to be used
14 to access other networks (including a 'default' server).
15
16 Local networks are declared using the 'local' keyword in the configura‐
17 tion file. When applications attempt to connect to machines in networks
18 marked as local tsocks will not attempt to use a SOCKS server to nego‐
19 tiate the connection.
20
21 Obviously if a connection is not to a locally accessible network it
22 will need to be proxied over a SOCKS server. However, many installa‐
23 tions have several different SOCKS servers to be used to access differ‐
24 ent internal (and external) networks. For this reason the configuration
25 file allows the definition of
26
27 Paths are declared as blocks in the configuration file. That is, they
28 begin with a 'path {' line in the configuration file and end with a '}'
29 line. Inside this block directives should be used to declare a SOCKS
30 server (as documented later in this manual page) and 'reaches' direc‐
31 tives should be used to declare networks and even destination ports in
32 those networks that this server should be used to reach. N.B Each path
33 MUST define a SOCKS server and contain one or more 'reaches' direc‐
34 tives.
35
36 SOCKS server declaration directives that are not contained within a
37 'path' block define the default SOCKS server. If tsocks needs to con‐
38 nect to a machine via a SOCKS server (i.e it isn't a network declared
39 as 'local') and no 'path' has declared it can reach that network via a
40 'reaches' directive this server is used to negotiate the connection.
41
42
44 The basic structure of all lines in the configuration file is:
45
46 <directive> = <parameters>
47
48 The exception to this is 'path' blocks which look like:
49
50 path {
51 <directive> = <parameters>
52 }
53
54 Empty lines are ignored and all input on a line after a '#' character
55 is ignored.
56
57
58 DIRECTIVES
59 The following directives are used in the tsocks configuration file:
60
61
62 server The IP address of the SOCKS server (e.g "server = 10.1.4.253").
63 Only one server may be specified per path block, or one outside
64 a path block (to define the default server). Unless --disable-
65 hostnames was specified to configure at compile time the server
66 can be specified as a hostname (e.g "server = socks.nec.com")
67
68
69 server_port
70 The port on which the SOCKS server receives requests. Only one
71 server_port may be specified per path block, or one outside a
72 path (for the default server). This directive is not required if
73 the server is on the standard port (1080).
74
75
76 server_type
77 SOCKS version used by the server. Versions 4 and 5 are supported
78 (but both for only the connect operation). The default is 4.
79 Only one server_type may be specified per path block, or one
80 outside a path (for the default server).
81
82 You can use the inspectsocks utility to determine the type of
83 server, see the 'UTILITIES' section later in this manual page.
84
85
86 default_user
87 This specifies the default username to be used for username and
88 password authentication in SOCKS version 5. In order to deter‐
89 mine the username to use (if the socks server requires username
90 and password authentication) tsocks first looks for the environ‐
91 ment variable TSOCKS_USERNAME, then looks for this configuration
92 option, then tries to get the local username. This option is
93 not valid for SOCKS version 4 servers. Only one default_user may
94 be specified per path block, or one outside a path (for the
95 default server)
96
97
98 default_pass
99 This specified the default password to be used for username and
100 password authentication in SOCKS version 5. In order to deter‐
101 mine the password to use (if the socks server requires username
102 and password authentication) tsocks first looks for the environ‐
103 ment variable TSOCKS_PASSWORD, then looks for this configuration
104 option. This option is not valid for SOCKS version 4 servers.
105 Onle one default_pass may be specified per path block, or one
106 outside a path (for the default server)
107
108
109 local An IP/Subnet pair specifying a network which may be accessed
110 directly without proxying through a SOCKS server (e.g "local =
111 10.0.0.0/255.0.0.0"). Obviously all SOCKS server IP addresses
112 must be in networks specified as local, otherwise tsocks would
113 need a SOCKS server to reach SOCKS servers.
114
115
116 reaches
117 This directive is only valid inside a path block. Its parameter
118 is formed as IP[:startport[-endport]]/Subnet and it specifies a
119 network (and a range of ports on that network) that can be
120 accessed by the SOCKS server specified in this path block. For
121 example, in a path block "reaches = 150.0.0.0:80-1024/255.0.0.0"
122 indicates to tsocks that the SOCKS server specified in the cur‐
123 rent path block should be used to access any IPs in the range
124 150.0.0.0 to 150.255.255.255 when the connection request is for
125 ports 80-1024.
126
127
129 tsocks comes with two utilities that can be useful in creating and ver‐
130 ifying the tsocks configuration file.
131
132
133 inspectsocks
134 inspectsocks can be used to determine the SOCKS version that a
135 server supports. Inspectsocks takes as its arguments the ip
136 address/hostname of the SOCKS server and optionally the port
137 number for socks (e.g 'inspectsocks socks.nec.com 1080'). It
138 then inspects that server to attempt to determine the version
139 that server supports.
140
141
142 validateconf
143 validateconf can be used to verify the configuration file. It
144 checks the format of the file and also the contents for errors.
145 Having read the file it dumps the configuration to the screen in
146 a formatted, readable manner. This can be extremely useful in
147 debugging problems.
148
149 validateconf can read a configuration file from a location other
150 than the location specified at compile time with the -f <file‐
151 name> command line option.
152
153 Normally validateconf simply dumps the configuration read to the
154 screen (in a nicely readable format), however it also has a use‐
155 ful 'test' mode. When passed a hostname/ip on the command line
156 like -t <hostname/ip>, validateconf determines which of the
157 SOCKS servers specified in the configuration file would be used
158 by tsocks to access the specified host.
159
160
162 tsocks(8)
163
164
166 Shaun Clowes (delius@progsoc.uts.edu.au)
167
168
170 Copyright 2000 Shaun Clowes
171
172 tsocks and its documentation may be freely copied under the terms and
173 conditions of version 2 of the GNU General Public License, as published
174 by the Free Software Foundation (Cambridge, Massachusetts, United
175 States of America).
176
177 This documentation is based on the documentation for logwrites, another
178 shared library interceptor. One line of code from it was used in tsocks
179 and a lot of the documentation :) logwrites is by adam@yggdrasil.com
180 (Adam J. Richter) and can be had from ftp.yggdrasil.com pub/dist/pkg
181
182
183
184Shaun Clowes TSOCKS.CONF(5)