mirror of
https://github.com/yarrick/iodine.git
synced 2024-11-22 04:56:07 +03:00
Update readme and manpage
This commit is contained in:
parent
23dc3f0844
commit
72aedb9638
20
README
20
README
@ -64,15 +64,25 @@ be able to ping the other end of the tunnel from either side.
|
|||||||
|
|
||||||
MISC. INFO:
|
MISC. INFO:
|
||||||
|
|
||||||
Try experimenting with the MTU size (-m option) to get maximum bandwidth. It is
|
Routing:
|
||||||
set to 1024 by default, which seems to work with most DNS servers. If you have
|
The normal case is to route all traffic through the DNS tunnel. To do this, first
|
||||||
problems, try setting it to 220 as this ensures all packets to be < 512 bytes.
|
add a route to the nameserver you use with the default gateway as gateway. Then
|
||||||
Some DNS servers enforce a 512 byte packet limit, and this is probably the case
|
replace the default gateway with the servers IP address within the DNS tunnel,
|
||||||
if you can ping through the tunnel but not login via SSH.
|
and configure the server to do NAT.
|
||||||
|
|
||||||
|
MTU issues:
|
||||||
|
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.
|
||||||
|
|
||||||
If you have problems, try inspecting the traffic with network monitoring tools
|
If you have problems, try inspecting the traffic with network monitoring tools
|
||||||
and make sure that the relaying DNS server has not cached the response. A
|
and make sure that the relaying DNS server has not cached the response. A
|
||||||
cached error message could mean that you started the client before the server.
|
cached error message could mean that you started the client before the server.
|
||||||
|
The -D option on the server can also show received and sent queries.
|
||||||
|
|
||||||
|
The iodined server replies to NS requests sent for subdomains of the tunnel
|
||||||
|
domain. If your domain is tunnel.com, send a NS request for foo.tunnel.com
|
||||||
|
to see if the delegation works. dig is a good tool for this:
|
||||||
|
dig -t NS foo123.tunnel.com
|
||||||
|
|
||||||
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 support '+' in domain names. DNS protocol allows one query per packet,
|
server support '+' in domain names. DNS protocol allows one query per packet,
|
||||||
|
@ -229,6 +229,13 @@ add a route to the nameserver you use with the default gateway as gateway. Then
|
|||||||
replace the default gateway with the servers IP address within the DNS tunnel,
|
replace the default gateway with the servers IP address within the DNS tunnel,
|
||||||
and configure the server to do NAT.
|
and configure the server to do NAT.
|
||||||
.TP
|
.TP
|
||||||
|
.B Troubleshooting:
|
||||||
|
Use the \-D option on the server to show received and sent queries, or a
|
||||||
|
tool like Wireshark/tcpdump. The iodined server replies to NS requests sent for
|
||||||
|
subdomains of the tunnel domain. If your domain is tunnel.com, send a NS
|
||||||
|
request for foo.tunnel.com to see if the delegation works. dig is a good tool
|
||||||
|
for this: dig \-t NS foo123.tunnel.com
|
||||||
|
.TP
|
||||||
.B MTU issues:
|
.B MTU issues:
|
||||||
These issues should be solved now, with automatic fragmentation of downstream
|
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.
|
packets. There should be no need to set the MTU explicitly on the server.
|
||||||
|
Loading…
Reference in New Issue
Block a user