diff --git a/README.md b/README.md index 378c1ab..f1be7b0 100644 --- a/README.md +++ b/README.md @@ -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. - _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. -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 @@ -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. -**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`). @@ -45,24 +45,9 @@ 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. -## Routing the traffic +## 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. +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. Details can be found in the [ROUTING.md](doc/Routing.md) document. ## Manual Compilation @@ -77,14 +62,12 @@ make make install ``` -Parts of the code – especially Speck cipher and the header encryption – speedwise benefit -from compiler optimizations and platform features such as NEON, SSE and AVX. To enable, -use `./configure CFLAGS="-O3 -march=native"` for configuration instead. +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. For Windows, check out [Windows.md](doc/Windows.md) for compilation and run instuctions. 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: @@ -97,33 +80,25 @@ starting it with `sudo systemctl start edge@instance1`. ## 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. Check out [IPv6.md](https://github.com/ntop/n2n/blob/dev/doc/IPv6.md) for more information. -## Security considerations +## Security Considerations -n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions. +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. -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`. +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`. -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 ` -parameter. Also, reuse of once-publically-used community names for header encryption is not recomended. +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. ## Contribution