enoch/n2n
1
0
Fork 0
mirror of https://github.com/ntop/n2n.git synced 2024-09-19 16:41:11 +02:00
Code Issues Actions Packages Projects Releases 1 Wiki Activity

Merge pull request #336 from Logan007/editReadme

Browse Source 
revised documentation
This commit is contained in:
Luca Deri 2020-07-29 11:47:01 +02:00 committed by GitHub
commit a515823885
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 60 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
README.md
View File

@ -1,15 +1,15 @@
# N2N # n2n
N2N is a light VPN software which make it easy to create virtual networks bypassing intermediate firewalls. n2n is a light VPN software which make it easy to create virtual networks bypassing intermediate firewalls.
In order to start using N2N, two elements are required: In order to start using n2n, two elements are required:
- A _supernode_: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet. - A _supernode_: it allows edge nodes to announce and discover other nodes. It must have a port publicly accessible on internet.
- _edge_ nodes: the nodes which will be part of the virtual networks - _edge_ nodes: the nodes which will be part of the virtual networks
A virtual network shared between multiple edge nodes in n2n is called a _community_. A single supernode can relay multiple communities and a single PC can be part of multiple communities at the same time. An encryption key can be used by the edge nodes to encrypt the packets within their community. A virtual network shared between multiple edge nodes in n2n is called a _community_. A single supernode can relay multiple communities and a single PC can be part of multiple communities at the same time. An encryption key can be used by the edge nodes to encrypt the packets within their community.
N2N tries to establish a direct P2P connection between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets. n2n tries to establish a direct peer-to-peer connection between the edge nodes when possible. When this is not possible (usually due to special NAT devices), the supernode is also used to relay the packets.
## Quick Setup ## Quick Setup
@ -29,9 +29,9 @@ $ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.2 -f -l supernode.ntop.o
Now the two hosts can ping each other. Now the two hosts can ping each other.
**IMPORTANT** It is strongly advised to choose a custom community name (`-c`) and a secret encryption key (`-k`) in order to prevent other users to connect to your PC. For privacy and to reduce the above server load, it is also suggested to set up a custom supernode as explained below. **IMPORTANT** It is strongly advised to choose a custom community name (`-c`) and a secret encryption key (`-k`) in order to prevent other users to connect to your computer. For privacy and to reduce the above server load, it is also suggested to set up a custom supernode as explained below.
## Setting up a custom Supernode ## Setting up a Custom Supernode
You can create your own infrastructure by setting up a supernode on a public server (e.g. a VPS). You just need to open a single port (1234 in the example below) on your firewall (usually `iptables`). You can create your own infrastructure by setting up a supernode on a public server (e.g. a VPS). You just need to open a single port (1234 in the example below) on your firewall (usually `iptables`).
@ -45,25 +45,6 @@ You can create your own infrastructure by setting up a supernode on a public ser
Now the supernode service should be up and running on port 1234. On your edge nodes you can now specify `-l your_supernode_ip:1234` to use it. All the edge nodes must use the same supernode. Now the supernode service should be up and running on port 1234. On your edge nodes you can now specify `-l your_supernode_ip:1234` to use it. All the edge nodes must use the same supernode.
## Routing the traffic
Reaching a remote network or tunneling all the internet traffic via n2n are two common tasks which require a proper routing setup. In this context, the `server` is the edge node which provides access to the remote network/internet, whereas the `client` is the connecting edge node.
In order to enable routing, the `server` must be configured as follows:
1. Add the `-r` option to the edge options to enable routing
2. Enable packet forwarding with `sudo sysctl -w net.ipv4.ip_forward=1`
3. Enable IP masquerading: `sudo iptables -t nat -A POSTROUTING -j MASQUERADE`
On the client side, the easiest way to configure routing is via the `-n` option. For example:
- In order to connect to the remote network `192.168.100.0/24`, use `-n 192.168.100.0/24:10.0.0.1`
- In order to tunnel all the internet traffic, use `-n 0.0.0.0/0:10.0.0.1`
10.0.0.1 is the IP address of the gateway to use to route the specified network. It should correspond to the IP address of the `server` within n2n. Multiple `-n` options can be specified.
As an alternative to the `-n` option, the `ip route` linux command can be manually used. See the [n2n_gateway.sh](doc/n2n_gateway.sh) script for an example. See also [Routing.md](doc/Routing.md) for other use cases and in depth explanation.
## Manual Compilation ## Manual Compilation
On linux, compilation from source is straight forward: On linux, compilation from source is straight forward:
@ -77,14 +58,12 @@ make
make install make install
``` ```
Parts of the code – especially Speck cipher and the header encryption – speedwise benefit Parts of the code significantly benefit from compiler optimizations and platform features such as NEON, SSE and AVX. To enable, use `./configure CFLAGS="-O3 -march=native"` for configuration instead.
from compiler optimizations and platform features such as NEON, SSE and AVX. To enable,
use `./configure CFLAGS="-O3 -march=native"` for configuration instead.
For Windows, check out [Windows.md](doc/Windows.md) for compilation and run instuctions. For Windows, check out [Windows.md](doc/Windows.md) for compilation and run instuctions.
For MacOS, check out [macOS.md](doc/macOS.md). For MacOS, check out [macOS.md](doc/macOS.md).
## Running edge as a service ## Running edge as a Service
edge can also be run as a service instead of cli: edge can also be run as a service instead of cli:
@ -95,35 +74,33 @@ edge can also be run as a service instead of cli:
You can run multiple edge service instances by creating `/etc/n2n/edge-instance1.conf` and You can run multiple edge service instances by creating `/etc/n2n/edge-instance1.conf` and
starting it with `sudo systemctl start edge@instance1`. starting it with `sudo systemctl start edge@instance1`.
## Security Considerations
When payload encryption is enabled (provide a key using `-k`), the supernode will not be able to decrypt
the traffic exchanged between two edge nodes, but it will know that edge A is talking with edge B.
The choice of encryption schemes that can be applied to payload has recently been enhanced. Please have
a look at [CRYPTO.md](doc/CRYPTO.md) for a quick comparison chart to help make a choice. n2n edge nodes use
Twofish encryption by default for compatibility reasons with existing versions. Other ciphers can be chosen
using the `-A_` option.
A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`.
The header which contains some metadata like the virtual MAC address of the edge nodes, their IP address
and the community name optionally can be encrypted applying `-H` on the edges.
## Routing the Traffic
Reaching a remote network or tunneling all the internet traffic via n2n are two common tasks which require a proper routing setup. n2n supports routing needs providing options for packet forwarding (`-r`) including broadcasts (`-E`) as well as temporarily modifying the routing table (`n`). Details can be found in the [Routing.md](doc/Routing.md) document.
## IPv6 Support ## IPv6 Support
N2N can tunnel IPv6 traffic into the virtual network but does not support n2n can tunnel IPv6 traffic into the virtual network but does not support
IPv6 for edge-to-supernode communication yet. IPv6 for edge-to-supernode communication yet.
Check out [IPv6.md](https://github.com/ntop/n2n/blob/dev/doc/IPv6.md) for more information. Check out [IPv6.md](https://github.com/ntop/n2n/blob/dev/doc/IPv6.md) for more information.
## Security considerations
n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions.
Different encryption schemes are applied to the packet payload and to the header which
contains some metadata like the virtual MAC address of the edge nodes, their IP address and the community
name.
When encryption is enabled, the supernode will not be able to decrypt the traffic exchanged between
two edge nodes, but it will know that edge A is talking with edge B.
Recently AES encryption support has been implemented, which increases both security and performance,
so it is recommended to enable it on all the edge nodes that must have the -Ax value. When possible
(i.e. when n2n is compiled with OpenSSL 1.1) we recommend to use `-A3`.
A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`.
Use `-H` on the edges to enable header encryption. Note, that header encryption is a per-community
decision, i.e. _all_ edges of one community need to have it either enabled or disabled. The supernode
can handle encrypted and unencrypted headers. As the key for header encryption is derived from the
community names, it requires the supernode to be used with fixed communities `-c <path>`
parameter. Also, reuse of once-publically-used community names for header encryption is not recomended.
## Contribution ## Contribution

2
doc/CRYPTO.md
View File

@ -125,7 +125,7 @@ In case of a PACKET-type, it is succeeded by the fields depicted below:
``` ```
### Encryption ### Encryption
If enabled (`-H`), all fields but the payload (which is handled seperately as outlined above) get encrypted using SPECK in CTR mode. As packet headers need to be decryptable by the supernode and we do not want to add another key (to keep it a simple interface), the community name serves as key (keep it secret!) because it is already known to the supernode. If enabled (`-H`), all fields but the payload (which is handled seperately as outlined above) get encrypted using SPECK in CTR mode. As packet headers need to be decryptable by the supernode and we do not want to add another key (to keep it a simple interface), the community name serves as key (keep it secret!) because it is already known to the supernode. The community name consists of up to 16 characters (well, 15 + `0x00`), so key size of 128 bit is a reasonable choice here.
The scheme applied tries to maintain compatibility with current packet format and works as follows: The scheme applied tries to maintain compatibility with current packet format and works as follows:

37
doc/Routing.md
View File

@ -1,6 +1,29 @@
# IPv4 Routing (Linux) # IPv4 Routing (Linux)
## Assumptions ## General Remarks
Reaching a remote network or tunneling all the internet traffic via n2n are two common tasks which require a proper routing setup. n2n supports routing needs providing options for packet forwarding including broadcasts as well as modifying the routing table.
In this context, the `server` is the edge node which provides access to the remote network/internet, whereas the `client` is the connecting edge node.
In order to enable routing, the `server` must be configured as follows:
1. Add the `-r` option to the edge options to enable routing
2. Enable packet forwarding with `sudo sysctl -w net.ipv4.ip_forward=1`
3. Enable IP masquerading: `sudo iptables -t nat -A POSTROUTING -j MASQUERADE`
On the client side, the easiest way to configure routing is via the `-n` option. For example:
- In order to connect to the remote network `192.168.100.0/24`, use `-n 192.168.100.0/24:10.0.0.1`
- In order to tunnel all the internet traffic, use `-n 0.0.0.0/0:10.0.0.1`
10.0.0.1 is the IP address of the gateway to use to route the specified network. It should correspond to the IP address of the `server` within n2n. Multiple `-n` options can be specified.
As an alternative to the `-n` option, the `ip route` linux command can be manually used. See the [n2n_gateway.sh](doc/n2n_gateway.sh) script for an example. See also the follwing description of other use cases and in depth explanation.
## Special Scenarios
### Assumptions
- There are two Local Area Networks, namely 10.11.12.0/24 (maybe at - There are two Local Area Networks, namely 10.11.12.0/24 (maybe at
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice). **h**ome) and 192.168.1.0/24 (maybe in **o**ffice).
@ -14,7 +37,7 @@
10.99.99.0/24 network. 10.99.99.0/24 network.
- The _iptables_ are flushed. - The _iptables_ are flushed.
## Prerequisites ### Prerequisites
- Both, **h**ickory and **o**scar have ip forwarding enabled: `echo 1 > /proc/sys/net/ipv4/ip_forward` or `sysctl -w net.ipv4.ip_forward=1`. To - Both, **h**ickory and **o**scar have ip forwarding enabled: `echo 1 > /proc/sys/net/ipv4/ip_forward` or `sysctl -w net.ipv4.ip_forward=1`. To
make this setting persistent over reboot, a file containing the line make this setting persistent over reboot, a file containing the line
@ -25,7 +48,7 @@
interfaces usually already allow packet forwarding and thus do not need interfaces usually already allow packet forwarding and thus do not need
any further configuration. any further configuration.
## Reach Complete Office Network from n2n Node at Home ### Reach Complete Office Network from n2n Node at Home
- To make **h**ickory send all packets with office destination via - To make **h**ickory send all packets with office destination via
**o**scar, **h**ickory needs to be made aware of where to route this **o**scar, **h**ickory needs to be made aware of where to route this
@ -75,14 +98,14 @@ sent to **h**ickory, one more step is required:
`iptables -P FORWARD ACCEPT` `iptables -P FORWARD ACCEPT`
`iptables -P OUTPUT ACCEPT` `iptables -P OUTPUT ACCEPT`
## Reach n2n Node in Office from Whole Home Network ### Reach n2n Node in Office from Whole Home Network
This is easy: This is easy:
- Just exchange home and office IP addresses and the computer names in - Just exchange home and office IP addresses and the computer names in
the instructions given above. the instructions given above.
## Reach Whole Home Network from Whole Office Network ### Reach Whole Home Network from Whole Office Network
This is not too complicated either. Basically, follow the given example This is not too complicated either. Basically, follow the given example
above and apply the following changes: above and apply the following changes:
@ -102,7 +125,7 @@ above and apply the following changes:
either to the router (best option) or all those computers that shall be either to the router (best option) or all those computers that shall be
able to connect to the other network. able to connect to the other network.
## Route All Internet Traffic from n2n Node at Home through Office Network ### Route All Internet Traffic from n2n Node at Home through Office Network
This scenario could be considered a n2n-tunneled VPN connection which This scenario could be considered a n2n-tunneled VPN connection which
also would work for travelling users on their laptop. All external also would work for travelling users on their laptop. All external
@ -142,6 +165,8 @@ accordingly, maybe to Google's 8.8.8.8.
If [DNS leaks](https://en.wikipedia.org/wiki/DNS_leak) do not matter, If [DNS leaks](https://en.wikipedia.org/wiki/DNS_leak) do not matter,
this setup is complete. this setup is complete.
### Preventing DNS Leaks
Otherwise, there is more to it: Without changes, all future DNS queries Otherwise, there is more to it: Without changes, all future DNS queries
go through the home router 10.11.12.1 to the ISP's servers or directly go through the home router 10.11.12.1 to the ISP's servers or directly
to Google (via the home router 10.11.12.1 along the configured route for to Google (via the home router 10.11.12.1 along the configured route for