.I user
.B ] [-P
.I password
+.B ] [-m
+.I fragsize
.B ] [-t
.I chrootdir
.B ] [-d
.B iodined [-c] [-s] [-f] [-D] [-u
.I user
-.B ] [-P
-.I password
.B ] [-t
.I chrootdir
+.B ] [-d
+.I device
.B ] [-m
.I mtu
.B ] [-l
.I listen_ip
-.B ] [-d
-.I device
-.B ]
+.B ] [-p
+.I port
+.B ] [-n
+.I external ip
+.B ] [-b
+.I dnsport
+.B ] [-P
+.I password
+.B ]
.I tunnel_ip
+.B [
+.I /netmask
+.B ]
.I topdomain
.SH DESCRIPTION
.B iodine
.B -t chrootdir
Chroot to 'chrootdir' after setting up tunnel.
.TP
+.B -d device
+Use the TUN device 'device' instead of the normal one, which is dnsX on Linux
+and otherwise tunX.
+.TP
.B -P password
Use 'password' to authenticate. If not used,
.B stdin
will be used as input. Only the first 32 characters will be used.
+.SS Client Options:
.TP
-.B -d device
-Use the TUN device 'device' instead of the normal one, which is dnsX on Linux
-and otherwise tunX.
+.B -m fragsize
+Maximum downstream fragsize. Not setting this will cause the client to probe
+the maximum accepted downstream packet size.
.SS Server Options:
.TP
.B -c
Make the server listen on 'port' instead of 53 for traffic.
.B Note:
You must make sure the dns requests are forwarded to this port yourself.
+.TP
+.B -n external ip
+The IP address to return in NS responses. Default is to return the address used
+as destination in the query.
+.TP
+.B -b dnsport
+If this port is specified, all incoming requests not inside the tunnel domain
+will be forwarded to this port on localhost, to be handled by a real dns.
.SS Client Arguments:
.TP
.B nameserver
must be the same on both the client and the server.
.SS Server Arguments:
.TP
-.B tunnel_ip
+.B tunnel_ip[/netmask]
This is the servers ip address on the tunnel interface. The client will be
given the next ip number in the range. It is recommended to use the
-10.0.0.0/8 or 172.16.0.0/12 ranges.
+10.0.0.0 or 172.16.0.0 ranges. The default netmask is /27, can be overriden
+by specifying it here. Using a smaller network will limit the number of
+concurrent users.
.TP
.B topdomain
The dns traffic will is expected to be sent as querys of type NULL for
.TP
.B Server side:
To use this tunnel, you need control over a real domain (like mytunnel.com),
-and a server with a static public IP number that does not yet run a DNS
-server. Then, delegate a subdomain (say, tunnel1.mytunnel.com) to the server.
-If you use BIND for the domain, add these lines to the zone file (replace
-10.15.213.99 with your server ip):
+and a server with a public IP number. If the server already runs a DNS
+server, change the listening port and then use the \-b option to let
+iodined forward the DNS requests. Then, delegate a subdomain
+(say, tunnel1.mytunnel.com) to the server. If you use BIND for the domain,
+add these lines to the zone file (replace 10.15.213.99 with your server ip):
.nf
tunnel1host IN A 10.15.213.99
and configure the server to do NAT.
.TP
.B MTU issues:
-Some relaying DNS servers enforce a 512 byte packet limit. All larger packets are
-simply dropped. If you can ping through the tunnel but not login via SSH, this is
-most likely the case. Set the MTU on the server to 220 to ensure that all packets
-are less than 512 bytes. This will however greatly affect performance.
+These issues should be solved now, with automatic fragmentation of downstream
+packets. There should be no need to set the MTU explicitly on the server.
.SH BUGS
File bugs at http://dev.kryo.se/iodine/
.SH AUTHORS
ToastFreeware / debian / iodine.git / blobdiff