source: man/iodine.8 @ d4849a

Revision d4849a, 10.0 KB checked in by Laurent Ghigonis <laurent@…>, 18 months ago (diff)

Add support for openbsd routing domain, #95

  • Property mode set to 100644
Line 
1.\" groff -man -Tascii iodine.8
2.TH IODINE 8 "DEC 2009" "User Manuals"
3.SH NAME
4iodine, iodined \- tunnel IPv4 over DNS
5.SH SYNOPSIS
6.B iodine [-v]
7
8.B iodine [-h]
9
10.B iodine [-f] [-r] [-u
11.I user
12.B ] [-P
13.I password
14.B ] [-m
15.I fragsize
16.B ] [-t
17.I chrootdir
18.B ] [-d
19.I device
20.B ] [-R
21.I rdomain
22.B ] [-m
23.I fragsize
24.B ] [-M
25.I namelen
26.B ] [-z
27.I context
28.B ] [-F
29.I pidfile
30.B ] [-T
31.I dnstype
32.B ] [-O
33.I downenc
34.B ] [-L
35.I 0|1
36.B ] [-I
37.I interval
38.B ]
39.B [
40.I nameserver
41.B ]
42.I topdomain
43
44.B iodined [-v]
45
46.B iodined [-h]
47
48.B iodined [-c] [-s] [-f] [-D] [-u
49.I user
50.B ] [-t
51.I chrootdir
52.B ] [-d
53.I device
54.B ] [-m
55.I mtu
56.B ] [-l
57.I listen_ip
58.B ] [-p
59.I port
60.B ] [-n
61.I external_ip
62.B ] [-b
63.I dnsport
64.B ] [-P
65.I password
66.B ] [-z
67.I context
68.B ] [-F
69.I pidfile
70.B ]
71.I tunnel_ip
72.B [
73.I /netmask
74.B ]
75.I topdomain
76.SH DESCRIPTION
77.B iodine
78lets you tunnel IPv4 data through a DNS
79server. This can be useful in situations where Internet access is firewalled,
80but DNS queries are allowed. It needs a TUN/TAP device to operate. The
81bandwidth is asymmetrical,
82with a measured maximum of 680 kbit/s upstream and 2.3 Mbit/s
83downstream in a wired LAN test network.
84Realistic sustained throughput on a Wifi network using a carrier-grade
85DNS cache has been measured at some 50 kbit/s upstream and over 200 kbit/s
86downstream.
87.B iodine
88is the client application,
89.B iodined
90is the server.
91
92Note: server and client are required to speak the exact same protocol. In most
93cases, this means running the same iodine version. Unfortunately, implementing
94backward and forward protocol compatibility is usually not feasible.
95.SH OPTIONS
96.SS Common Options:
97.TP
98.B -v
99Print version info and exit.
100.TP
101.B -h
102Print usage info and exit.
103.TP
104.B -f
105Keep running in foreground.
106.TP
107.B -u user
108Drop privileges and run as user 'user' after setting up tunnel.
109.TP
110.B -t chrootdir
111Chroot to 'chrootdir' after setting up tunnel.
112.TP
113.B -d device
114Use the TUN device 'device' instead of the normal one, which is dnsX on Linux
115and otherwise tunX.
116.TP
117.B -P password
118Use 'password' to authenticate. If not used,
119.B stdin
120will be used as input. Only the first 32 characters will be used.
121.TP
122.B -z context
123Apply SELinux 'context' after initialization.
124.TP
125.B -F pidfile
126Create 'pidfile' and write process id in it.
127.SS Client Options:
128.TP
129.B -r
130Skip raw UDP mode. If not used, iodine will try getting the public IP address
131of the iodined host and test if it is reachable directly. If it is, traffic
132will be sent to the server instead of the DNS relay.
133.TP
134.B -R rdomain
135Use OpenBSD routing domain 'rdomain' for the DNS connection.
136.TP
137.B -m fragsize
138Force maximum downstream fragment size. Not setting this will cause the
139client to automatically probe the maximum accepted downstream fragment size.
140.TP
141.B -M namelen
142Maximum length of upstream hostnames, default 255.
143Usable range ca. 100 to 255.
144Use this option to scale back upstream bandwidth in favor of downstream
145bandwidth.
146Also useful for DNS servers that perform unreliably when using full-length
147hostnames, noticable when fragment size autoprobe returns very
148different results each time.
149.TP
150.B -T dnstype
151DNS request type override.
152By default, autodetection will probe for working DNS request types, and
153will select the request type that is expected to provide the most bandwidth.
154However, it may turn out that a DNS relay imposes limits that skew the
155picture, which may lead to an "unexpected" DNS request type providing
156more bandwidth.
157In that case, use this option to override the autodetection.
158In (expected) decreasing bandwidth order, the supported DNS request types are:
159.IR NULL ,
160.IR TXT ,
161.IR SRV ,
162.IR MX ,
163.I CNAME
164and
165.I A
166(returning CNAME).
167Note that
168.IR SRV ,
169.I MX
170and
171.I A
172may/will cause additional lookups by "smart" caching
173nameservers to get an actual IP address, which may either slow down or fail
174completely.
175.TP
176.B -O downenc
177Force downstream encoding type for all query type responses except NULL.
178Default is autodetected, but may not spot all problems for the more advanced
179codecs.
180Use this option to override the autodetection.
181.I Base32
182is the lowest-grade codec and should always work; this is used when
183autodetection fails.
184.I Base64
185provides more bandwidth, but may not work on all nameservers.
186.I Base64u
187is equal to Base64 except in using underscore ('_')
188instead of plus sign ('+'), possibly working where
189.I Base64
190does not.
191.I Base128
192uses high byte values (mostly accented letters in iso8859-1),
193which might work with some nameservers.
194For TXT queries,
195.I Raw
196will provide maximum performance, but this will only work if the nameserver
197path is fully 8-bit-clean for responses that are assumed to be "legible text".
198.TP
199.B -L 0|1
200Lazy-mode switch.
201\-L1 (default): Use lazy mode for improved performance and decreased latency.
202A very small minority of DNS relays appears to be unable to handle the
203lazy mode traffic pattern, resulting in no or very little data coming through.
204The iodine client will detect this and try to switch back to legacy mode,
205but this may not always work.
206In these situations use \-L0 to force running in legacy mode
207(implies \-I1).
208.TP
209.B -I interval
210Maximum interval between requests (pings) so that intermediate DNS
211servers will not time out. Default is 4 in lazy mode, which will work
212fine in most cases. When too many SERVFAIL errors occur, iodine
213will automatically reduce this to 1.
214To get absolute minimum DNS traffic,
215increase well above 4, but not so high that SERVFAIL errors start to occur.
216There are some DNS relays with very small timeouts,
217notably dnsadvantage.com (ultradns), that will give
218SERVFAIL errors even with \-I1; data will still get trough,
219and these errors can be ignored.
220Maximum useful value is 59, since iodined will close a client's
221connection after 60 seconds of inactivity.
222.SS Server Options:
223.TP
224.B -c
225Disable checking the client IP address on all incoming requests.
226By default, requests originating from non-matching IP adresses will be
227rejected, however this will cause problems when requests are routed
228via a cluster of DNS servers.
229.TP
230.B -s
231Don't try to configure IP address or MTU.
232This should only be used if you have already configured the device that will be
233used.
234.TP
235.B -D
236Increase debug level. Level 1 prints info about each RX/TX packet.
237Implies the
238.B -f
239option.
240On level 2 (-DD) or higher, DNS queries will be printed literally.
241When using Base128 upstream encoding, this is best viewed as
242ISO Latin-1 text instead of (illegal) UTF-8.
243This is easily done with : "LC_ALL=C luit iodined -DD ..."
244(see luit(1)).
245.TP
246.B -m mtu
247Set 'mtu' as mtu size for the tun device.
248This will be sent to the client on login, and the client will use the same mtu
249for its tun device.  Default 1130.  Note that the DNS traffic will be
250automatically fragmented when needed.
251.TP
252.B -l listen_ip
253Make the server listen only on 'listen_ip' for incoming requests.
254By default, incoming requests are accepted from all interfaces.
255.TP
256.B -p port
257Make the server listen on 'port' instead of 53 for traffic.
258.B Note:
259You must make sure the dns requests are forwarded to this port yourself.
260.TP
261.B -n external_ip
262The IP address to return in NS responses. Default is to return the address used
263as destination in the query.
264.TP
265.B -b dnsport
266If this port is specified, all incoming requests not inside the tunnel domain
267will be forwarded to this port on localhost, to be handled by a real dns.
268.B Note:
269The forwarding is not fully transparent, and not advised for use
270in production environments.
271.SS Client Arguments:
272.TP
273.B nameserver
274The nameserver to use to relay the dns traffic. This can be any relaying
275nameserver or the server running iodined if reachable. This field can be
276given as an IP address, or as a hostname. This argument is optional, and
277if not specified a nameserver will be read from the
278.I /etc/resolv.conf
279file.
280.TP
281.B topdomain
282The dns traffic will be sent as queries for subdomains under
283\'topdomain'. This is normally a subdomain to a domain you own. Use a short
284domain name to get better throughput. If
285.B nameserver
286is the iodined server, then the topdomain can be chosen freely. This argument
287must be the same on both the client and the server.
288.SS Server Arguments:
289.TP
290.B tunnel_ip[/netmask]
291This is the server's ip address on the tun interface. The client will be
292given the next ip number in the range. It is recommended to use the
29310.0.0.0 or 172.16.0.0 ranges. The default netmask is /27, can be overriden
294by specifying it here. Using a smaller network will limit the number of
295concurrent users.
296.TP
297.B topdomain
298The dns traffic is expected to arrive as queries for
299subdomains under 'topdomain'. This is normally a subdomain to a domain you
300own. Use a short domain name to get better throughput. This argument must be
301the same on both the client and the server. Queries for domains other
302than 'topdomain' will be forwarded when the \-b option is given, otherwise
303they will be dropped.
304.SH EXAMPLES
305See the README file for both a quick test scenario, and a detailed description
306of real-world deployment.
307.SH SECURITY
308Login is a relatively secure challenge-response MD5 hash, with the
309password never passing the wire.
310However, all other data is
311.B NOT
312encrypted in any way. The DNS traffic is also vulnerable to replay,
313injection and man-in-the-middle attacks, especially when iodined is used
314with the \-c option. Use of ssh or vpn tunneling is strongly recommended.
315On both server and client, use
316.IR iptables ,
317.I pf
318or other firewalls to block all traffic coming in from the tun interfaces,
319except to the used ssh or vpn ports.
320.SH ENVIRONMENT
321.SS IODINE_PASS
322If the environment variable
323.B IODINE_PASS
324is set, iodine will use the value it is set to as password instead of asking
325for one. The
326.B -P
327option still has precedence.
328.SS IODINED_PASS
329If the environment variable
330.B IODINED_PASS
331is set, iodined will use the value it is set to as password instead of asking
332for one. The
333.B -P
334option still has precedence.
335.El
336.SH SEE ALSO
337The README file in the source distribution contains some more elaborate
338information.
339.SH BUGS
340File bugs at http://dev.kryo.se/iodine/
341.SH AUTHORS
342Erik Ekman <yarrick@kryo.se> and Bjorn Andersson <flex@kryo.se>. Major
343contributions by Anne Bezemer.
Note: See TracBrowser for help on using the repository browser.