CarderPlanet
Professional
- Messages
- 2,552
- Reaction score
- 712
- Points
- 83
Most internet users do not have a dedicated address. This is due to the limited IP address range of version 4 (IPv4) of 4.2 billion. Considering that there are twice as many people on the planet, and even some of them have several gadgets - you will not find enough addresses. The problem is solved in the IPv6 protocol, which has an unimaginably large range, where there will be enough addresses for the entire solar system, even when all the planets are inhabited. The catch, however, is that IPv6 is being implemented very slowly and reluctantly into today's network. Therefore, we have what we have: Internet providers release hundreds and thousands of people into the global network under one IPv4 address (through a NAT server).
The model of access to the network through NAT works only in one direction - from the user behind the NAT to the web resource. When a connection is established by a user, the web server can respond to it, but if there is no established session, the user cannot be reached from the outside, because thousands of other subscribers of the provider access the network under the same IP address , which in fact does not belong to any of them. ...
In terms of I2P, the complexity of the situation lies in the fact that the hidden network is completely decentralized and all participants communicate with their neighbors directly. The question that this article will answer: how is interaction with users whose I2P routers are out of direct access to establish a connection.
In the TCP protocol, information is transmitted within an established session with packet integrity control. In UDP, information just flies to a given address without any control.
In UDP, there is the concept of "hole punch", which means a short-term reservation of a port on a NAT server, which is assigned to a subscriber. All information coming to this port will be transmitted to a specific subscriber. In order for the created window to remain assigned to the subscriber, he needs to regularly send any information through it.
From all that has been said, the main thing is to understand that as long as a UDP window (hole punch) exists, anyone can send information to it, and the user to whom the window is assigned will receive it. No pre-established sessions are required as in TCP.
NTCP2 uses TCP as a transport, therefore it has a direct dependence on a dedicated IP address. If there is no direct accessibility, NTCP2 will not work. It is logical that SSU runs on top of UDP and has a window-like feature. This allows the SSU to be used to work without a white address, for example, when using a cellular connection.
The screenshot shows the web interface of a router running on a USB modem. Two columns are highlighted: network status with unavailable status and a list of external addresses. The SSU column displays the address of the provider's NAT server and the port that is currently assigned to the subscriber, that is, it is a window (hole punch). NTCP2 shows no signs of life, all connections to the outside world go through the SSU, and for the provider this is encrypted UDP traffic.
It should be noted that the traffic of the user application and the I2P transport protocol are two independent planes, ie in fact, user TCP traffic can be sent over the SSU.
In addition to the general router flags, there are flags for each address specified in the RI. For example, IPv4 can be nat and IPv6 is globally available. Agree that it is at least unreasonable to designate two addresses with completely different status with one common flag.
There are not many special flags for addresses:
We are interested in the C flag, which signals that the router can act as an introducer. In the modern implementation of i2pd, this flag is assigned automatically if there is direct access via SSU, that is, the I2P router has a dedicated IP address and an open port for receiving external requests without breaking the window.
When working behind a NAT, a router looks in its database for an RI, which can be a conductor. When contacting a router with a request for a guide service, consent is expected. If consent is obtained, the poorly accessible router acquires a conductor and from that moment it can accept connections initiated from the outside.
When a router works through an explorer, it enters its address and expiration time into its Router Info. The agreement between the router and the conductor lasts an hour, after which the router selects a new conductor, or re-turns to the old one, resetting the hour counter. The new Router Info is communicated to all current interlocutors, and is also published on floodfiles. As a rule, the router uses the services of three conductors at the same time, publishing the address of each in the RI.
The task of the conductor is to mediate the establishment of a session between his ward router and the third node.
The external router (Alice in the screenshot) sends a request to the conductor (Bob), who sends information about the new connection to the router behind Nat (Charlie). The message (RelayIntro) tells the IP address and port of the person who wants to establish the connection. The router behind Nat sends an empty UDP packet to this address, thereby forming a window (hole punch). Then, through this window, a full initialization of the SSU connection takes place.
Thus, a connection can be established between two routers, each of which is located behind the nat: the first, when accessing the conductor, forms a window, and the second router, when accessing the interlocutor's window, forms its own window. After that, two I2P routers without dedicated IP addresses communicate directly with each other. Gracefully!
For a more detailed acquaintance with the mechanisms of SSU, see the documentation.
It is important to understand that we are talking about a direct connection to the router, and not directly to some of our hidden resources. Connecting to hidden resources almost always occurs through a chain of transit routers, where only the nearest neighbor in the tunnel will connect to our router through a conductor.
In order for i2pd with a dedicated IP address to work through conductors, publishing only their addresses, you must deny incoming connections to the working port of the I2P router (that is, close the working port specified on the main page in the web console) ...
The working port in the screenshot is 19972
For iptables the firewall rule, it will look like this:
If you have an IPv6 interface, perform similar operations with it through the utility ip6tables.
At the output, we get a router with a "Firewalled" network status and an operating mode exclusively through conductors. However, it should be borne in mind that this can insignificantly damage the speed.
The model of access to the network through NAT works only in one direction - from the user behind the NAT to the web resource. When a connection is established by a user, the web server can respond to it, but if there is no established session, the user cannot be reached from the outside, because thousands of other subscribers of the provider access the network under the same IP address , which in fact does not belong to any of them. ...
In terms of I2P, the complexity of the situation lies in the fact that the hidden network is completely decentralized and all participants communicate with their neighbors directly. The question that this article will answer: how is interaction with users whose I2P routers are out of direct access to establish a connection.
UDP Hole punch
To understand the next part of the article, you need to consider the UDP information transfer protocol. UDP does not control the integrity of packets, but it can transmit them very quickly. An illustrative example of using UDP is video and audio calls over the Internet, where irrecoverable loss of information is preferable than listening to irrelevant words five seconds ago after freezing, or NTP is a time synchronization protocol where minimum latency is needed.In the TCP protocol, information is transmitted within an established session with packet integrity control. In UDP, information just flies to a given address without any control.
In UDP, there is the concept of "hole punch", which means a short-term reservation of a port on a NAT server, which is assigned to a subscriber. All information coming to this port will be transmitted to a specific subscriber. In order for the created window to remain assigned to the subscriber, he needs to regularly send any information through it.
From all that has been said, the main thing is to understand that as long as a UDP window (hole punch) exists, anyone can send information to it, and the user to whom the window is assigned will receive it. No pre-established sessions are required as in TCP.
A little about I2P transport protocols
I2P uses crypto-wrappers for the TCP and UDP protocols - these are NTCP2 and SSU, respectively. These are the lowest-level I2P protocols through which all information transfer between nodes is carried out. These protocols are sometimes referred to as the crypto analogs of TCP and UDP, but in fact they are crypto wrappers that run on top of TCP and UDP.NTCP2 uses TCP as a transport, therefore it has a direct dependence on a dedicated IP address. If there is no direct accessibility, NTCP2 will not work. It is logical that SSU runs on top of UDP and has a window-like feature. This allows the SSU to be used to work without a white address, for example, when using a cellular connection.
The screenshot shows the web interface of a router running on a USB modem. Two columns are highlighted: network status with unavailable status and a list of external addresses. The SSU column displays the address of the provider's NAT server and the port that is currently assigned to the subscriber, that is, it is a window (hole punch). NTCP2 shows no signs of life, all connections to the outside world go through the SSU, and for the provider this is encrypted UDP traffic.
It should be noted that the traffic of the user application and the I2P transport protocol are two independent planes, ie in fact, user TCP traffic can be sent over the SSU.
Explorer flag
The article on floodfiles describes the mechanics of publishing information about themselves by routers (Router Info, abbreviated as "RI"), which contains public encryption keys and flags (Router Caps) that report the router's bandwidth and other important parameters. Based on this information, network participants choose routers to participate in their tunnels.In addition to the general router flags, there are flags for each address specified in the RI. For example, IPv4 can be nat and IPv6 is globally available. Agree that it is at least unreasonable to designate two addresses with completely different status with one common flag.
There are not many special flags for addresses:
We are interested in the C flag, which signals that the router can act as an introducer. In the modern implementation of i2pd, this flag is assigned automatically if there is direct access via SSU, that is, the I2P router has a dedicated IP address and an open port for receiving external requests without breaking the window.
Guides (introducer)
An I2P router that communicates with the outside world exclusively through SSU through hole punching cannot publish the temporary address and port from the current window to Router Info.When working behind a NAT, a router looks in its database for an RI, which can be a conductor. When contacting a router with a request for a guide service, consent is expected. If consent is obtained, the poorly accessible router acquires a conductor and from that moment it can accept connections initiated from the outside.
When a router works through an explorer, it enters its address and expiration time into its Router Info. The agreement between the router and the conductor lasts an hour, after which the router selects a new conductor, or re-turns to the old one, resetting the hour counter. The new Router Info is communicated to all current interlocutors, and is also published on floodfiles. As a rule, the router uses the services of three conductors at the same time, publishing the address of each in the RI.
The task of the conductor is to mediate the establishment of a session between his ward router and the third node.
The external router (Alice in the screenshot) sends a request to the conductor (Bob), who sends information about the new connection to the router behind Nat (Charlie). The message (RelayIntro) tells the IP address and port of the person who wants to establish the connection. The router behind Nat sends an empty UDP packet to this address, thereby forming a window (hole punch). Then, through this window, a full initialization of the SSU connection takes place.
Thus, a connection can be established between two routers, each of which is located behind the nat: the first, when accessing the conductor, forms a window, and the second router, when accessing the interlocutor's window, forms its own window. After that, two I2P routers without dedicated IP addresses communicate directly with each other. Gracefully!
For a more detailed acquaintance with the mechanisms of SSU, see the documentation.
Improper use
Using the feature with conductors (introducer) is also possible in the case of a dedicated IP address. This may be needed to hide the IP address from the Router Info file. In this case, even a detailed analysis of known I2P routers will not give out to attackers the IP address of our router, because it is not published in the clear, but is transmitted personally to everyone who establishes a connection with us.It is important to understand that we are talking about a direct connection to the router, and not directly to some of our hidden resources. Connecting to hidden resources almost always occurs through a chain of transit routers, where only the nearest neighbor in the tunnel will connect to our router through a conductor.
In order for i2pd with a dedicated IP address to work through conductors, publishing only their addresses, you must deny incoming connections to the working port of the I2P router (that is, close the working port specified on the main page in the web console) ...
The working port in the screenshot is 19972
For iptables the firewall rule, it will look like this:
Code:
iptables -A INPUT -p tcp --dport <i2pd_port> -j DROP
iptables -A INPUT -p udp --dport <i2pd_port> -j DROPIf you have an IPv6 interface, perform similar operations with it through the utility ip6tables.
At the output, we get a router with a "Firewalled" network status and an operating mode exclusively through conductors. However, it should be borne in mind that this can insignificantly damage the speed.
