1 |
pcg |
1.1 |
=head1 NAME |
2 |
|
|
|
3 |
|
|
gvpe.conf - configuration file for the GNU VPE daemon |
4 |
|
|
|
5 |
|
|
=head1 SYNOPSIS |
6 |
|
|
|
7 |
pcg |
1.21 |
# global options for all nodes |
8 |
pcg |
1.1 |
udp-port = 407 |
9 |
|
|
mtu = 1492 |
10 |
|
|
ifname = vpn0 |
11 |
|
|
|
12 |
pcg |
1.21 |
# first node is named branch1 and is at 1.2.3.4 |
13 |
pcg |
1.1 |
node = branch1 |
14 |
|
|
hostname = 1.2.3.4 |
15 |
|
|
|
16 |
pcg |
1.21 |
# second node uses dns to resolve the address |
17 |
pcg |
1.1 |
node = branch2 |
18 |
|
|
hostname = www.example.net |
19 |
|
|
udp-port = 500 # this host uses a different udp-port |
20 |
|
|
|
21 |
pcg |
1.21 |
# third node has no fixed ip address |
22 |
pcg |
1.1 |
node = branch3 |
23 |
|
|
connect = ondemand |
24 |
|
|
|
25 |
|
|
=head1 DESCRIPTION |
26 |
|
|
|
27 |
|
|
The gvpe config file consists of a series of lines that contain C<variable |
28 |
|
|
= value> pairs. Empty lines are ignored. Comments start with a C<#> and |
29 |
|
|
extend to the end of the line. They can be used on their own lines, or |
30 |
pcg |
1.13 |
after any directives. Whitespace is allowed around the C<=> sign or after |
31 |
|
|
values, but not within the variable names or values themselves. |
32 |
pcg |
1.1 |
|
33 |
root |
1.28 |
All settings are applied "in order", that is, later settings of the same |
34 |
|
|
variable overwrite earlier ones. |
35 |
|
|
|
36 |
|
|
The only exceptions to the above are the "on" and "include" directives: |
37 |
|
|
|
38 |
|
|
=over 4 |
39 |
|
|
|
40 |
|
|
=item on nodename ... |
41 |
pcg |
1.1 |
|
42 |
root |
1.28 |
=item on !nodename ... |
43 |
|
|
|
44 |
|
|
You can prefix any configuration directive with C<on> and a nodename. GVPE |
45 |
|
|
will will only "execute" it on the named node, or (if the nodename starts |
46 |
|
|
with C<!>) on all nodes except the named one. |
47 |
|
|
|
48 |
|
|
Example: set the MTU to C<1450> everywhere, C<loglevel> to C<noise> on |
49 |
|
|
C<branch1>, and C<connect> to C<ondemand> everywhere but on branch2. |
50 |
pcg |
1.21 |
|
51 |
|
|
mtu = 1450 |
52 |
pcg |
1.1 |
on branch1 loglevel = noise |
53 |
|
|
on !branch2 connect = ondemand |
54 |
|
|
|
55 |
root |
1.28 |
=item include relative-or-absolute-path |
56 |
|
|
|
57 |
|
|
Reads the specified file (the path must not contain whitespace or C<=> |
58 |
|
|
characters) and evaluate all config directives in it as if they were |
59 |
|
|
spelled out in place of the C<include> directive. |
60 |
|
|
|
61 |
|
|
The path is a printf format string, that is, you must escape any C<%> |
62 |
|
|
by doubling it, and you can have a single C<%s> inside, which will be |
63 |
|
|
replaced by the current nodename. |
64 |
|
|
|
65 |
|
|
Relative paths are interpreted relative to the GVPE config directory. |
66 |
|
|
|
67 |
|
|
Example: include the file F<local.conf> in the config directory on every |
68 |
|
|
node. |
69 |
|
|
|
70 |
|
|
include local.conf |
71 |
|
|
|
72 |
|
|
Example: include a file F<conf/>nodenameF<.conf> |
73 |
|
|
|
74 |
|
|
include conf/%s.conf |
75 |
|
|
|
76 |
|
|
=back |
77 |
pcg |
1.1 |
|
78 |
|
|
=head1 ANATOMY OF A CONFIG FILE |
79 |
|
|
|
80 |
pcg |
1.21 |
Usually, a config file starts with a few global settings (like the UDP |
81 |
|
|
port to listen on), followed by node-specific sections that begin with a |
82 |
|
|
C<node = nickname> line. |
83 |
pcg |
1.1 |
|
84 |
|
|
Every node that is part of the network must have a section that starts |
85 |
|
|
with C<node = nickname>. The number and order of the nodes is important |
86 |
pcg |
1.20 |
and must be the same on all nodes. It is not uncommon for node sections to |
87 |
pcg |
1.1 |
be completely empty - if the default values are right. |
88 |
|
|
|
89 |
|
|
Node-specific settings can be used at any time. If used before the first |
90 |
|
|
node section they will set the default values for all following nodes. |
91 |
|
|
|
92 |
|
|
=head1 CONFIG VARIABLES |
93 |
|
|
|
94 |
|
|
=head2 GLOBAL SETTINGS |
95 |
|
|
|
96 |
|
|
Global settings will affect the behaviour of the running gvpe daemon, that |
97 |
|
|
is, they are in some sense node-specific (config files can set different |
98 |
|
|
values on different nodes using C<on>), but will affect the behaviour of |
99 |
|
|
the gvpe daemon and all connections it creates. |
100 |
|
|
|
101 |
|
|
=over 4 |
102 |
|
|
|
103 |
pcg |
1.6 |
=item dns-forw-host = hostname/ip |
104 |
pcg |
1.1 |
|
105 |
pcg |
1.21 |
The DNS server to forward DNS requests to for the DNS tunnel protocol |
106 |
pcg |
1.6 |
(default: C<127.0.0.1>, changing it is highly recommended). |
107 |
pcg |
1.1 |
|
108 |
pcg |
1.6 |
=item dns-forw-port = port-number |
109 |
pcg |
1.1 |
|
110 |
pcg |
1.6 |
The port where the C<dns-forw-host> is to be contacted (default: C<53>, |
111 |
|
|
which is fine in most cases). |
112 |
pcg |
1.1 |
|
113 |
root |
1.28 |
=item dns-case-preserving = yes|true|on | no|false|off |
114 |
|
|
|
115 |
|
|
Sets whether the DNS transport forwarding server preserves case (DNS |
116 |
|
|
servers have to, but some access systems are even more broken than others) |
117 |
|
|
(default: true). |
118 |
|
|
|
119 |
|
|
Normally, when the forwarding server changes the case of domain names then |
120 |
|
|
GVPE will automatically set this to false. |
121 |
|
|
|
122 |
pcg |
1.12 |
=item dns-max-outstanding = integer-number-of-requests |
123 |
|
|
|
124 |
|
|
The maximum number of outstanding DNS transport requests |
125 |
|
|
(default: C<100>). GVPE will never issue more requests then the given |
126 |
|
|
limit without receiving replies. In heavily overloaded situations it might |
127 |
|
|
help to set this to a low number (e.g. C<3> or even C<1>) to limit the |
128 |
|
|
number of parallel requests. |
129 |
|
|
|
130 |
pcg |
1.21 |
The default should be working OK for most links. |
131 |
pcg |
1.12 |
|
132 |
|
|
=item dns-overlap-factor = float |
133 |
|
|
|
134 |
|
|
The DNS transport uses the minimum request latency (B<min_latency>) seen |
135 |
|
|
during a connection as it's timing base. This factor (default: C<0.5>, |
136 |
|
|
must be > 0) is multiplied by B<min_latency> to get the maximum sending |
137 |
|
|
rate (= minimum send interval), i.e. a factor of C<1> means that a new |
138 |
|
|
request might be generated every B<min_latency> seconds, which means on |
139 |
|
|
average there should only ever be one outstanding request. A factor of |
140 |
|
|
C<0.5> means that GVPE will send requests twice as often as the minimum |
141 |
|
|
latency measured. |
142 |
|
|
|
143 |
pcg |
1.21 |
For congested or picky DNS forwarders you could use a value nearer to or |
144 |
pcg |
1.12 |
exceeding C<1>. |
145 |
|
|
|
146 |
pcg |
1.21 |
The default should be working OK for most links. |
147 |
pcg |
1.12 |
|
148 |
|
|
=item dns-send-interval = send-interval-in-seconds |
149 |
|
|
|
150 |
|
|
The minimum send interval (= maximum rate) that the DNS transport will |
151 |
|
|
use to send new DNS requests. GVPE will not exceed this rate even when |
152 |
|
|
the latency is very low. The default is C<0.01>, which means GVPE will |
153 |
|
|
not send more than 100 DNS requests per connection per second. For |
154 |
|
|
high-bandwidth links you could go lower, e.g. to C<0.001> or so. For |
155 |
|
|
congested or rate-limited links, you might want to go higher, say C<0.1>, |
156 |
|
|
C<0.2> or even higher. |
157 |
|
|
|
158 |
pcg |
1.21 |
The default should be working OK for most links. |
159 |
pcg |
1.12 |
|
160 |
|
|
=item dns-timeout-factor = float |
161 |
|
|
|
162 |
|
|
Factor to multiply the C<min_latency> (see C<dns-overlap-factor>) by to |
163 |
|
|
get request timeouts. The default of C<8> means that the DNS transport |
164 |
|
|
will resend the request when no reply has been received for longer than |
165 |
|
|
eight times the minimum (= expected) latency, assuming the request or |
166 |
|
|
reply has been lost. |
167 |
|
|
|
168 |
pcg |
1.17 |
For congested links a higher value might be necessary (e.g. C<30>). If |
169 |
|
|
the link is very stable lower values (e.g. C<2>) might work |
170 |
|
|
nicely. Values near or below C<1> makes no sense whatsoever. |
171 |
pcg |
1.12 |
|
172 |
pcg |
1.21 |
The default should be working OK for most links but will result in low |
173 |
pcg |
1.17 |
throughput if packet loss is high. |
174 |
pcg |
1.12 |
|
175 |
pcg |
1.1 |
=item if-up = relative-or-absolute-path |
176 |
|
|
|
177 |
|
|
Sets the path of a script that should be called immediately after the |
178 |
pcg |
1.21 |
network interface is initialized (but not necessarily up). The following |
179 |
pcg |
1.13 |
environment variables are passed to it (the values are just examples). |
180 |
|
|
|
181 |
|
|
Variables that have the same value on all nodes: |
182 |
pcg |
1.1 |
|
183 |
|
|
=over 4 |
184 |
|
|
|
185 |
|
|
=item CONFBASE=/etc/gvpe |
186 |
|
|
|
187 |
|
|
The configuration base directory. |
188 |
|
|
|
189 |
|
|
=item IFNAME=vpn0 |
190 |
|
|
|
191 |
pcg |
1.13 |
The network interface to initialize. |
192 |
|
|
|
193 |
|
|
=item IFTYPE=native # or tincd |
194 |
|
|
|
195 |
|
|
=item IFSUBTYPE=linux # or freebsd, darwin etc.. |
196 |
|
|
|
197 |
|
|
The interface type (C<native> or C<tincd>) and the subtype (usually the |
198 |
|
|
OS name in lowercase) that this GVPE was configured for. Can be used to |
199 |
|
|
select the correct syntax to use for network-related commands. |
200 |
pcg |
1.1 |
|
201 |
|
|
=item MTU=1436 |
202 |
|
|
|
203 |
|
|
The MTU to set the interface to. You can use lower values (if done |
204 |
pcg |
1.20 |
consistently on all nodes), but this is usually either inefficient or |
205 |
|
|
simply ineffective. |
206 |
pcg |
1.1 |
|
207 |
pcg |
1.13 |
=item NODES=5 |
208 |
|
|
|
209 |
|
|
The number of nodes in this GVPE network. |
210 |
|
|
|
211 |
|
|
=back |
212 |
|
|
|
213 |
|
|
Variables that are node-specific and with values pertaining to the node |
214 |
|
|
running this GVPE: |
215 |
pcg |
1.1 |
|
216 |
pcg |
1.13 |
=over 4 |
217 |
pcg |
1.1 |
|
218 |
pcg |
1.13 |
=item IFUPDATA=string |
219 |
pcg |
1.1 |
|
220 |
pcg |
1.13 |
The value of the configuration directive C<if-up-data>. |
221 |
pcg |
1.1 |
|
222 |
pcg |
1.13 |
=item MAC=fe:fd:80:00:00:01 |
223 |
pcg |
1.1 |
|
224 |
pcg |
1.13 |
The MAC address the network interface has to use. |
225 |
pcg |
1.1 |
|
226 |
pcg |
1.13 |
Might be used to initialize interfaces on platforms where GVPE does not |
227 |
pcg |
1.21 |
do this automatically. Please see the C<gvpe.osdep(5)> man page for |
228 |
pcg |
1.13 |
platform-specific information. |
229 |
pcg |
1.1 |
|
230 |
|
|
=item NODENAME=branch1 |
231 |
|
|
|
232 |
pcg |
1.13 |
The nickname of the node. |
233 |
pcg |
1.1 |
|
234 |
|
|
=item NODEID=1 |
235 |
|
|
|
236 |
pcg |
1.13 |
The numerical node ID of the node running this instance of GVPE. The first |
237 |
|
|
node mentioned in the config file gets ID 1, the second ID 2 and so on. |
238 |
pcg |
1.1 |
|
239 |
|
|
=back |
240 |
|
|
|
241 |
pcg |
1.13 |
In addition, all node-specific variables (except C<NODEID>) will be |
242 |
|
|
available with a postfix of C<_nodeid>, which contains the value for that |
243 |
|
|
node, e.g. the C<MAC_1> variable contains the MAC address of node #1, while |
244 |
|
|
the C<NODENAME_22> variable contains the name of node #22. |
245 |
|
|
|
246 |
pcg |
1.1 |
Here is a simple if-up script: |
247 |
|
|
|
248 |
|
|
#!/bin/sh |
249 |
pcg |
1.13 |
ip link set $IFNAME up |
250 |
pcg |
1.1 |
[ $NODENAME = branch1 ] && ip addr add 10.0.0.1 dev $IFNAME |
251 |
|
|
[ $NODENAME = branch2 ] && ip addr add 10.1.0.1 dev $IFNAME |
252 |
|
|
ip route add 10.0.0.0/8 dev $IFNAME |
253 |
|
|
|
254 |
pcg |
1.21 |
More complicated examples (using routing to reduce ARP traffic) can be |
255 |
|
|
found in the F<etc/> subdirectory of the distribution. |
256 |
pcg |
1.1 |
|
257 |
pcg |
1.6 |
=item ifname = devname |
258 |
|
|
|
259 |
|
|
Sets the tun interface name to the given name. The default is OS-specific |
260 |
|
|
and most probably something like C<tun0>. |
261 |
|
|
|
262 |
|
|
=item ifpersist = yes|true|on | no|false|off |
263 |
|
|
|
264 |
|
|
Should the tun/tap device be made persistent, that is, should the device |
265 |
|
|
stay up even when gvpe exits? Some versions of the tunnel device have |
266 |
|
|
problems sending packets when gvpe is restarted in persistent mode, so |
267 |
|
|
if the connections can be established but you cannot send packets from |
268 |
|
|
the local node, try to set this to C<off> and do an ifconfig down on the |
269 |
|
|
device. |
270 |
|
|
|
271 |
|
|
=item ip-proto = numerical-ip-protocol |
272 |
|
|
|
273 |
|
|
Sets the protocol number to be used for the rawip protocol. This is a |
274 |
pcg |
1.20 |
global option because all nodes must use the same protocol, and since |
275 |
pcg |
1.6 |
there are no port numbers, you cannot easily run more than one gvpe |
276 |
|
|
instance using the same protocol, nor can you share the protocol with |
277 |
|
|
other programs. |
278 |
|
|
|
279 |
pcg |
1.21 |
The default is 47 (GRE), which has a good chance of tunneling |
280 |
|
|
through firewalls (but note that gvpe's rawip protocol is not GRE |
281 |
|
|
compatible). Other common choices are 50 (IPSEC, ESP), 51 (IPSEC, AH), 4 |
282 |
pcg |
1.25 |
(IPIP tunnels) or 98 (ENCAP, rfc1241). |
283 |
|
|
|
284 |
|
|
Many versions of Linux seem to have a bug that causes them to reorder |
285 |
|
|
packets for some ip protocols (GRE, ESP) but not for others (AH), so |
286 |
|
|
choose wisely (that is, use 51, AH). |
287 |
pcg |
1.6 |
|
288 |
|
|
=item http-proxy-host = hostname/ip |
289 |
|
|
|
290 |
|
|
The C<http-proxy-*> family of options are only available if gvpe was |
291 |
|
|
compiled with the C<--enable-http-proxy> option and enable tunneling of |
292 |
|
|
tcp connections through a http proxy server. |
293 |
|
|
|
294 |
|
|
C<http-proxy-host> and C<http-proxy-port> should specify the hostname and |
295 |
|
|
port number of the proxy server. See C<http-proxy-loginpw> if your proxy |
296 |
|
|
requires authentication. |
297 |
|
|
|
298 |
|
|
Please note that gvpe will still try to resolve all hostnames in the |
299 |
pcg |
1.21 |
configuration file, so if you are behind a proxy without access to a DNS |
300 |
pcg |
1.6 |
server better use numerical IP addresses. |
301 |
|
|
|
302 |
pcg |
1.21 |
To make best use of this option disable all protocols except TCP in your |
303 |
pcg |
1.20 |
config file and make sure your routers (or all other nodes) are listening |
304 |
pcg |
1.6 |
on a port that the proxy allows (443, https, is a common choice). |
305 |
|
|
|
306 |
pcg |
1.21 |
If you have a router, connecting to it will suffice. Otherwise TCP must be |
307 |
pcg |
1.20 |
enabled on all nodes. |
308 |
pcg |
1.6 |
|
309 |
|
|
Example: |
310 |
|
|
|
311 |
|
|
http-proxy-host = proxy.example.com |
312 |
|
|
http-proxy-port = 3128 # 8080 is another common choice |
313 |
|
|
http-proxy-auth = schmorp:grumbeere |
314 |
|
|
|
315 |
|
|
=item http-proxy-port = proxy-tcp-port |
316 |
|
|
|
317 |
|
|
The port where your proxy server listens. |
318 |
|
|
|
319 |
|
|
=item http-proxy-auth = login:password |
320 |
|
|
|
321 |
|
|
The optional login and password used to authenticate to the proxy server, |
322 |
pcg |
1.21 |
separated by a literal colon (C<:>). Only basic authentication is |
323 |
pcg |
1.6 |
currently supported. |
324 |
|
|
|
325 |
|
|
=item keepalive = seconds |
326 |
|
|
|
327 |
|
|
Sets the keepalive probe interval in seconds (default: C<60>). After this |
328 |
|
|
many seconds of inactivity the daemon will start to send keepalive probe |
329 |
pcg |
1.21 |
every 3 seconds until it receives a reply from the other end. If no reply |
330 |
|
|
is received within 15 seconds, the peer is considered unreachable and the |
331 |
pcg |
1.6 |
connection is closed. |
332 |
|
|
|
333 |
|
|
=item loglevel = noise|trace|debug|info|notice|warn|error|critical |
334 |
|
|
|
335 |
|
|
Set the logging level. Connection established messages are logged at level |
336 |
|
|
C<info>, notable errors are logged with C<error>. Default is C<info>. |
337 |
|
|
|
338 |
|
|
=item mtu = bytes |
339 |
|
|
|
340 |
|
|
Sets the maximum MTU that should be used on outgoing packets (basically |
341 |
|
|
the MTU of the outgoing interface) The daemon will automatically calculate |
342 |
pcg |
1.21 |
maximum overhead (e.g. UDP header size, encryption blocksize...) and pass |
343 |
pcg |
1.6 |
this information to the C<if-up> script. |
344 |
|
|
|
345 |
|
|
Recommended values are 1500 (ethernet), 1492 (pppoe), 1472 (pptp). |
346 |
|
|
|
347 |
pcg |
1.21 |
This value must be the minimum of the MTU values of all nodes. |
348 |
pcg |
1.6 |
|
349 |
|
|
=item node = nickname |
350 |
|
|
|
351 |
|
|
Not really a config setting but introduces a node section. The nickname is |
352 |
|
|
used to select the right configuration section and must be passed as an |
353 |
|
|
argument to the gvpe daemon. |
354 |
|
|
|
355 |
pcg |
1.1 |
=item node-up = relative-or-absolute-path |
356 |
|
|
|
357 |
pcg |
1.19 |
Sets a command (default: none) that should be called whenever a connection |
358 |
|
|
is established (even on rekeying operations). Note that node-up/down |
359 |
|
|
scripts will be run asynchronously, but execution is serialised, so there |
360 |
|
|
will only ever be one such script running. |
361 |
|
|
|
362 |
|
|
In addition to all the variables passed to C<if-up> scripts, the following |
363 |
pcg |
1.24 |
environment variables will be set (values are just examples): |
364 |
pcg |
1.1 |
|
365 |
|
|
=over 4 |
366 |
|
|
|
367 |
|
|
=item DESTNODE=branch2 |
368 |
|
|
|
369 |
|
|
The name of the remote node. |
370 |
|
|
|
371 |
|
|
=item DESTID=2 |
372 |
|
|
|
373 |
|
|
The node id of the remote node. |
374 |
|
|
|
375 |
pcg |
1.24 |
=item DESTSI=rawip/88.99.77.55:0 |
376 |
|
|
|
377 |
|
|
The "socket info" of the target node, protocol dependent but usually in |
378 |
|
|
the format protocol/ip:port. |
379 |
|
|
|
380 |
pcg |
1.1 |
=item DESTIP=188.13.66.8 |
381 |
|
|
|
382 |
pcg |
1.20 |
The numerical IP address of the remote node (gvpe accepts connections from |
383 |
|
|
everywhere, as long as the other node can authenticate itself). |
384 |
pcg |
1.1 |
|
385 |
|
|
=item DESTPORT=655 # deprecated |
386 |
|
|
|
387 |
pcg |
1.24 |
The protocol port used by the other side, if applicable. |
388 |
pcg |
1.1 |
|
389 |
pcg |
1.24 |
=item STATE=up |
390 |
pcg |
1.1 |
|
391 |
pcg |
1.24 |
Node-up scripts get called with STATE=up, node-change scripts get called |
392 |
|
|
with STATE=change and node-down scripts get called with STATE=down. |
393 |
pcg |
1.1 |
|
394 |
|
|
=back |
395 |
|
|
|
396 |
|
|
Here is a nontrivial example that uses nsupdate to update the name => ip |
397 |
pcg |
1.21 |
mapping in some DNS zone: |
398 |
pcg |
1.1 |
|
399 |
|
|
#!/bin/sh |
400 |
|
|
{ |
401 |
|
|
echo update delete $DESTNODE.lowttl.example.net. a |
402 |
|
|
echo update add $DESTNODE.lowttl.example.net. 1 in a $DESTIP |
403 |
|
|
echo |
404 |
|
|
} | nsupdate -d -k $CONFBASE:key.example.net. |
405 |
|
|
|
406 |
pcg |
1.24 |
=item node-change = relative-or-absolute-path |
407 |
|
|
|
408 |
|
|
Same as C<node-change>, but gets called whenever something about a |
409 |
|
|
connection changes (such as the source IP address). |
410 |
|
|
|
411 |
pcg |
1.1 |
=item node-down = relative-or-absolute-path |
412 |
|
|
|
413 |
|
|
Same as C<node-up>, but gets called whenever a connection is lost. |
414 |
|
|
|
415 |
pcg |
1.6 |
=item pid-file = path |
416 |
|
|
|
417 |
|
|
The path to the pid file to check and create |
418 |
|
|
(default: C<LOCALSTATEDIR/run/gvpe.pid>). |
419 |
|
|
|
420 |
|
|
=item private-key = relative-path-to-key |
421 |
|
|
|
422 |
|
|
Sets the path (relative to the config directory) to the private key |
423 |
|
|
(default: C<hostkey>). This is a printf format string so every C<%> must |
424 |
|
|
be doubled. A single C<%s> is replaced by the hostname, so you could |
425 |
|
|
use paths like C<hostkeys/%s> to fetch the files at the location where |
426 |
|
|
C<gvpectrl> puts them. |
427 |
pcg |
1.1 |
|
428 |
pcg |
1.6 |
Since only the private key file of the current node is used and the |
429 |
pcg |
1.21 |
private key file should be kept secret per-node to avoid spoofing, it is |
430 |
pcg |
1.6 |
not recommended to use this feature. |
431 |
pcg |
1.1 |
|
432 |
pcg |
1.6 |
=item rekey = seconds |
433 |
pcg |
1.1 |
|
434 |
pcg |
1.6 |
Sets the rekeying interval in seconds (default: C<3600>). Connections are |
435 |
pcg |
1.21 |
reestablished every C<rekey> seconds, making them use a new encryption |
436 |
|
|
key. |
437 |
pcg |
1.1 |
|
438 |
pcg |
1.23 |
=item nfmark = integer |
439 |
|
|
|
440 |
|
|
This advanced option, when set to a nonzero value (default: C<0>), tries |
441 |
|
|
to set the netfilter mark (or fwmark) value on all sockets gvpe uses to |
442 |
|
|
send packets. |
443 |
|
|
|
444 |
|
|
This can be used to make gvpe use a different set of routing rules. For |
445 |
|
|
example, on GNU/Linux, the C<if-up> could set C<nfmark> to 1000 and then |
446 |
|
|
put all routing rules into table C<99> and then use an ip rule to make |
447 |
|
|
gvpe traffic avoid that routing table, in effect routing normal traffic |
448 |
|
|
via gvpe and gvpe traffic via the normal system routing tables: |
449 |
|
|
|
450 |
|
|
ip rule add not fwmark 1000 lookup 99 |
451 |
|
|
|
452 |
pcg |
1.6 |
=back |
453 |
pcg |
1.1 |
|
454 |
pcg |
1.6 |
=head2 NODE SPECIFIC SETTINGS |
455 |
pcg |
1.1 |
|
456 |
pcg |
1.6 |
The following settings are node-specific, that is, every node can have |
457 |
|
|
different settings, even within the same gvpe instance. Settings that are |
458 |
pcg |
1.15 |
set before the first node section set the defaults, settings that are |
459 |
|
|
set within a node section only apply to the given node. |
460 |
pcg |
1.1 |
|
461 |
pcg |
1.6 |
=over 4 |
462 |
pcg |
1.1 |
|
463 |
pcg |
1.15 |
=item allow-direct = nodename |
464 |
|
|
|
465 |
|
|
Allow direct connections to this node. See C<deny-direct> for more info. |
466 |
|
|
|
467 |
pcg |
1.6 |
=item compress = yes|true|on | no|false|off |
468 |
pcg |
1.1 |
|
469 |
root |
1.26 |
For the current node, this specified whether it will accept compressed |
470 |
|
|
packets, and for all other nodes, this specifies whether to try to |
471 |
|
|
compress data packets sent to this node (default: C<yes>). Compression is |
472 |
|
|
really cheap even on slow computers, has no size overhead at all and will |
473 |
|
|
only be used when the other side supports compression, so enabling this is |
474 |
|
|
often a good idea. |
475 |
pcg |
1.1 |
|
476 |
pcg |
1.6 |
=item connect = ondemand | never | always | disabled |
477 |
pcg |
1.1 |
|
478 |
pcg |
1.6 |
Sets the connect mode (default: C<always>). It can be C<always> (always |
479 |
pcg |
1.20 |
try to establish and keep a connection to the given node), C<never> |
480 |
pcg |
1.6 |
(never initiate a connection to the given host, but accept connections), |
481 |
pcg |
1.18 |
C<ondemand> (try to establish a connection when there are outstanding |
482 |
|
|
packets in the queue and take it down after the keepalive interval) or |
483 |
|
|
C<disabled> (node is bad, don't talk to it). |
484 |
pcg |
1.1 |
|
485 |
pcg |
1.20 |
Routers will automatically be forced to C<always> unless they are |
486 |
|
|
C<disabled>, to ensure all nodes can talk to each other. |
487 |
|
|
|
488 |
pcg |
1.15 |
=item deny-direct = nodename | * |
489 |
|
|
|
490 |
|
|
Deny direct connections to the specified node (or all nodes when C<*> |
491 |
|
|
is given). Only one node can be specified, but you can use multiple |
492 |
|
|
C<allow-direct> and C<deny-direct> statements. This only makes sense in |
493 |
|
|
networks with routers, as routers are required for indirect connections. |
494 |
|
|
|
495 |
|
|
Sometimes, a node cannot reach some other nodes for reasons of network |
496 |
|
|
connectivity. For example, a node behind a firewall that only allows |
497 |
pcg |
1.21 |
connections to/from a single other node in the network. In this case one |
498 |
pcg |
1.15 |
should specify C<deny-direct = *> and C<allow-direct = othernodename> (the other |
499 |
|
|
node I<must> be a router for this to work). |
500 |
|
|
|
501 |
pcg |
1.21 |
The algorithm to check whether a connection may be direct is as follows: |
502 |
pcg |
1.15 |
|
503 |
pcg |
1.21 |
1. Other node mentioned in an C<allow-direct>? If yes, allow the connection. |
504 |
pcg |
1.15 |
|
505 |
|
|
2. Other node mentioned in a C<deny-direct>? If yes, deny direct connections. |
506 |
|
|
|
507 |
|
|
3. Allow the connection. |
508 |
|
|
|
509 |
pcg |
1.16 |
That is, C<allow-direct> takes precedence over C<deny-direct>. |
510 |
pcg |
1.15 |
|
511 |
|
|
The check is done in both directions, i.e. both nodes must allow a direct |
512 |
|
|
connection before one is attempted, so you only need to specify connect |
513 |
|
|
limitations on one node. |
514 |
|
|
|
515 |
pcg |
1.6 |
=item dns-domain = domain-suffix |
516 |
pcg |
1.1 |
|
517 |
pcg |
1.7 |
The DNS domain suffix that points to the DNS tunnel server for this node. |
518 |
pcg |
1.1 |
|
519 |
pcg |
1.6 |
The domain must point to a NS record that points to the I<dns-hostname>, |
520 |
|
|
i.e. |
521 |
pcg |
1.1 |
|
522 |
pcg |
1.6 |
dns-domainname = tunnel.example.net |
523 |
|
|
dns-hostname = tunnel-server.example.net |
524 |
pcg |
1.1 |
|
525 |
pcg |
1.6 |
Corresponds to the following DNS entries in the C<example.net> domain: |
526 |
pcg |
1.1 |
|
527 |
pcg |
1.6 |
tunnel.example.net. NS tunnel-server.example.net. |
528 |
|
|
tunnel-server.example.net. A 13.13.13.13 |
529 |
pcg |
1.1 |
|
530 |
pcg |
1.6 |
=item dns-hostname = hostname/ip |
531 |
pcg |
1.1 |
|
532 |
pcg |
1.6 |
The address to bind the DNS tunnel socket to, similar to the C<hostname>, |
533 |
|
|
but for the DNS tunnel protocol only. Default: C<0.0.0.0>, but that might |
534 |
|
|
change. |
535 |
pcg |
1.1 |
|
536 |
pcg |
1.6 |
=item dns-port = port-number |
537 |
pcg |
1.1 |
|
538 |
pcg |
1.8 |
The port to bind the DNS tunnel socket to. Must be C<53> on DNS tunnel servers. |
539 |
pcg |
1.1 |
|
540 |
pcg |
1.7 |
=item enable-dns = yes|true|on | no|false|off |
541 |
|
|
|
542 |
pcg |
1.10 |
See gvpe.protocol(7) for a description of the DNS transport |
543 |
|
|
protocol. Avoid this protocol if you can. |
544 |
|
|
|
545 |
pcg |
1.8 |
Enable the DNS tunneling protocol on this node, either as server or as |
546 |
pcg |
1.10 |
client. Support for this transport protocol is only available when gvpe |
547 |
|
|
was compiled using the C<--enable-dns> option. |
548 |
|
|
|
549 |
|
|
=item enable-icmp = yes|true|on | no|false|off |
550 |
|
|
|
551 |
|
|
See gvpe.protocol(7) for a description of the ICMP transport protocol. |
552 |
pcg |
1.8 |
|
553 |
pcg |
1.21 |
Enable the ICMP transport using ICMP packets of type C<icmp-type> on this |
554 |
pcg |
1.10 |
node. |
555 |
pcg |
1.7 |
|
556 |
pcg |
1.1 |
=item enable-rawip = yes|true|on | no|false|off |
557 |
|
|
|
558 |
pcg |
1.10 |
See gvpe.protocol(7) for a description of the RAW IP transport protocol. |
559 |
|
|
|
560 |
pcg |
1.1 |
Enable the RAW IPv4 transport using the C<ip-proto> protocol |
561 |
pcg |
1.10 |
(default: C<no>). |
562 |
pcg |
1.1 |
|
563 |
pcg |
1.6 |
=item enable-tcp = yes|true|on | no|false|off |
564 |
|
|
|
565 |
pcg |
1.10 |
See gvpe.protocol(7) for a description of the TCP transport protocol. |
566 |
|
|
|
567 |
pcg |
1.6 |
Enable the TCPv4 transport using the C<tcp-port> port |
568 |
pcg |
1.10 |
(default: C<no>). Support for this transport protocol is only available |
569 |
|
|
when gvpe was compiled using the C<--enable-tcp> option. |
570 |
pcg |
1.6 |
|
571 |
pcg |
1.1 |
=item enable-udp = yes|true|on | no|false|off |
572 |
|
|
|
573 |
pcg |
1.10 |
See gvpe.protocol(7) for a description of the UDP transport protocol. |
574 |
|
|
|
575 |
root |
1.27 |
Enable the UDPv4 transport using the C<udp-port> port (default: C<no>). |
576 |
pcg |
1.15 |
|
577 |
|
|
=item hostname = hostname | ip [can not be defaulted] |
578 |
|
|
|
579 |
pcg |
1.21 |
Forces the address of this node to be set to the given DNS hostname or IP |
580 |
pcg |
1.15 |
address. It will be resolved before each connect request, so dyndns should |
581 |
|
|
work fine. If this setting is not specified and a router is available, |
582 |
|
|
then the router will be queried for the address of this node. Otherwise, |
583 |
|
|
the connection attempt will fail. |
584 |
pcg |
1.1 |
|
585 |
pcg |
1.21 |
Note that DNS resolving is done synchronously, pausing the daemon. If that |
586 |
|
|
is an issue you need to specify IP addresses. |
587 |
|
|
|
588 |
pcg |
1.11 |
=item icmp-type = integer |
589 |
|
|
|
590 |
|
|
Sets the type value to be used for outgoing (and incoming) packets sent |
591 |
|
|
via the ICMP transport. |
592 |
|
|
|
593 |
|
|
The default is C<0> (which is C<echo-reply>, also known as |
594 |
pcg |
1.21 |
"ping-reply"). Other useful values include C<8> (C<echo-request>, a.k.a. |
595 |
pcg |
1.11 |
"ping") and C<11> (C<time-exceeded>), but any 8-bit value can be used. |
596 |
|
|
|
597 |
pcg |
1.13 |
=item if-up-data = value |
598 |
|
|
|
599 |
|
|
The value specified using this directive will be passed to the C<if-up> |
600 |
|
|
script in the environment variable C<IFUPDATA>. |
601 |
|
|
|
602 |
pcg |
1.6 |
=item inherit-tos = yes|true|on | no|false|off |
603 |
|
|
|
604 |
root |
1.26 |
Whether to inherit the TOS settings of packets sent to the tunnel when |
605 |
pcg |
1.6 |
sending packets to this node (default: C<yes>). If set to C<yes> then |
606 |
|
|
outgoing tunnel packets will have the same TOS setting as the packets sent |
607 |
|
|
to the tunnel device, which is usually what you want. |
608 |
|
|
|
609 |
|
|
=item max-retry = positive-number |
610 |
pcg |
1.1 |
|
611 |
pcg |
1.8 |
The maximum interval in seconds (default: C<3600>, one hour) between |
612 |
pcg |
1.6 |
retries to establish a connection to this node. When a connection cannot |
613 |
pcg |
1.21 |
be established, gvpe uses exponential back-off capped at this value. It's |
614 |
pcg |
1.6 |
sometimes useful to set this to a much lower value (e.g. C<120>) on |
615 |
|
|
connections to routers that usually are stable but sometimes are down, to |
616 |
pcg |
1.8 |
assure quick reconnections even after longer downtimes. |
617 |
pcg |
1.1 |
|
618 |
pcg |
1.18 |
=item max-ttl = seconds |
619 |
|
|
|
620 |
|
|
Expire packets that couldn't be sent after this many seconds |
621 |
|
|
(default: C<60>). Gvpe will normally queue packets for a node without an |
622 |
|
|
active connection, in the hope of establishing a connection soon. This |
623 |
|
|
value specifies the maximum lifetime a packet will stay in the queue, if a |
624 |
|
|
packet gets older, it will be thrown away. |
625 |
|
|
|
626 |
pcg |
1.20 |
=item max-queue = positive-number>=1 |
627 |
pcg |
1.18 |
|
628 |
|
|
The maximum number of packets that will be queued (default: C<512>) |
629 |
|
|
for this node. If more packets are sent then earlier packets will be |
630 |
|
|
expired. See C<max-ttl>, above. |
631 |
|
|
|
632 |
pcg |
1.8 |
=item router-priority = 0 | 1 | positive-number>=2 |
633 |
pcg |
1.1 |
|
634 |
pcg |
1.20 |
Sets the router priority of the given node (default: C<0>, disabled). |
635 |
|
|
|
636 |
|
|
If some node tries to connect to another node but it doesn't have a |
637 |
|
|
hostname, it asks a router node for it's IP address. The router node |
638 |
|
|
chosen is the one with the highest priority larger than C<1> that is |
639 |
|
|
currently reachable. This is called a I<mediated> connection, as the |
640 |
|
|
connection itself will still be direct, but it uses another node to |
641 |
|
|
mediate between the two nodes. |
642 |
pcg |
1.1 |
|
643 |
pcg |
1.20 |
The value C<0> disables routing, that means if the node receives a packet |
644 |
|
|
not for itself it will not forward it but instead drop it. |
645 |
pcg |
1.2 |
|
646 |
|
|
The special value C<1> allows other hosts to route through the router |
647 |
pcg |
1.20 |
host, but they will never route through it by default (i.e. the config |
648 |
|
|
file of another node needs to specify a router priority higher than one |
649 |
|
|
to choose such a node for routing). |
650 |
|
|
|
651 |
|
|
The idea behind this is that some hosts can, if required, bump the |
652 |
|
|
C<router-priority> setting to higher than C<1> in their local config to |
653 |
|
|
route through specific hosts. If C<router-priority> is C<0>, then routing |
654 |
|
|
will be refused, so C<1> serves as a "enable, but do not use by default" |
655 |
|
|
switch. |
656 |
|
|
|
657 |
|
|
Nodes with C<router-priority> set to C<2> or higher will always be forced |
658 |
|
|
to C<connect> = C<always> (unless they are C<disabled>). |
659 |
pcg |
1.2 |
|
660 |
pcg |
1.6 |
=item tcp-port = port-number |
661 |
pcg |
1.1 |
|
662 |
pcg |
1.6 |
Similar to C<udp-port> (default: C<655>), but sets the TCP port number. |
663 |
pcg |
1.1 |
|
664 |
pcg |
1.6 |
=item udp-port = port-number |
665 |
pcg |
1.1 |
|
666 |
pcg |
1.6 |
Sets the port number used by the UDP protocol (default: C<655>, not |
667 |
|
|
officially assigned by IANA!). |
668 |
pcg |
1.1 |
|
669 |
|
|
=back |
670 |
|
|
|
671 |
|
|
=head1 CONFIG DIRECTORY LAYOUT |
672 |
|
|
|
673 |
|
|
The default (or recommended) directory layout for the config directory is: |
674 |
|
|
|
675 |
|
|
=over 4 |
676 |
|
|
|
677 |
pcg |
1.22 |
=item gvpe.conf |
678 |
pcg |
1.1 |
|
679 |
|
|
The config file. |
680 |
|
|
|
681 |
pcg |
1.22 |
=item if-up |
682 |
pcg |
1.1 |
|
683 |
|
|
The if-up script |
684 |
|
|
|
685 |
pcg |
1.22 |
=item node-up, node-down |
686 |
pcg |
1.1 |
|
687 |
|
|
If used the node up or node-down scripts. |
688 |
|
|
|
689 |
pcg |
1.22 |
=item hostkey |
690 |
pcg |
1.1 |
|
691 |
|
|
The private key (taken from C<hostkeys/nodename>) of the current host. |
692 |
|
|
|
693 |
pcg |
1.22 |
=item pubkey/nodename |
694 |
pcg |
1.1 |
|
695 |
|
|
The public keys of the other nodes, one file per node. |
696 |
|
|
|
697 |
|
|
=back |
698 |
|
|
|
699 |
|
|
=head1 SEE ALSO |
700 |
|
|
|
701 |
|
|
gvpe(5), gvpe(8), gvpectrl(8). |
702 |
|
|
|
703 |
|
|
=head1 AUTHOR |
704 |
|
|
|
705 |
pcg |
1.14 |
Marc Lehmann <gvpe@schmorp.de> |
706 |
pcg |
1.1 |
|