mirror of
https://github.com/yarrick/iodine.git
synced 2024-10-31 23:39:18 +02:00
Revamping the README file
This commit is contained in:
parent
cea498e710
commit
81d932703b
|
@ -1,130 +1,136 @@
|
||||||
|
iodine - <http://code.kryo.se/iodine>
|
||||||
|
=====================================
|
||||||
|
|
||||||
iodine - http://code.kryo.se/iodine
|
|
||||||
|
|
||||||
***********************************
|
|
||||||
|
|
||||||
This is a piece of software that lets you tunnel IPv4 data through a DNS
|
This is a piece of software that lets you tunnel IPv4 data through a DNS
|
||||||
server. This can be usable in different situations where internet access is
|
server. This can be usable in different situations where internet access is
|
||||||
firewalled, but DNS queries are allowed.
|
firewalled, but DNS queries are allowed.
|
||||||
|
|
||||||
|
|
||||||
COMPILING:
|
COMPILING
|
||||||
|
---------
|
||||||
|
|
||||||
Iodine has no configure script. There are two optional features for Linux
|
Iodine has no configure script. There are two optional features for Linux
|
||||||
(SELinux and systemd support) that will be enabled automatically if the
|
(SELinux and systemd support) that will be enabled automatically if the
|
||||||
relevant header files are found in /usr/include. (See script at ./src/osflags)
|
relevant header files are found in `/usr/include`.
|
||||||
|
(See script at `./src/osflags`)
|
||||||
|
|
||||||
Run 'make' to compile the server and client binaries.
|
Run `make` to compile the server and client binaries.
|
||||||
Run 'make install' to copy binaries and manpage to the destination directory.
|
Run `make install` to copy binaries and manpage to the destination directory.
|
||||||
Run 'make test' to compile and run the unit tests. (Requires the check library)
|
Run `make test` to compile and run the unit tests. (Requires the `check` library)
|
||||||
|
|
||||||
|
|
||||||
QUICKSTART:
|
QUICKSTART
|
||||||
|
----------
|
||||||
|
|
||||||
Try it out within your own LAN! Follow these simple steps:
|
Try it out within your own LAN! Follow these simple steps:
|
||||||
- On your server, run: ./iodined -f 10.0.0.1 test.com
|
- On your server, run: `./iodined -f 10.0.0.1 test.com`.
|
||||||
(If you already use the 10.0.0.0 network, use another internal net like
|
If you already use the `10.0.0.0` network, use another internal net like
|
||||||
172.16.0.0)
|
`172.16.0.0`.
|
||||||
- Enter a password
|
- Enter a password.
|
||||||
- On the client, run: ./iodine -f -r 192.168.0.1 test.com
|
- On the client, run: `./iodine -f -r 192.168.0.1 test.com`.
|
||||||
(Replace 192.168.0.1 with your server's ip address)
|
Replace `192.168.0.1` with your server's ip address.
|
||||||
- Enter the same password
|
- Enter the same password.
|
||||||
- Now the client has the tunnel ip 10.0.0.2 and the server has 10.0.0.1
|
- Now the client has the tunnel ip `10.0.0.2` and the server has `10.0.0.1`.
|
||||||
- Try pinging each other through the tunnel
|
- Try pinging each other through the tunnel.
|
||||||
- Done! :)
|
- Done! :)
|
||||||
|
|
||||||
To actually use it through a relaying nameserver, see below.
|
To actually use it through a relaying nameserver, see below.
|
||||||
|
|
||||||
|
|
||||||
HOW TO USE:
|
HOW TO USE
|
||||||
|
----------
|
||||||
|
|
||||||
Note: server and client are required to speak the exact same protocol. In most
|
Note: server and client are required to speak the exact same protocol. In most
|
||||||
cases, this means running the same iodine version. Unfortunately, implementing
|
cases, this means running the same iodine version. Unfortunately, implementing
|
||||||
backward and forward protocol compatibility is usually not feasible.
|
backward and forward protocol compatibility is usually not feasible.
|
||||||
|
|
||||||
Server side:
|
### Server side
|
||||||
To use this tunnel, you need control over a real domain (like mydomain.com),
|
To use this tunnel, you need control over a real domain (like `mydomain.com`),
|
||||||
and a server with a public IP address to run iodined on. If this server
|
and a server with a public IP address to run `iodined` on. If this server
|
||||||
already runs a DNS program, change its listening port and then use iodined's
|
already runs a DNS program, change its listening port and then use `iodined`'s
|
||||||
-b option to let iodined forward the DNS requests. (Note that this procedure
|
`-b` option to let `iodined` forward the DNS requests. (Note that this procedure
|
||||||
is not advised in production environments, because iodined's DNS forwarding
|
is not advised in production environments, because `iodined`'s DNS forwarding
|
||||||
is not completely transparent.)
|
is not completely transparent.)
|
||||||
|
|
||||||
Then, delegate a subdomain (say, t1.mydomain.com) to the iodined server.
|
Then, delegate a subdomain (say, `t1.mydomain.com`) to the iodined server.
|
||||||
If you use BIND for your domain, add two lines like these to the zone file:
|
If you use BIND for your domain, add two lines like these to the zone file:
|
||||||
|
|
||||||
t1 IN NS t1ns.mydomain.com. ; note the dot!
|
t1 IN NS t1ns.mydomain.com. ; note the dot!
|
||||||
t1ns IN A 10.15.213.99
|
t1ns IN A 10.15.213.99
|
||||||
|
|
||||||
The "NS" line is all that's needed to route queries for the "t1" subdomain
|
The `NS` line is all that's needed to route queries for the `t1` subdomain
|
||||||
to the "t1ns" server. We use a short name for the subdomain, to keep as much
|
to the `t1ns` server. We use a short name for the subdomain, to keep as much
|
||||||
space as possible available for the data traffic. At the end of the "NS" line
|
space as possible available for the data traffic. At the end of the `NS` line
|
||||||
is the name of your iodined server. This can be any name, pointing anywhere,
|
is the name of your `iodined` server. This can be any name, pointing anywhere,
|
||||||
but in this case it's easily kept in the same zone file. It must be a name
|
but in this case it's easily kept in the same zone file. It must be a name
|
||||||
(not an IP address), and that name itself must have an A record (not a CNAME).
|
(not an IP address), and that name itself must have an `A` record
|
||||||
|
(not a `CNAME`).
|
||||||
|
|
||||||
If your iodined server has a dynamic IP, use a dynamic dns provider. Simply
|
If your `iodined` server has a dynamic IP, use a dynamic DNS provider. Simply
|
||||||
point the "NS" line to it, and leave the "A" line out:
|
point the `NS` line to it, and leave the `A` line out:
|
||||||
|
|
||||||
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
|
t1 IN NS myname.mydyndnsprovider.com. ; note the dot!
|
||||||
|
|
||||||
Then reload or restart your nameserver program. Now any DNS queries for
|
Then reload or restart your nameserver program. Now any DNS queries for
|
||||||
domains ending in t1.mydomain.com will be sent to your iodined server.
|
domains ending in `t1.mydomain.com` will be sent to your `iodined` server.
|
||||||
|
|
||||||
Finally start iodined on your server. The first argument is the IP address
|
Finally start `iodined` on your server. The first argument is the IP address
|
||||||
inside the tunnel, which can be from any range that you don't use yet (for
|
inside the tunnel, which can be from any range that you don't use yet (for
|
||||||
example 192.168.99.1), and the second argument is the assigned domain (in this
|
example `192.168.99.1`), and the second argument is the assigned domain (in this
|
||||||
case t1.mydomain.com). Using the -f option will keep iodined running in the
|
case `t1.mydomain.com`). Using the `-f` option will keep iodined running in the
|
||||||
foreground, which helps when testing. iodined will open a virtual interface
|
foreground, which helps when testing. iodined will open a virtual interface
|
||||||
("tun device"), and will also start listening for DNS queries on UDP port 53.
|
("tun device"), and will also start listening for DNS queries on UDP port 53.
|
||||||
Either enter a password on the commandline (-P pass) or after the server has
|
Either enter a password on the commandline (`-P pass`) or after the server has
|
||||||
started. Now everything is ready for the client.
|
started. Now everything is ready for the client.
|
||||||
|
|
||||||
If there is a chance you'll be using an iodine tunnel from unexpected
|
If there is a chance you'll be using an iodine tunnel from unexpected
|
||||||
environments, start iodined with a -c option.
|
environments, start `iodined` with a `-c` option.
|
||||||
|
|
||||||
Resulting commandline in this example situation:
|
Resulting commandline in this example situation:
|
||||||
|
|
||||||
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
|
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com
|
||||||
|
|
||||||
Client side:
|
### Client side
|
||||||
All the setup is done, just start iodine. It takes one or two arguments, the
|
All the setup is done, just start `iodine`. It takes one or two arguments, the
|
||||||
first is the local relaying DNS server (optional) and the second is the domain
|
first is the local relaying DNS server (optional) and the second is the domain
|
||||||
you used (t1.mydomain.com). If you don't specify the first argument, the
|
you used (`t1.mydomain.com`). If you don't specify the first argument, the
|
||||||
system's current DNS setting will be consulted.
|
system's current DNS setting will be consulted.
|
||||||
|
|
||||||
If DNS queries are allowed to any computer, you can directly give the iodined
|
If DNS queries are allowed to any computer, you can directly give the `iodined`
|
||||||
server's address as first argument (in the example: t1ns.mydomain.com or
|
server's address as first argument (in the example: `t1ns.mydomain.com` or
|
||||||
10.15.213.99). In that case, it may also happen that _any_ traffic is allowed
|
`10.15.213.99`). In that case, it may also happen that _any_ traffic is allowed
|
||||||
to the DNS port (53 UDP) of any computer. Iodine will detect this, and switch
|
to the DNS port (53 UDP) of any computer. Iodine will detect this, and switch
|
||||||
to raw UDP tunneling if possible. To force DNS tunneling in any case, use the
|
to raw UDP tunneling if possible. To force DNS tunneling in any case, use the
|
||||||
-r option (especially useful when testing within your own network).
|
`-r` option (especially useful when testing within your own network).
|
||||||
|
|
||||||
The client's tunnel interface will get an IP close to the server's (in this
|
The client's tunnel interface will get an IP close to the server's (in this
|
||||||
case 192.168.99.2 or .3 etc.) and a suitable MTU. Enter the same password as
|
case `192.168.99.2` or `.3` etc.) and a suitable MTU. Enter the same password as
|
||||||
on the server either as commandline option or after the client has started.
|
on the server either as commandline option or after the client has started.
|
||||||
Using the -f option will keep the iodine client running in the foreground.
|
Using the `-f` option will keep the iodine client running in the foreground.
|
||||||
|
|
||||||
|
Resulting commandline in this example situation, adding -r forces DNS tunneling
|
||||||
|
even if raw UDP tunneling would be possible:
|
||||||
|
|
||||||
Resulting commandline in this example situation:
|
|
||||||
./iodine -f -P secretpassword t1.mydomain.com
|
./iodine -f -P secretpassword t1.mydomain.com
|
||||||
(add -r to force DNS tunneling even if raw UDP tunneling would be possible)
|
|
||||||
|
|
||||||
From either side, you should now be able to ping the IP address on the other
|
From either side, you should now be able to ping the IP address on the other
|
||||||
end of the tunnel. In this case, ping 192.168.99.1 from the iodine client, and
|
end of the tunnel. In this case, `ping 192.168.99.1` from the iodine client, and
|
||||||
192.168.99.2 or .3 etc. from the iodine server.
|
`192.168.99.2` from the iodine server.
|
||||||
|
|
||||||
|
|
||||||
MISC. INFO:
|
### MISC. INFO
|
||||||
|
|
||||||
IPv6:
|
#### IPv6
|
||||||
At the moment the iodined server only supports IPv4. The data inside the tunnel
|
At the moment the iodined server only supports IPv4. The data inside the tunnel
|
||||||
is IPv4 only.
|
is IPv4 only.
|
||||||
|
|
||||||
The client can use IPv4 or IPv6 nameservers to connect to iodined. The relay
|
The client can use IPv4 or IPv6 nameservers to connect to iodined. The relay
|
||||||
nameservers will translate between protocols automatically if needed. Use
|
nameservers will translate between protocols automatically if needed. Use
|
||||||
options -4 or -6 to force the client to use a specific IP version for its DNS
|
options `-4` or `-6` to force the client to use a specific IP version for its DNS
|
||||||
queries. The client has to force IPv4 if it has dual-stack connectivity and
|
queries. The client has to force IPv4 if it has dual-stack connectivity and
|
||||||
the hostname handling the tunnel domain has both A and AAAA records.
|
the hostname handling the tunnel domain has both `A` and `AAAA` records.
|
||||||
|
|
||||||
Routing:
|
#### Routing
|
||||||
It is possible to route all traffic through the DNS tunnel. To do this, first
|
It is possible to route all traffic through the DNS tunnel. To do this, first
|
||||||
add a host route to the nameserver used by iodine over the wired/wireless
|
add a host route to the nameserver used by iodine over the wired/wireless
|
||||||
interface with the default gateway as gateway. Then replace the default
|
interface with the default gateway as gateway. Then replace the default
|
||||||
|
@ -138,70 +144,77 @@ shell (SSH) access, possibly with port forwarding. The latter can also be used
|
||||||
for web browsing, when you run a web proxy (for example Privoxy) on your
|
for web browsing, when you run a web proxy (for example Privoxy) on your
|
||||||
server.
|
server.
|
||||||
|
|
||||||
Testing:
|
#### Testing
|
||||||
The iodined server replies to NS requests sent for subdomains of the tunnel
|
The `iodined` server replies to `NS` requests sent for subdomains of the tunnel
|
||||||
domain. If your iodined subdomain is t1.mydomain.com, send a NS request for
|
domain. If your iodined subdomain is `t1.mydomain.com`, send a `NS` request for
|
||||||
foo123.t1.mydomain.com to see if the delegation works. dig is a good tool
|
`foo123.t1.mydomain.com` to see if the delegation works.
|
||||||
for this:
|
`dig` is a good tool for this:
|
||||||
dig -t NS foo123.t1.mydomain.com
|
|
||||||
|
% dig -t NS foo123.t1.mydomain.com
|
||||||
|
ns.io.citronna.de.
|
||||||
|
|
||||||
Also, the iodined server will answer requests starting with 'z' for any of the
|
Also, the iodined server will answer requests starting with 'z' for any of the
|
||||||
supported request types, for example:
|
supported request types, for example:
|
||||||
|
|
||||||
dig -t TXT z456.t1.mydomain.com
|
dig -t TXT z456.t1.mydomain.com
|
||||||
dig -t SRV z456.t1.mydomain.com
|
dig -t SRV z456.t1.mydomain.com
|
||||||
dig -t CNAME z456.t1.mydomain.com
|
dig -t CNAME z456.t1.mydomain.com
|
||||||
|
|
||||||
The reply should look like garbled text in all these cases.
|
The reply should look like garbled text in all these cases.
|
||||||
|
|
||||||
Operational info:
|
|
||||||
|
Operational info
|
||||||
|
----------------
|
||||||
|
|
||||||
The DNS-response fragment size is normally autoprobed to get maximum bandwidth.
|
The DNS-response fragment size is normally autoprobed to get maximum bandwidth.
|
||||||
To force a specific value (and speed things up), use the -m option.
|
To force a specific value (and speed things up), use the `-m` option.
|
||||||
|
|
||||||
The DNS hostnames are normally used up to their maximum length, 255 characters.
|
The DNS hostnames are normally used up to their maximum length, 255 characters.
|
||||||
Some DNS relays have been found that answer full-length queries rather
|
Some DNS relays have been found that answer full-length queries rather
|
||||||
unreliably, giving widely varying (and mostly very bad) results of the
|
unreliably, giving widely varying (and mostly very bad) results of the
|
||||||
fragment size autoprobe on repeated tries. In these cases, use the -M switch
|
fragment size autoprobe on repeated tries. In these cases, use the `-M` switch
|
||||||
to reduce the DNS hostname length to for example 200 characters, which makes
|
to reduce the DNS hostname length to, for example 200 characters, which makes
|
||||||
these DNS relays much more stable. This is also useful on some "de-optimizing"
|
these DNS relays much more stable. This is also useful on some “de-optimizing”
|
||||||
DNS relays that stuff the response with two full copies of the query, leaving
|
DNS relays that stuff the response with two full copies of the query, leaving
|
||||||
very little space for downstream data (also not capable of EDNS0). The -M
|
very little space for downstream data (also not capable of EDNS0). The `-M`
|
||||||
switch can trade some upstream bandwidth for downstream bandwidth. Note that
|
switch can trade some upstream bandwidth for downstream bandwidth. Note that
|
||||||
the minimum -M value is about 100, since the protocol can split packets (1200
|
the minimum `-M` value is about 100, since the protocol can split packets (1200
|
||||||
bytes max) in only 16 fragments, requiring at least 75 real data bytes per
|
bytes max) in only 16 fragments, requiring at least 75 real data bytes per
|
||||||
fragment.
|
fragment.
|
||||||
|
|
||||||
The upstream data is sent gzipped encoded with Base32; or Base64 if the relay
|
The upstream data is sent gzipped encoded with Base32; or Base64 if the relay
|
||||||
server supports mixed case and '+' in domain names; or Base64u if '_' is
|
server supports mixed case and `+` in domain names; or Base64u if `_` is
|
||||||
supported instead; or Base128 if high-byte-value characters are supported.
|
supported instead; or Base128 if high-byte-value characters are supported.
|
||||||
This upstream encoding is autodetected. The DNS protocol allows one query per
|
This upstream encoding is autodetected. The DNS protocol allows one query per
|
||||||
packet, and one query can be max 256 chars. Each domain name part can be max
|
packet, and one query can be max 256 chars. Each domain name part can be max
|
||||||
63 chars. So your domain name and subdomain should be as short as possible to
|
63 chars. So your domain name and subdomain should be as short as possible to
|
||||||
allow maximum upstream throughput.
|
allow maximum upstream throughput.
|
||||||
|
|
||||||
Several DNS request types are supported, with the NULL and PRIVATE types
|
Several DNS request types are supported, with the `NULL` and `PRIVATE` types
|
||||||
expected to provide the largest downstream bandwidth. The PRIVATE type uses
|
expected to provide the largest downstream bandwidth. The `PRIVATE` type uses
|
||||||
value 65399 in the private-use range. Other available types are TXT, SRV, MX,
|
value 65399 in the private-use range. Other available types are `TXT`, `SRV`,
|
||||||
CNAME and A (returning CNAME), in decreasing bandwidth order. Normally the
|
`MX`, `CNAME` and `A` (returning `CNAME`), in decreasing bandwidth order.
|
||||||
"best" request type is autodetected and used. However, DNS relays may impose
|
Normally the “best” request type is autodetected and used. However, DNS relays
|
||||||
limits on for example NULL and TXT, making SRV or MX actually the best choice.
|
may impose limits on for example NULL and TXT, making SRV or MX actually the best
|
||||||
This is not autodetected, but can be forced using the -T option. It is
|
choice. This is not autodetected, but can be forced using the `-T` option.
|
||||||
advisable to try various alternatives especially when the autodetected request
|
It is advisable to try various alternatives especially when the autodetected
|
||||||
type provides a downstream fragment size of less than 200 bytes.
|
request type provides a downstream fragment size of less than 200 bytes.
|
||||||
|
|
||||||
Note that SRV, MX and A (returning CNAME) queries may/will cause additional
|
Note that `SRV`, `MX` and `A` (returning `CNAME`) queries may/will cause
|
||||||
lookups by "smart" caching nameservers to get an actual IP address, which may
|
additional lookups by "smart" caching nameservers to get an actual IP address,
|
||||||
either slow down or fail completely.
|
which may either slow down or fail completely.
|
||||||
|
|
||||||
DNS responses for non-NULL/PRIVATE queries can be encoded with the same set of
|
DNS responses for non-`NULL/PRIVATE` queries can be encoded with the same set of
|
||||||
codecs as upstream data. This is normally also autodetected, but no fully
|
codecs as upstream data. This is normally also autodetected, but no fully
|
||||||
exhaustive tests are done, so some problems may not be noticed when selecting
|
exhaustive tests are done, so some problems may not be noticed when selecting
|
||||||
more advanced codecs. In that case, you'll see failures/corruption in the
|
more advanced codecs. In that case, you'll see failures/corruption in the
|
||||||
fragment size autoprobe. In particular, several DNS relays have been found that
|
fragment size autoprobe. In particular, several DNS relays have been found that
|
||||||
change replies returning hostnames (SRV, MX, CNAME, A) to lowercase only when
|
change replies returning hostnames (`SRV`, `MX`, `CNAME`, `A`) to lowercase only
|
||||||
that hostname exceeds ca. 180 characters. In these and similar cases, use the
|
when that hostname exceeds ca. 180 characters. In these and similar cases, use
|
||||||
-O option to try other downstream codecs; Base32 should always work.
|
the `-O` option to try other downstream codecs; Base32 should always work.
|
||||||
|
|
||||||
Normal operation now is for the server to _not_ answer a DNS request until
|
Normal operation now is for the server to _not_ answer a DNS request until
|
||||||
the next DNS request has come in, a.k.a. being "lazy". This way, the server
|
the next DNS request has come in, a.k.a. being “lazy”. This way, the server
|
||||||
will always have a DNS request handy when new downstream data has to be sent.
|
will always have a DNS request handy when new downstream data has to be sent.
|
||||||
This greatly improves (interactive) performance and latency, and allows to
|
This greatly improves (interactive) performance and latency, and allows to
|
||||||
slow down the quiescent ping requests to 4 second intervals by default, and
|
slow down the quiescent ping requests to 4 second intervals by default, and
|
||||||
|
@ -209,24 +222,24 @@ possibly much slower. In fact, the main purpose of the pings now is to force
|
||||||
a reply to the previous ping, and prevent DNS server timeouts (usually at
|
a reply to the previous ping, and prevent DNS server timeouts (usually at
|
||||||
least 5-10 seconds per RFC1035). Some DNS servers are more impatient and will
|
least 5-10 seconds per RFC1035). Some DNS servers are more impatient and will
|
||||||
give SERVFAIL errors (timeouts) in periods without tunneled data traffic. All
|
give SERVFAIL errors (timeouts) in periods without tunneled data traffic. All
|
||||||
data should still get through in these cases, but iodine will reduce the ping
|
data should still get through in these cases, but `iodine` will reduce the ping
|
||||||
interval to 1 second anyway (-I1) to reduce the number of error messages. This
|
interval to 1 second anyway (-I1) to reduce the number of error messages. This
|
||||||
may not help for very impatient DNS relays like dnsadvantage.com (ultradns),
|
may not help for very impatient DNS relays like `dnsadvantage.com` (ultradns),
|
||||||
which time out in 1 second or even less. Yet data will still get trough, and
|
which time out in 1 second or even less. Yet data will still get trough, and
|
||||||
you can ignore the SERVFAIL errors.
|
you can ignore the `SERVFAIL` errors.
|
||||||
|
|
||||||
If you are running on a local network without any DNS server in-between, try
|
If you are running on a local network without any DNS server in-between, try
|
||||||
-I 50 (iodine and iodined close the connection after 60 seconds of silence).
|
`-I 50` (iodine and iodined close the connection after 60 seconds of silence).
|
||||||
The only time you'll notice a slowdown, is when DNS reply packets go missing;
|
The only time you'll notice a slowdown, is when DNS reply packets go missing;
|
||||||
the iodined server then has to wait for a new ping to re-send the data. You can
|
the `iodined` server then has to wait for a new ping to re-send the data. You can
|
||||||
speed this up by generating some upstream traffic (keypress, ping). If this
|
speed this up by generating some upstream traffic (keypress, ping). If this
|
||||||
happens often, check your network for bottlenecks and/or run with -I1.
|
happens often, check your network for bottlenecks and/or run with `-I1`.
|
||||||
|
|
||||||
The delayed answering in lazy mode will cause some "carrier grade" commercial
|
The delayed answering in lazy mode will cause some “carrier grade” commercial
|
||||||
DNS relays to repeatedly re-send the same DNS query to the iodined server.
|
DNS relays to repeatedly re-send the same DNS query to the iodined server.
|
||||||
If the DNS relay is actually implemented as a pool of parallel servers,
|
If the DNS relay is actually implemented as a pool of parallel servers,
|
||||||
duplicate requests may even arrive from multiple sources. This effect will
|
duplicate requests may even arrive from multiple sources. This effect will
|
||||||
only be visible in the network traffic at the iodined server, and will not
|
only be visible in the network traffic at the `iodined` server, and will not
|
||||||
affect the client's connection. Iodined will notice these duplicates, and send
|
affect the client's connection. Iodined will notice these duplicates, and send
|
||||||
the same answer (when its time has come) to both the original query and the
|
the same answer (when its time has come) to both the original query and the
|
||||||
latest duplicate. After that, the full answer is cached for a short while.
|
latest duplicate. After that, the full answer is cached for a short while.
|
||||||
|
@ -236,16 +249,19 @@ iodine client will ignore (if it ever arrives there).
|
||||||
If you have problems, try inspecting the traffic with network monitoring tools
|
If you have problems, try inspecting the traffic with network monitoring tools
|
||||||
like tcpdump or ethereal/wireshark, and make sure that the relaying DNS server
|
like tcpdump or ethereal/wireshark, and make sure that the relaying DNS server
|
||||||
has not cached the response. A cached error message could mean that you
|
has not cached the response. A cached error message could mean that you
|
||||||
started the client before the server. The -D (and -DD) option on the server
|
started the client before the server. The `-D` (and `-DD`) option on the server
|
||||||
can also show received and sent queries.
|
can also show received and sent queries.
|
||||||
|
|
||||||
|
|
||||||
TIPS & TRICKS:
|
TIPS & TRICKS
|
||||||
|
-------------
|
||||||
|
|
||||||
If your port 53 is taken on a specific interface by an application that does
|
If your port 53 is taken on a specific interface by an application that does
|
||||||
not use it, use -p on iodined to specify an alternate port (like -p 5353) and
|
not use it, use `-p` on iodined to specify an alternate port (like `-p 5353`)
|
||||||
use for instance iptables (on Linux) to forward the traffic:
|
and use for instance iptables (on Linux) to forward the traffic:
|
||||||
|
|
||||||
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
|
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
|
||||||
|
|
||||||
(Sent in by Tom Schouten)
|
(Sent in by Tom Schouten)
|
||||||
|
|
||||||
Iodined will reject data from clients that have not been active (data/pings)
|
Iodined will reject data from clients that have not been active (data/pings)
|
||||||
|
@ -265,32 +281,33 @@ DNSCACHE_LEN is still advised, preferably 2 or higher, however you can also
|
||||||
undefine it to save a few more kilobytes.
|
undefine it to save a few more kilobytes.
|
||||||
|
|
||||||
|
|
||||||
PERFORMANCE:
|
PERFORMANCE
|
||||||
|
-----------
|
||||||
|
|
||||||
This section tabulates some performance measurements. To view properly, use
|
This section tabulates some performance measurements. To view properly, use
|
||||||
a fixed-width font like Courier.
|
a fixed-width font like Courier.
|
||||||
|
|
||||||
Measurements were done in protocol 00000502 in lazy mode; upstream encoding
|
Measurements were done in protocol 00000502 in lazy mode; upstream encoding
|
||||||
always Base128; iodine -M255; iodined -m1130. Network conditions were not
|
always Base128; `iodine -M255`; `iodined -m1130`. Network conditions were not
|
||||||
extremely favorable; results are not benchmarks but a realistic indication of
|
extremely favorable; results are not benchmarks but a realistic indication of
|
||||||
real-world performance that can be expected in similar situations.
|
real-world performance that can be expected in similar situations.
|
||||||
|
|
||||||
Upstream/downstream throughput was measured by scp'ing a file previously
|
Upstream/downstream throughput was measured by `scp`'ing a file previously
|
||||||
read from /dev/urandom (i.e. incompressible), and measuring size with
|
read from `/dev/urandom` (i.e. incompressible), and measuring size with
|
||||||
"ls -l ; sleep 30 ; ls -l" on a separate non-tunneled connection. Given the
|
`ls -l ; sleep 30 ; ls -l` on a separate non-tunneled connection. Given the
|
||||||
large scp block size of 16 kB, this gives a resolution of 4.3 kbit/s, which
|
large `scp` block size of 16 kB, this gives a resolution of 4.3 kbit/s, which
|
||||||
explains why some values are exactly equal.
|
explains why some values are exactly equal.
|
||||||
Ping round-trip times measured with "ping -c100", presented are average rtt
|
Ping round-trip times measured with `ping -c100`, presented are average rtt
|
||||||
and mean deviation (indicating spread around the average), in milliseconds.
|
and mean deviation (indicating spread around the average), in milliseconds.
|
||||||
|
|
||||||
|
|
||||||
Situation 1:
|
### Situation 1: `Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter`
|
||||||
Laptop -> Wifi AP -> Home server -> DSL provider -> Datacenter
|
|
||||||
iodine DNS "relay" bind9 DNS cache iodined
|
iodine DNS "relay" bind9 DNS cache iodined
|
||||||
|
|
||||||
downstr. upstream downstr. ping-up ping-down
|
downstr. upstream downstr. ping-up ping-down
|
||||||
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
|
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
|
||||||
------------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
|
|
||||||
iodine -> Wifi AP :53
|
iodine -> Wifi AP :53
|
||||||
-Tnull (= -Oraw) 982 43.6 131.0 28.0 4.6 26.8 3.4
|
-Tnull (= -Oraw) 982 43.6 131.0 28.0 4.6 26.8 3.4
|
||||||
|
@ -314,19 +331,21 @@ iodine -> DSL provider :53
|
||||||
[174.7* : these all have 2frag/packet]
|
[174.7* : these all have 2frag/packet]
|
||||||
|
|
||||||
|
|
||||||
Situation 2:
|
### Situation 2: `Laptop -> Wifi+vpn / wired -> Home server`
|
||||||
Laptop -> Wifi+vpn / wired -> Home server
|
|
||||||
iodine iodined
|
iodine iodined
|
||||||
|
|
||||||
downstr. upstream downstr. ping-up ping-down
|
downstr. upstream downstr. ping-up ping-down
|
||||||
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
|
fragsize kbit/s kbit/s avg +/-mdev avg +/-mdev
|
||||||
------------------------------------------------------------------------------
|
-----------------------------------------------------------------------------
|
||||||
|
|
||||||
wifi + openvpn -Tnull 1186 166.0 1022.3 6.3 1.3 6.6 1.6
|
wifi + openvpn -Tnull 1186 166.0 1022.3 6.3 1.3 6.6 1.6
|
||||||
|
|
||||||
wired -Tnull 1186 677.2 2464.1 1.3 0.2 1.3 0.1
|
wired -Tnull 1186 677.2 2464.1 1.3 0.2 1.3 0.1
|
||||||
|
|
||||||
|
|
||||||
|
### Notes
|
||||||
|
|
||||||
Performance is strongly coupled to low ping times, as iodine requires
|
Performance is strongly coupled to low ping times, as iodine requires
|
||||||
confirmation for every data fragment before moving on to the next. Allowing
|
confirmation for every data fragment before moving on to the next. Allowing
|
||||||
multiple fragments in-flight like TCP could possibly increase performance,
|
multiple fragments in-flight like TCP could possibly increase performance,
|
||||||
|
@ -335,29 +354,33 @@ The current protocol scales performance with DNS responsivity, since the
|
||||||
DNS servers are on average handling at most one DNS request per client.
|
DNS servers are on average handling at most one DNS request per client.
|
||||||
|
|
||||||
|
|
||||||
PORTABILITY:
|
PORTABILITY
|
||||||
|
-----------
|
||||||
|
|
||||||
iodine has been tested on Linux (arm, ia64, x86, AMD64 and SPARC64), FreeBSD
|
iodine has been tested on Linux (arm, ia64, x86, AMD64 and SPARC64), FreeBSD
|
||||||
(ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc and x86, with
|
(ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc and x86, with
|
||||||
http://tuntaposx.sourceforge.net/). and Windows (with OpenVPN TAP32 driver, see
|
<http://tuntaposx.sourceforge.net/>). and Windows (with OpenVPN TAP32 driver, see
|
||||||
win32 readme file). It should be easy to port to other unix-like systems that
|
win32 readme file). It should be easy to port to other unix-like systems that
|
||||||
has TUN/TAP tunneling support. Let us know if you get it to run on other
|
have TUN/TAP tunneling support. Let us know if you get it to run on other
|
||||||
platforms.
|
platforms.
|
||||||
|
|
||||||
|
|
||||||
THE NAME:
|
THE NAME
|
||||||
|
--------
|
||||||
|
|
||||||
The name iodine was chosen since it starts with IOD (IP Over DNS) and since
|
The name iodine was chosen since it starts with IOD (IP Over DNS) and since
|
||||||
iodine has atomic number 53, which happens to be the DNS port number.
|
iodine has atomic number 53, which happens to be the DNS port number.
|
||||||
|
|
||||||
|
|
||||||
THANKS:
|
THANKS
|
||||||
|
------
|
||||||
|
|
||||||
- To kuxien for FreeBSD and OS X testing
|
- To kuxien for FreeBSD and OS X testing
|
||||||
- To poplix for code audit
|
- To poplix for code audit
|
||||||
|
|
||||||
|
|
||||||
AUTHORS & LICENSE:
|
AUTHORS & LICENSE
|
||||||
|
-----------------
|
||||||
|
|
||||||
Copyright (c) 2006-2014 Erik Ekman <yarrick@kryo.se>, 2006-2009 Bjorn
|
Copyright (c) 2006-2014 Erik Ekman <yarrick@kryo.se>, 2006-2009 Bjorn
|
||||||
Andersson <flex@kryo.se>. Also major contributions by Anne Bezemer.
|
Andersson <flex@kryo.se>. Also major contributions by Anne Bezemer.
|
||||||
|
@ -375,5 +398,5 @@ OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
||||||
PERFORMANCE OF THIS SOFTWARE.
|
PERFORMANCE OF THIS SOFTWARE.
|
||||||
|
|
||||||
|
|
||||||
MD5 implementation by L. Peter Deutsch (license and source in src/md5.[ch])
|
MD5 implementation by L. Peter Deutsch (license and source in `src/md5.[ch]`)
|
||||||
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.
|
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises. All rights reserved.
|
Loading…
Reference in New Issue