I2P network node administrator. Full course

I2P (Invisible Internet Project is an open source peer-to-peer network where participant anonymity is the main agenda of all architectural decisions..

There are two main entities in I2P: the router and the endpoint. Router called the software client that must be installed to use I2P. By default, the router publishes real IP addresses and actively interacts with other similar participants, acting as a transit node and expanding its own network pattern, i.e. accumulates information about other available routers for their further use in its tunnels. End point – it is the meaningful entity of the network that conducts hidden activity. For example, a hidden site, or an output proxy of a regular user. The anonymity factor of I2P lies in the secrecy of the locations of the endpoints: identifying the router that is the parent of the endpoint is extremely difficult, and with the proper approach of the administrator, it is impossible.

This manual is dedicated to router administration, i.e. understanding the configuration of an ordinary node that ensures the functioning of the hidden network.

Installation

I2Pd (Invisible Internet Protocol Daemon) is a router from the predominantly Russian-speaking PurpleI2P community. Developed since 2013. Implemented in the C++ programming language, uses the OpenSSL and Boost libraries. I2Pd is cross-platform, ready-made binaries are distributed for Windows, Linux, MacOS and Android platforms. The possibility of manual compilation is obvious, including for operating systems not listed above. I2Pd is available in the standard repositories of some Linux distributions, but it is recommended to use the latest version community repository. The main distribution location for source codes and binaries is GitHub repository.

Fortunately, administering an I2P router on all platforms is virtually identical: the web console at the local address is the main source of information about the current activity of the router. Default web console address: http://127.0.0.1:7070.

Webconsole: Main page

Let's sort it all out in order:

Uptime – Shows elapsed time since startup.

Network status – Reports the network status of the router. In versions above 2.37.0 there is Network status 6 to separately display network status on IPv6 interfaces. Accepts values:

• Testing: Testing the router's network capabilities.

• OK: Everything is okay. This means that the router is operating normally and is available for external connections via TCP and UDP. Typically, the “OK” status appears when the I2Pd port in the operating system is open and the IP address is available globally, i.e. is dedicated, or “white” (or the port for I2Pd is forwarded through NAT).

• Firewalled: This is an indicator that the UDP port is unavailable from the outside. This may be a signal that the working I2Pd port is blocked by the operating system firewall. In most cases, the “Firewalled” status is seen by users behind a NAT server who do not have a dedicated IP address: mainly users of cellular operators.

• Proxy: The router works through a proxy. It implies working only using the NTCP2 protocol (a crypto-analogue of TCP), since SSU (a crypto-analogue of UDP) does not go through a proxy. Configured manually via config.

• mesh: Router operation in a mesh network. At the time of writing, work is supported in Yggdrasil Network. Status mesh involves the router operating exclusively through a mesh network, bypassing the regular Internet. In case of using the mode mesh together with a proxy, or direct work via the Internet, status mesh not displayed.

• Unknown: There is no SSU traffic, and the router configuration does not match the “Proxy” or “Mesh” indicators».

Tunnel creation success rate – Percentage of successfully constructed tunnels, i.e. the percentage of successfully created tunnels from the number initiated by the router. On average varies from 20 to 50%.

Received And Sent – The amount of information received and sent since the router was launched. The current transmission speed is indicated in parentheses.

Transit – Volume of transit traffic and current speed of its flow.

Data path – The working directory of the router, where the keys and local network database are stored.

I2Pd supports a portable mode of operation, when all the necessary application files are stored in one directory next to the executable file. I2Pd automatically starts working in portable mode if the configuration file “i2pd.conf” is located next to the executable file».

Hidden content. Press on text to see – Spoiler with sensitive information about the router. Hidden by default. IP addresses indicating the protocol are displayed here: SSU, SSUv6, NTCP2 and NTCP2v6 (the prefix “v6” indicates operation over IPv6), as well as the cryptographic name of the router (Router Ident), generated from the public key “router.keys”. This key encrypts information addressed to our router.

In section Our external address external IP addresses of the router are displayed, indicating the working port on which the router receives external calls. A random port is generated on first launch and saved in the “router.info” file. It is also possible to specify a random working port manually at startup or in the configuration file. If you see a local address or zeros in the web console, this is a signal that the working port of the router is closed by a firewall, or your IP address is not accessible from the outside (that is, it is not dedicated). In the case of the SSU protocol, when working behind a NAT server (for example, via a USB modem), the address of the provider's NAT server and the port that is currently assigned to you will appear in the list of external addresses of the router (Hole punch).

Of particular interest is the graph Router Caps – in Russian: router flags. These are special markers published by the router, through which other network participants get an idea of ​​​​the capabilities of our router. You may come across the following flags:

• f: Floodfill – the router is a floodfill.

• h: Hidden – the router does not publish its IP addresses.

• K: Channel for transit traffic up to 12KB/sec.

• L: Channel for transit traffic up to 48 KB/sec (default).

• M: Channel for transit traffic up to 64 KB/sec.

• N: Channel for transit traffic up to 128 KB/sec.

• O: Channel for transit traffic up to 256 KB/sec.

• P: Channel for transit traffic up to 2000 KB/sec.

• x: Channel for transit traffic 2000 KB/sec and higher (default value for floodfill).

• R: Reachable - the router is accessible to calls from outside, has a dedicated address and an open port.

• U: Unreachable – the router is not accessible to external requests.

Router flags R And U in I2Pd are indicated for the correct operation of an outdated Java router. I2Pd ignores these flags and uses similar flags from Router Info (RI). It is logical that the availability flags can be different for each address (for example, for IPv4 behind NAT and dedicated IPv6). In RI, flags are specified for each IP address separately.

Router Info – information published by the router about itself, which includes keys, flags and IP addresses. The file “router.info” is generated after each change in the state of the router and is located in the working directory – Data path.

In addition to the above flags R And U, the following are optionally added to the addresses in Router Info:

• 4: Hidden IPv address4.

• 6: Hidden IPv address6.

• B: The SSU address processes peer tests, i.e. can be involved to check the accessibility of the router from outside.

• WITH: The address can be an introducer - an entity that acts as a link to access a node with a hidden IP address. Information about whether the end node is using IPv4 or IPv6 is required for transport layer compatibility after the linker responds (flags 4 And 6). Introducer is a very capacious topic that will be discussed in detail in a separate article..

Routers – Displays the current number of known network routers in the local database.

Floodfills – Displays the current number of routers in the local database that are floodfills - “bulletin boards” where I publish information about myself with server endpoints. Floodfiles are called to obtain input data (keys and tunnels) for any resource in I2P that we access.

LeaseSets – The number of current local LeaseSets - information packets for connecting to hidden network resources. Hidden endpoints publish their LeaseSets independently. The parameter is relevant only for routers that are floodfills and have a good network status of “OK”, i.e. available for external circulation for the purpose of publishing a litset.

Client Tunnels – The number of tunnels built and used by our local router at the current time. Only successfully built tunnels are displayed: as server tunnels, i.e. both receiving connections and client ones, through which we connect to other hidden network resources.

Transit Tunnels – The number of transit tunnels of which the router is currently a part.

At the bottom of the page, under the heading Services indicates the state of services (active or not):

• HTTP Proxy – HTTP proxy for the user to access the hidden network. By default available at 127.0.0.1:4444.

• SOCKS Proxy – Custom SOCKS proxy for accessing a hidden network. By default available at 127.0.0.1:4447.

• BOB (Basic Open Bridge) – Is an interface for application programs running via I2P. The main task is to create dynamic tunnels. Deprecated in Java Router due to the DSA signature being untrusted due to the successful practice of cracking the SHA1 hash used in this signature. In I2Pd, BOB is actively supported, uses up-to-date signature algorithms, and also has protocol extensions that are completely absent in the Java router. In general, it is a relevant tool.

• SAM (Simple Anonymous Messaging) – Is an interface for application programs working via I2P. The main task is also to create dynamic tunnels. In I2Pd, SAM is an equivalent alternative to BOB, and in a Java router it is the only protocol of its kind.

  The similarity between BOB and SAM is due to the initial development by different people with similar goals: BOB for the Robert torrent client, SAM for iMule. As a result, both Robert and iMule faded into the background, but the protocols for interaction between applications and the I2P router remained.

• I2CP (I2P Control Protocol) is a protocol for the interaction of external programs with the router, strictly separating the I2P router from the program accessing the hidden network. The concept is that some application external to the router should handle the data. In practice, this means that the external application must contain ~2/3 of the I2P router code to do anything meaningful. In a Java router, absolutely all traffic passes through the I2CP protocol, which greatly affects the loss of flexibility: streams (TCP sessions - in fact all user activity) cannot control access to tunnels and LeaseSets.

  In practical terms, this means that any external application should have most of the very complex router code, not have access to tunnels, of which the same endpoint always has several, and it would be nice to be able to choose the appropriate one, as well as switch between them. In the end, I2CP, like any layer, entails a drop in performance.

  In I2Pd, the I2CP protocol exists as a compatibility tool with applications written in the Java router paradigm. This protocol has been removed from the working logic of I2Pd, and all client data is processed within the internal libraries libi2pd and libi2pd_client, which allows application programs to fully control their activity in the hidden network.

• I2PControl – a protocol that allows you to obtain information about the operation of the router in the form of requests and responses in JSON format. It is an alternative to the web console and is rarely used, so it will not be discussed in this article..

Webconsole: Router commands

This page presents several intuitive commands that do not change the configuration file and are valid until the router is restarted:

• Run peer test – run a router availability check. It may be necessary if, when starting the router, the working port was closed and the network status is displayed as “Firewalled”. The router automatically checks its availability approximately once an hour, but it is possible to speed up the process manually.

• Decline transit tunnels – reject new transit tunnels (the life cycle of already created transit tunnels will not be interrupted). Nodes offering us to become part of the tunnels will be rejected. The command can be useful when studying the network activity of a server in order to remove all “junk” connections, while maintaining the functionality of hidden I2P services, including the SSH session.

• Start graceful shutdown – start a correct shutdown of the router. After startup, the router will continue normal operation for 10 minutes without accepting new transit connections. Since all tunnels live for 10 minutes, this is enough to turn off the router without breaking the tunnels of other network participants.

• Force shutdown – immediate stop of the I2P router.

• Logging level (none, error, warn, info, debug) – change the logging mode. It can be useful if you suddenly need to debug. Logs will continue to be written to a standard file (/var/log/i2pd/i2pd.log).

• Transit tunnels limit – allows you to change the limit on the number of transit tunnels. Default 2500.

Webconsole: Local Destinations

Here is a list of endpoints located on the router. Each address is formed by a unique key, however, several tunnels can be located on one key, so in most cases it is convenient to use the “I2P tunnels” item to analyze the tunnels separately (comparable to a domain name in a regular network and individual services running on a domain on different ports ). You can see detailed information about the endpoint by clicking on its name.

Base64 – full endpoint address, base64 encoded. Includes the public encryption key, public signing key and other service information. Typically this array is 391 bytes. By the way, the SHA256 hash encoded in base32 from this “Base64” array forms the usual address *.b32.i2p.

Address registration line – allows you to get a string for domain registration on the resources reg.i2p (supported by the i2pd developer community) and stats.i2p (supported by the Java router team). The domain will be linked to the current key for which the registration line is open.

Registration of short domains will be discussed in detail in article about i2pd-tools.

LeaseSets – The number of known LeaseSets that a particular endpoint has. Most often these are the LeaseSets of users with whom our hidden service is currently communicating.

Inbound tunnels And Outbound tunnels – inbound and outbound tunnels of an endpoint hosted on a local router. The essence of the incoming tunnel designations is shown in the illustration; for outgoing tunnels everything is similar..

The number of tunnels (inbound or outbound) cannot exceed 16. By default, server endpoints create five inbound and outbound tunnels, and client endpoints create three. The presence of several tunnels laid through different nodes, but leading to the same endpoint, complicates traffic analysis and is a decisive factor in availability: if one tunnel breaks, traffic begins to flow through another without disrupting the information transfer session.

Tags – a list of addresses that the local endpoint interacted with using one-time cryptographic keys called “tags.” Amount is the number of tags. The minimum number of generated tags, as can be seen in the screenshot, is four. A zero quantity means that previously generated tags have been used up. Applies when using the ElGamal algorithm (internal designation of the encryption type – «0»).

ElGamal is considered a very resource-intensive and outdated algorithm. It is being replaced by encryption type “4” - a new fast end-to-end encryption protocol "ECIES-X25519-AEAD-Ratchet». Tags are also present here, but in a different form.

With this algorithm, the keys are not transmitted over the network: each subscriber derives them mathematically locally. Parameter Incoming Tags denotes the number of tags output for the future, and Tags sessions displays the number of sessions and the addresses with which they are established. Status talking about session state, Where 4 means “Established”, and anything less means the session is frozen for some reason. More 4 – also the norm.

Streams – streams (TCP information transfer sessions), active connections of an external application to I2P via a local router. Compliant with TCP/IP client connections. Stream ID – tunnel number. Necessary to be able to distinguish between different streams, comparable to the port number. The icon with a cross allows you to close, i.e. interrupt the stream. Destination – endpoint address at the other end of the line. Sent And Received – amount of information sent and received in bytes.

RTT – time in milliseconds from sending a packet to confirmation of its receipt. Window – current window size for sending, measured in packets. Buf – number of unsent bytes waiting for space in the window. Out – number of packets in the window without acknowledgment. in – number of received packets that the client application has not yet accepted. Status – stream status, where 1 means open connection.

Packet sizes: 1730 bytes for ElGamal and 1812 bytes for ECIES-X25519-AEAD-Ratchet.

To make it easier to understand the I2P network architecture, which includes a whole stack of protocols with cryptotransports, tunnels and a ton of encryption, and also to find a place in this bundle for a client application, a special illustration is provided. In its own way it is OSI model I2P networks.

Based on this general model, we can say that transit tunnels operate at the second level (at the very bottom, if you look at it), using a minimum of logical resources of the router. Thanks to this, the standard 2500 transit tunnels do not overload the router even on single board computers. The work of a floodfill is somewhat more expensive in terms of resources, because uses end-to-end encryption, so a single-board floodfill with a weak processor may start to fail.

Webconsole: LeaseSets

An item that is relevant for routers that are floodfills. Contains a list of LeaseSets published by us with hidden resources, i.e. anonymous network endpoints. The LeaseSet name is the domain *.b32.i2p without this ending notation. The LeaseSet contains information about the target resource's input tunnel and expiration date (on average 10 minutes). There are also encrypted LeaseSets that cannot be easily analyzed. The topic of LeaseSets is discussed in detail in article.

Webconsole: Tunnels / Transit tunnels

In the tab Tunnels you can see all incoming and outgoing router tunnels initiated by the router itself. Tunnels with a mark exploratory are “probing” - they are built automatically after a short period of time, have low traffic movement and are used for network research: obtaining three random routers from a random floodfill. Also, service requests for the router and publication of your Router Info sometimes go through them.

Transit Tunnels displays only transit tunnels. The information here is more than meager, since all tunnels in I2P are unidirectional and the transit router only knows where to receive and where to transmit other people’s information packets (with the corresponding manipulation of the symmetric encryption key that was issued to it when creating the transit tunnel).

The arrows show the location in the tunnel, and the last number shows the volume of bytes transferred. In theory, additional information about the status of the tunnel and the addresses of neighboring routers can be displayed here, but perhaps this will not happen, because monitoring transit tunnels is not a gentleman's business.

Webconsole: Transports

A page displaying direct interaction with other routers, indicating the number of connections for each protocol (NTCP2, NTCP2v6, SSU, SSUv6). The number of [sent : received] bytes is indicated in square brackets. The arrows indicate the connection status: incoming or outgoing.

Webconsole: I2P Tunnels

The page is similar to “Local destinations”, but is more convenient in practical use, because allows you to analyze each tunnel separately, even if several tunnels use the same key (same address). The name of the tunnel is taken from its configuration file.

Three types of tunnels are displayed: client, server and Server Forwards. “Forwards” tunnels are UDP tunnels: they can be either server or client.

Webconsole: SAM sessions

A page with a list of sessions of external applications with the router using the SAM protocol. The session name is specified by the application. By clicking on the session, you can see the external I2P address of the session and a list of local connections to the router within the SAM session. The BOB protocol may have a similar interface, but due to its low popularity, the page is not available in the web console (but theoretically could be added in the future). In short, if you write applications for I2P, it is better to focus on the API in the form of the SAM protocol, so that poor Java router users could also use your product.

Connecting to the web console of a remote router

I2Pd web console supports configuration with access to an external address and allows you to enable user authorization by login and password. An example of such a configuration is shown in the illustration (two types of syntax supported by the I2Pd config are shown).

This approach is fraught with vulnerability in the case when the connection to the web console is made via the regular Internet without using additional traffic encryption (https). One of the most practical and safest ways is to connect to the web console via SSH with the port forwarded. The SSH protocol does not require additional security, as it has built-in encryption, and is excellent for everyday use due to its simplicity and prevalence. The local port is forwarded to the remote machine using the -D flag: ssh -D 8888 user@<server ip> -p <ssh port>.

The above command will allow you to connect to a SOCKS proxy in your browser at 127.0.0.1:8888 and access the global network from the server’s IP address, as well as have access to the local resources of the remote machine, as if a browser was running on it. Including you will be able to connect to a local address 127.0.0.1:7070 to the web console of the I2P router deployed on the server.

Configuration file

Despite the router's ability to work with passed values ​​(startup parameters), a common practice is to use a configuration file. On Debian, when installing from a config package i2pd.conf located in the directory /etc/i2pd/. When running a binary without installation (for example, after manually compiling a router), the configuration file is read from the directory ~./i2pd/. On Android, all working files of the router (including config) are located in one folder, most often this /sdcard/i2pd/. On Windows the default working directory is %AppData%\i2pd.

Configuration files on different operating systems take the same values ​​with minor exceptions, which can be found in official documentation. The standard config with comments can be found in the sources, in contrib folder (when installing from a package it appears in the system).

The configuration file supports two types of syntax:

1. Indication of the configurable section in square brackets with the parameters of this section listed below until the next square brackets;

2. Specifying a parameter with a dot after the section name.

Default parameters (mainly when running without a configuration file):

• The web console is enabled and can be accessed at http://127.0.0.1:7070

• HTTP proxy enabled, available at 127.0.0.1:4444

• SOCKS proxy enabled, available at 127.0.0.1:4447

• SAM enabled, available at 127.0.0.1:7656

• The background mode of the router is active (daemon)

• Logging at the “warn” level (from “warning” - attention!)

• IPv4 – enabled, IPv6 – disabled

  Options not mentioned are disabled by default.

Obviously, it is unnecessary to describe the entire config here, which without it has comments. Therefore, we will focus only on points that often raise questions, or are a rake for novice users.

family – additional identifying feature of the router. In a concept that only a few believed in, including the leading developer of a Java router with the nickname zzz, family is indicated by respectable users so that routers of the same administrator do not appear together in the same tunnel. As it is not difficult to understand, this option is never used by anyone, but by malicious people who want to capture as many tunnels as possible to try to monitor the network, – family not even used.

[reseed] – Parameters for receiving a start package (reseed) with several routers to begin interacting with the I2P network. First of all, the resid is important at the first start, when the local network database is empty (the netDb folder).

verify – Verification of the signature of the received resid. By default, the option is disabled. However, in the standard config it is in the “true” state. It is assumed that a copy of the configuration file is available after installation from a package that includes the start node certificates (certificates folder). If you enable verification without having certificates, the router will not be able to start.

urls – addresses from one of which the resid will be downloaded (for example, https://example.ru/).

yggurls – Yggdrasil IPv6 addresses, from one of which the resid will be downloaded (http:// without s).

file – path to local .su3 file, or direct https link.

zipfile – path to the local zip archive of the router base, or direct https link.

proxy – proxy used when accessing resid.

threshold – the minimum number of known routers, upon reaching which one of the resids will be contacted. Default – 25.

[persist] – Section responsible for saving some dynamic information to disk.

profiles – is responsible for saving router profiles to disk, which makes them available the next time you start them. Profiles are text files with information about the quality of interaction with the router. For example, routers that do not allow transit tunnels to be built through them are removed from the local database.

addressbook – is responsible for storing complete addresses. When disabled, reduces the load on the disk.

Afterword

The article omits some technical issues related to setting up the operating system, because... the main topic is not system administration for beginners, but managing an I2P router.

Don't forget about the function --help, built into the router, as well as official documentation. These tools will help you with practical configuration.

In the following articles we will consider the configuration of tunnels, types of LeaseSets, secure key storage, multihoming and registration of short domains in the “.i2p” zone».