[svn-upgrade] Integrating new upstream version, iodine (0.5.0)
[debian/iodine.git] / man / iodine.8
index fdb28fed53d2c0e1e4cdff03df4fadffb04bc67f..9eb88f01a7497e8fbfd38eb5fd0142dee14e7bf7 100644 (file)
@@ -11,6 +11,8 @@ iodine, iodined \- tunnel IPv4 over DNS
 .I user
 .B ] [-P
 .I password
 .I user
 .B ] [-P
 .I password
+.B ] [-m
+.I fragsize
 .B ] [-t
 .I chrootdir
 .B ] [-d
 .B ] [-t
 .I chrootdir
 .B ] [-d
@@ -27,18 +29,27 @@ iodine, iodined \- tunnel IPv4 over DNS
 
 .B iodined [-c] [-s] [-f] [-D] [-u
 .I user
 
 .B iodined [-c] [-s] [-f] [-D] [-u
 .I user
-.B ] [-P
-.I password
 .B ] [-t
 .I chrootdir
 .B ] [-t
 .I chrootdir
+.B ] [-d
+.I device
 .B ] [-m
 .I mtu
 .B ] [-l
 .I listen_ip
 .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
 .I tunnel_ip
+.B [
+.I /netmask
+.B ]
 .I topdomain
 .SH DESCRIPTION
 .B iodine
 .I topdomain
 .SH DESCRIPTION
 .B iodine
@@ -68,14 +79,19 @@ Drop privileges and run as user 'user' after setting up tunnel.
 .B -t chrootdir
 Chroot to 'chrootdir' after setting up tunnel.
 .TP
 .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.
 .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
 .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
 .SS Server Options:
 .TP
 .B -c
@@ -100,6 +116,14 @@ connections.
 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.
 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
 .SS Client Arguments:
 .TP
 .B nameserver
@@ -119,10 +143,12 @@ is the iodined server, then the topdomain can be chosen freely. This argument
 must be the same on both the client and the server.
 .SS Server Arguments:
 .TP
 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 
 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 topdomain
 The dns traffic will is expected to be sent as querys of type NULL for 
@@ -157,10 +183,11 @@ To actually use it through a relaying nameserver, see below.
 .TP
 .B Server side:
 To use this tunnel, you need control over a real domain (like mytunnel.com),
 .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
 
 .nf
 tunnel1host    IN      A       10.15.213.99
@@ -194,10 +221,8 @@ replace the default gateway with the servers IP address within the DNS tunnel,
 and configure the server to do NAT.
 .TP
 .B MTU issues:
 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
 .SH BUGS
 File bugs at http://dev.kryo.se/iodine/
 .SH AUTHORS