* update & reformat tunnels.cfg.md

hagen
2015-12-09 05:26:29 +00:00
parent cb88743c0c
commit 1ae41ab6ba

@@ -1,46 +1,66 @@
tunnels.cfg is designed to support multiple I2P tunnels.
Must be located in ~/.i2pd.
Overview
--------
tunnels.cfg is designed to support multiple I2P tunnels. Must be located in ``~/.i2pd`` (per-user) or ``/var/lib/i2pd`` (system-wide).
This file uses .ini file format. It consists of multiple sections with unique name each.
Section type is specified by 'type' parameter with possible values 'client', 'server' or 'http'. Each 'client' specifies I2P client tunnel and each 'server' specifies I2P server tunnel. 'http' is special type of server tunnel for eepsites.
Client tunnels
--------------
Mnemonic: WE can connect to someone as client
.ini file format.
Consists of multiple sections with unique name each.
Section type is specified by 'type' parameter with possible values 'client', 'server' or 'http'.
Each 'client' specifies I2P client tunnel and each 'server' specifies I2P server tunnel.
'http' is special type of server tunnel for eepsites.
Must contain few mandatory parameters, some optional parameters might be also presented.
Example of client tunnel:
Example of client tunnel:
`[IRC]`
`type=client`
`address=0.0.0.0`
`port=6668`
`destination=irc.echelon.i2p`
`keys=irc.dat `
If 'keys' is empty, transient keys will be created on every restart.
If keys file is not found, new keys will be created and store into specified file.
Client tunnels might share same local destination, if keys file contains same identity.
'adddress' means local interface tunnel binds to, '127.0.0.1' for connections from local host only,
'0.0.0.0' for connections from everywhere.
[irc-out]
type = client
address = 127.0.0.1
port = 6668
destination = irc.echelon.i2p
keys = irc.dat
Example of server tunnel:
`[smtp]`
`type=server`
`host=127.0.0.1`
`port=25`
`keys=sendmail.dat`
If 'keys' is empty, transient keys will be created on every restart. If keys file is not found, new keys will be created and store into specified file.
Keys must be presented, LeaseSet of address from keys file will be published.
Server tunnel must use it's own local destination.
Client tunnels might share same local destination, if keys file contains same identity.
'address' means local interface tunnel binds to, '127.0.0.1' for connections from local host only, '0.0.0.0' for connections from everywhere.
So, if we telnet to 127.0.0.1/6668 on localhost, i2pd will connect us to irc.echelon.i2p:6668
Server/generic tunnels
----------------------
Mnemonic: WE serving some service to others in network
Example of server tunnel:
[smtp-in]
type = server
host = 127.0.0.1
port = 25
keys = smtp-in.dat
'keys' must be presented, LeaseSet of address from keys file will be published. Server tunnel must use its own local destination.
Optional parameters:
inport - what port at local destination server tunnel listens to. Same as 'port' by default.
accesslist - list of comma-separated of b32 address (without .b32.i2p) allowed to connect. Everybody is allowed by default.
'http' tunnel works same way as server tunnel, but replace 'Host: ' field in HTTP header to address provided in configuration. Also resolves it if necessary.
'inport' - what port at local destination server tunnel listens to. Same as 'port' by default.
'accesslist' - list of comma-separated of b32 address (without .b32.i2p) allowed to connect. Everybody is allowed by default.
Server/http tunnels
-------------------
'http' tunnel works same way as server tunnel, but replace 'Host:' field in HTTP header to address provided in configuration. Also resolves it if necessary.
Example of http tunnel:
`[i2pd]`
`type=http`
`host=i2pd.website`
`port=80`
`keys=i2pd.dat`
[http-in]
type = http
host = website.i2p
port = 80
keys = our-website.dat