mirror of
https://github.com/ntop/n2n.git
synced 2024-09-19 16:41:11 +02:00
Standardize documentation (#211)
* Use Markdown for Android build docs, fix typos * Format and correct syntax errors/irregularities in existing Markdown documents * Convert `txt`-based docs to Markdown, update macOS instructions * Use GitHub conventions for README, fix typos, add link to `gon2n` * Fix case sensitivity issues
This commit is contained in:
parent
317a425904
commit
8d64ed3ff8
69
README.md
69
README.md
|
@ -1,21 +1,19 @@
|
||||||
# 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 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.
|
## Quick Setup
|
||||||
|
|
||||||
Quick Setup
|
Some Linux distributions already provide n2n as a package so a simple `sudo apt install n2n` will do the work. Alternatively, up to date packages for most distributions are available on [ntop repositories](http://packages.ntop.org/).
|
||||||
-----------
|
|
||||||
|
|
||||||
Some linux distributions already provide n2n as a package so a simple `sudo apt-get install n2n` will do the work. Alternatively, up to date packages for most distributions are available on [ntop repositories](http://packages.ntop.org/).
|
|
||||||
|
|
||||||
On host1 run:
|
On host1 run:
|
||||||
|
|
||||||
|
@ -31,25 +29,23 @@ $ 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 PC. 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`).
|
||||||
|
|
||||||
1. Install the n2n package
|
1. Install the n2n package
|
||||||
2. Edit `/etc/n2n/supernode.conf` and add the following:
|
2. Edit `/etc/n2n/supernode.conf` and add the following:
|
||||||
```
|
```
|
||||||
-l=1234
|
-l=1234
|
||||||
```
|
```
|
||||||
3. Start the supernode service with `sudo systemctl start supernode`
|
3. Start the supernode service with `sudo systemctl start supernode`
|
||||||
4. Optionally enable supernode start on boot: `sudo systemctl enable supernode`
|
4. Optionally enable supernode start on boot: `sudo systemctl enable 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.
|
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
|
||||||
-------------------
|
|
||||||
|
|
||||||
On linux, n2n provides a standard TAP interface, so routing works gracefully via the standard system utilities as follows.
|
On linux, n2n provides a standard TAP interface, so routing works gracefully via the standard system utilities as follows.
|
||||||
|
|
||||||
|
@ -77,12 +73,11 @@ $ sudo ip route del default
|
||||||
$ sudo ip route add default via 192.168.100.1
|
$ sudo ip route add default via 192.168.100.1
|
||||||
```
|
```
|
||||||
|
|
||||||
This process can be greatly simplified by using the [n2n_gateway.sh](https://github.com/ntop/n2n/blob/dev/doc/n2n_gateway.sh) script.
|
This process can be greatly simplified by using the [n2n_gateway.sh](doc/n2n_gateway.sh) script.
|
||||||
|
|
||||||
See [Routing.md](https://github.com/ntop/n2n/blob/dev/doc/Routing.md) for other use cases and in depth explanation.
|
See [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:
|
||||||
|
|
||||||
|
@ -96,11 +91,9 @@ make install
|
||||||
```
|
```
|
||||||
|
|
||||||
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 [n2n_on_MacOS.txt](https://github.com/ntop/n2n/blob/dev/doc/n2n_on_MacOS.txt).
|
## 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:
|
||||||
|
|
||||||
|
@ -111,16 +104,14 @@ 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`.
|
||||||
|
|
||||||
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
|
## Security considerations
|
||||||
-----------------------
|
|
||||||
|
|
||||||
n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions.
|
n2n edge nodes use twofish encryption by default for compatibility reasons with existing versions.
|
||||||
|
|
||||||
|
@ -135,8 +126,7 @@ so it is recommended to enable it on all the edge nodes by specifying the `-A` o
|
||||||
|
|
||||||
A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`.
|
A benchmark of the encryption methods is available when compiled from source with `tools/n2n-benchmark`.
|
||||||
|
|
||||||
Contribution
|
## Contribution
|
||||||
------------
|
|
||||||
|
|
||||||
You can contribute to n2n in various ways:
|
You can contribute to n2n in various ways:
|
||||||
|
|
||||||
|
@ -147,14 +137,15 @@ You can contribute to n2n in various ways:
|
||||||
|
|
||||||
For details about the internals of n2n check out [Hacking guide](https://github.com/ntop/n2n/blob/dev/doc/HACKING).
|
For details about the internals of n2n check out [Hacking guide](https://github.com/ntop/n2n/blob/dev/doc/HACKING).
|
||||||
|
|
||||||
Related Projects
|
## Related Projects
|
||||||
----------------
|
|
||||||
|
|
||||||
Here is a list of third-party projects connected to this repository.
|
Here is a list of third-party projects connected to this repository.
|
||||||
|
|
||||||
- N2n for android: [hin2n](https://github.com/switch-iot/hin2n)
|
- N2N for Android: [hin2n](https://github.com/switch-iot/hin2n)
|
||||||
- N2n v1 and v2 version from meyerd: [meyerd n2n](https://github.com/meyerd/n2n)
|
- N2N v1 and v2 version from meyerd: [meyerd n2n](https://github.com/meyerd/n2n)
|
||||||
- Docker images: [DockerHub](https://hub.docker.com/r/supermock/supernode/) - [DockerStore](https://store.docker.com/community/images/supermock/supernode/)
|
- Docker images: [Docker Hub](https://hub.docker.com/r/supermock/supernode/)
|
||||||
|
- Go bindings, management daemons and CLIs for n2n edges and supernodes, Docker, Kubernetes & Helm Charts: [pojntfx/gon2n](https://pojntfx.github.io/gon2n/)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
-----------------
|
|
||||||
(C) 2007-2019 - ntop.org and contributors
|
(C) 2007-2019 - ntop.org and contributors
|
||||||
|
|
|
@ -1,29 +0,0 @@
|
||||||
- Install jdk.
|
|
||||||
- Generate app keystore by commond keytool -genkey -alias Hin2n -keystore Hin2n.jks. And remember these two passwords:
|
|
||||||
|
|
||||||
keytool -genkey -dname "CN=Unknown,O=Unknown,C=Unknown" -keystore Hin2n.jks -keysize 1024 -alias Hin2nalias -validity 14000 -keypass yourpassword -storepass yourpassword
|
|
||||||
|
|
||||||
- Move Hin2n.jks to android/Hin2n/app directory. We will use this file to sign the application
|
|
||||||
- In the file app/build.gradle replace "yourpassword" with the password used to generate the keystore.
|
|
||||||
|
|
||||||
|
|
||||||
- Download android tools from https://developer.android.com/, and unzip it.
|
|
||||||
|
|
||||||
- Install android development environment.
|
|
||||||
echo y | ./tools/bin/sdkmanager tools
|
|
||||||
echo y | ./tools/bin/sdkmanager platform-tools
|
|
||||||
echo y | ./tools/bin/sdkmanager ndk-bundle
|
|
||||||
echo y | ./tools/bin/sdkmanager "cmake;3.6.4111459"
|
|
||||||
echo y | ./tools/bin/sdkmanager "lldb;3.1"
|
|
||||||
|
|
||||||
- Set environment variables.
|
|
||||||
export ANDROID_HOME=YOUE_ANDROID_DEV_HOME
|
|
||||||
export ANDROID_NDK_HOME=$ANDROID_HOME/ndk-bundle
|
|
||||||
export HIN2N_KSTOREPWD=YOUR_APP_KEYSTORE_PASSWORD
|
|
||||||
export HIN2N_KEYPWD=YOUR_APP_KEY_PASSWORD
|
|
||||||
|
|
||||||
- Compile the app.
|
|
||||||
cd android/Hin2n
|
|
||||||
./gradlew assemble
|
|
||||||
|
|
||||||
- You will get the app in android/Hin2n/app/build/outputs/apk/ directory.
|
|
33
android/README.md
Normal file
33
android/README.md
Normal file
|
@ -0,0 +1,33 @@
|
||||||
|
# Building n2n on Android
|
||||||
|
|
||||||
|
- Install jdk.
|
||||||
|
- Generate app keystore by the command `keytool -genkey -alias Hin2n -keystore Hin2n.jks`. And remember these two passwords:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
keytool -genkey -dname "CN=Unknown,O=Unknown,C=Unknown" -keystore Hin2n.jks -keysize 1024 -alias Hin2nalias -validity 14000 -keypass yourpassword -storepass yourpassword
|
||||||
|
```
|
||||||
|
|
||||||
|
- Move `Hin2n.jks` to `android/Hin2n/app` directory. We will use this file to sign the application.
|
||||||
|
- In the file `app/build.gradle` replace `yourpassword` with the password used to generate the keystore.
|
||||||
|
- Download Android tools from https://developer.android.com/, and unzip it.
|
||||||
|
- Install Android development environment.
|
||||||
|
```bash
|
||||||
|
echo y | ./tools/bin/sdkmanager tools
|
||||||
|
echo y | ./tools/bin/sdkmanager platform-tools
|
||||||
|
echo y | ./tools/bin/sdkmanager ndk-bundle
|
||||||
|
echo y | ./tools/bin/sdkmanager "cmake;3.6.4111459"
|
||||||
|
echo y | ./tools/bin/sdkmanager "lldb;3.1"
|
||||||
|
```
|
||||||
|
- Set environment variables.
|
||||||
|
```bash
|
||||||
|
export ANDROID_HOME=YOUE_ANDROID_DEV_HOME
|
||||||
|
export ANDROID_NDK_HOME=\$ANDROID_HOME/ndk-bundle
|
||||||
|
export HIN2N_KSTOREPWD=YOUR_APP_KEYSTORE_PASSWORD
|
||||||
|
export HIN2N_KEYPWD=YOUR_APP_KEY_PASSWORD
|
||||||
|
```
|
||||||
|
- Compile the app.
|
||||||
|
```bash
|
||||||
|
cd android/Hin2n
|
||||||
|
./gradlew assemble
|
||||||
|
```
|
||||||
|
- You will get the app in `android/Hin2n/app/build/outputs/apk/` directory.
|
|
@ -1,3 +1,5 @@
|
||||||
|
# IPv6
|
||||||
|
|
||||||
n2n supports the carriage of IPv6 packets within the n2n tunnel. N2n does not
|
n2n supports the carriage of IPv6 packets within the n2n tunnel. N2n does not
|
||||||
yet use IPv6 for transport between edges and supernodes.
|
yet use IPv6 for transport between edges and supernodes.
|
||||||
|
|
||||||
|
@ -5,7 +7,7 @@ To make IPv6 carriage work you need to manually add IPv6 addresses to the TAP
|
||||||
interfaces at each end. There is currently no way to specify an IPv6 address on
|
interfaces at each end. There is currently no way to specify an IPv6 address on
|
||||||
the edge command line.
|
the edge command line.
|
||||||
|
|
||||||
eg. under linux:
|
Eg. under linux:
|
||||||
|
|
||||||
on hostA:
|
on hostA:
|
||||||
`[hostA] $ /sbin/ip -6 addr add fc00:abcd:1234::7/48 dev n2n0`
|
`[hostA] $ /sbin/ip -6 addr add fc00:abcd:1234::7/48 dev n2n0`
|
||||||
|
|
11
doc/MTU.md
11
doc/MTU.md
|
@ -1,5 +1,4 @@
|
||||||
MTU
|
# MTU
|
||||||
---
|
|
||||||
|
|
||||||
The MTU of the VPN interface is set to a lower value (rather than the standard
|
The MTU of the VPN interface is set to a lower value (rather than the standard
|
||||||
1500 B value) to avoid excessive fragmentation on the datagram sent on internet.
|
1500 B value) to avoid excessive fragmentation on the datagram sent on internet.
|
||||||
|
@ -27,8 +26,7 @@ MTU of the path between two hosts. Knowing the PMTU is also useful for a sender
|
||||||
avoid fragmentation at the IP level. Trying to find the biggest MTU is useful since it allows to
|
avoid fragmentation at the IP level. Trying to find the biggest MTU is useful since it allows to
|
||||||
maximize bandwidth.
|
maximize bandwidth.
|
||||||
|
|
||||||
PMTU Discovery Failures
|
## PMTU Discovery Failures
|
||||||
-----------------------
|
|
||||||
|
|
||||||
Most operating systems try to periodically discover the PMTU by using a PMTU discovery algorithm.
|
Most operating systems try to periodically discover the PMTU by using a PMTU discovery algorithm.
|
||||||
This involves setting the DF (don't fragment) flag on the IP packets. When a large IP packet exceeds
|
This involves setting the DF (don't fragment) flag on the IP packets. When a large IP packet exceeds
|
||||||
|
@ -40,18 +38,15 @@ The main problem when this situation occurs is that the actual PMTU is unknown,
|
||||||
solution is not applicable. The user must manually specify a lower MTU for the VPN interface
|
solution is not applicable. The user must manually specify a lower MTU for the VPN interface
|
||||||
in order to solve the issue.
|
in order to solve the issue.
|
||||||
|
|
||||||
n2n and MTU
|
## n2n and MTU
|
||||||
-----------
|
|
||||||
|
|
||||||
n2n should work by default in different environments. For this reason, the following solution
|
n2n should work by default in different environments. For this reason, the following solution
|
||||||
has been provided:
|
has been provided:
|
||||||
|
|
||||||
- PMTU discovery is disabled when possible (via the IP_MTU_DISCOVER socket option). This avoid
|
- PMTU discovery is disabled when possible (via the IP_MTU_DISCOVER socket option). This avoid
|
||||||
silently dropping a oversize packet due to the DF flag, however it possibly increments fragmentation on the path.
|
silently dropping a oversize packet due to the DF flag, however it possibly increments fragmentation on the path.
|
||||||
|
|
||||||
- As examplained above, a lower MTU is set on the VPN interface, thus removing excessive fragmentation on
|
- As examplained above, a lower MTU is set on the VPN interface, thus removing excessive fragmentation on
|
||||||
the sender.
|
the sender.
|
||||||
|
|
||||||
- 1400 B is used instead of 1500 B as the reference value for the internet interface MTU.
|
- 1400 B is used instead of 1500 B as the reference value for the internet interface MTU.
|
||||||
This essentially avoids fragmentation when the PMTU is >= 1400 B.
|
This essentially avoids fragmentation when the PMTU is >= 1400 B.
|
||||||
|
|
||||||
|
|
|
@ -1,5 +0,0 @@
|
||||||
|
|
||||||
Between 2.0.x and 2.1.x
|
|
||||||
|
|
||||||
* Better ming Windows build support.
|
|
||||||
* Added -E flag to allow multicast ethernet traffic.
|
|
271
doc/Routing.md
271
doc/Routing.md
|
@ -1,166 +1,163 @@
|
||||||
# IP v4 Routing (Linux)
|
# IPv4 Routing (Linux)
|
||||||
|
|
||||||
## Assumptions
|
## Assumptions
|
||||||
- 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).
|
- There are two Local Area Networks, namely 10.11.12.0/24 (maybe at
|
||||||
- These networks are connected to the internet via routers 10.11.12.1
|
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice).
|
||||||
and 192.168.1.1, respectively.
|
- These networks are connected to the internet via routers 10.11.12.1
|
||||||
- In each network, there is a computer running a successfully setup n2n
|
and 192.168.1.1, respectively.
|
||||||
node: 10.11.12.5 (**h**ickory) and 192.168.1.6 (**o**scar). They are
|
- In each network, there is a computer running a successfully setup n2n
|
||||||
connected to their networks through a device called _eth0_. Their n2n
|
node: 10.11.12.5 (**h**ickory) and 192.168.1.6 (**o**scar). They are
|
||||||
devices shall be called _n2n0_, and their n2n IP addresses are
|
connected to their networks through a device called _eth0_. Their n2n
|
||||||
10.99.99.50 (**h**ickory) and 10.99.99.60 (**o**scar) in the
|
devices shall be called _n2n0_, and their n2n IP addresses are
|
||||||
10.99.99.0/24 network.
|
10.99.99.50 (**h**ickory) and 10.99.99.60 (**o**scar) in the
|
||||||
|
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
|
|
||||||
make this setting persistent over reboot, a file containing the line
|
|
||||||
`net.ipv4.ip_forward=1` could be added in /etc/sysctl.d/ – your distro
|
|
||||||
may vary.
|
|
||||||
- To allow n2n to forward packets, both edge nodes need to be started
|
|
||||||
with `-r` option on their command line. All other regular network
|
|
||||||
interfaces usually already allow packet forwarding and thus do not need
|
|
||||||
any further configuration.
|
|
||||||
|
|
||||||
## Reach Complete Office Network from n2n Node at Home
|
- 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
|
||||||
|
`net.ipv4.ip_forward=1` could be added in /etc/sysctl.d/ – your distro
|
||||||
|
may vary.
|
||||||
|
- To allow n2n to forward packets, both edge nodes need to be started
|
||||||
|
with `-r` option on their command line. All other regular network
|
||||||
|
interfaces usually already allow packet forwarding and thus do not need
|
||||||
|
any further configuration.
|
||||||
|
|
||||||
- To make **h**ickory send all packets with office destination via
|
## Reach Complete Office Network from n2n Node at Home
|
||||||
**o**scar, **h**ickory needs to be made aware of where to route this
|
|
||||||
packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60
|
|
||||||
dev n2n0 src 10.11.12.5`.
|
|
||||||
- **o**scar needs to know where to send packets to, too. So, on
|
|
||||||
**o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src
|
|
||||||
192.168.1.6`.
|
|
||||||
|
|
||||||
**o**scar and **h**ickory should now be able to exchange packets by
|
- To make **h**ickory send all packets with office destination via
|
||||||
using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6.
|
**o**scar, **h**ickory needs to be made aware of where to route this
|
||||||
To make the complete office network aware of how packets or answers are
|
packets to. On **h**ickory: `ip route add 192.168.1.0/24 via 10.99.99.60 dev n2n0 src 10.11.12.5`.
|
||||||
sent to **h**ickory, one more step is required:
|
- **o**scar needs to know where to send packets to, too. So, on
|
||||||
|
**o**scar: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
|
||||||
|
|
||||||
- Packets from any office computer to **h**ickory need to be directed to
|
**o**scar and **h**ickory should now be able to exchange packets by
|
||||||
**o**scar that – thanks to enabled IP forwarding and the routing rule –
|
using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6.
|
||||||
already knows how to handle this kind of packets.
|
To make the complete office network aware of how packets or answers are
|
||||||
* To handle it in a one-stop-shop, the office router 192.168.1.1 can
|
sent to **h**ickory, one more step is required:
|
||||||
be configured to direct those packets to **o**scar. Luckily, even most
|
|
||||||
modern small-office-and-home routers allow to add static routing rules
|
|
||||||
via a web interface. A rule like "All packets for host 10.11.12.5 (or
|
|
||||||
network 10.11.12.0/24) need to be sent to another router, namely
|
|
||||||
192.168.1.5" will do. This is the **recommended** solution.
|
|
||||||
* However, a **less recommended** but working option would be to add
|
|
||||||
static routes to each single of those computers in the office network
|
|
||||||
that shall be able to connect to or be accessed by **h**ickory. On
|
|
||||||
those, e.g. **o**livia with IP address 192.168.1.123: `ip route add
|
|
||||||
10.11.12.5 via 192.168.1.5 dev eth0 src 192.168.1.123`.
|
|
||||||
* Alternatively, in case the office router does not allow to have
|
|
||||||
added own static routing rules, **o**scar needs to perform NAT for all
|
|
||||||
connections initiated from **h**ickory:
|
|
||||||
`iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`
|
|
||||||
`iptables -A FORWARD -i eth0 -o n2n0 -m state --state
|
|
||||||
RELATED,ESTABLISHED -j ACCEPT`
|
|
||||||
`iptables -A FORWARD -i n2n0 -o eth0 -j ACCEPT`
|
|
||||||
There is a major drawback with this solution which thus is the **least
|
|
||||||
recommended**: Connections between **h**ickory and the office network
|
|
||||||
will only work if initiated by **h**ickory – not the other way 'round.
|
|
||||||
By the way, in case _iptables_ are messed up, they can be flushed by:
|
|
||||||
`iptables -F`
|
|
||||||
`iptables -X`
|
|
||||||
`iptables -t nat -F`
|
|
||||||
`iptables -t nat -X`
|
|
||||||
`iptables -t mangle -F`
|
|
||||||
`iptables -t mangle -X`
|
|
||||||
`iptables -t raw -F`
|
|
||||||
`iptables -t raw -X`
|
|
||||||
`iptables -t security -F`
|
|
||||||
`iptables -t security -X`
|
|
||||||
`iptables -P INPUT ACCEPT`
|
|
||||||
`iptables -P FORWARD ACCEPT`
|
|
||||||
`iptables -P OUTPUT ACCEPT`
|
|
||||||
|
|
||||||
## Reach n2n Node in Office from Whole Home Network
|
- Packets from any office computer to **h**ickory need to be directed to
|
||||||
|
**o**scar that – thanks to enabled IP forwarding and the routing rule –
|
||||||
|
already knows how to handle this kind of packets.
|
||||||
|
- To handle it in a one-stop-shop, the office router 192.168.1.1 can
|
||||||
|
be configured to direct those packets to **o**scar. Luckily, even most
|
||||||
|
modern small-office-and-home routers allow to add static routing rules
|
||||||
|
via a web interface. A rule like "All packets for host 10.11.12.5 (or
|
||||||
|
network 10.11.12.0/24) need to be sent to another router, namely
|
||||||
|
192.168.1.5" will do. This is the **recommended** solution.
|
||||||
|
- However, a **less recommended** but working option would be to add
|
||||||
|
static routes to each single of those computers in the office network
|
||||||
|
that shall be able to connect to or be accessed by **h**ickory. On
|
||||||
|
those, e.g. **o**livia with IP address 192.168.1.123: `ip route add 10.11.12.5 via 192.168.1.5 dev eth0 src 192.168.1.123`.
|
||||||
|
- Alternatively, in case the office router does not allow to have
|
||||||
|
added own static routing rules, **o**scar needs to perform NAT for all
|
||||||
|
connections initiated from **h**ickory:
|
||||||
|
`iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE`
|
||||||
|
`iptables -A FORWARD -i eth0 -o n2n0 -m state --state RELATED,ESTABLISHED -j ACCEPT`
|
||||||
|
`iptables -A FORWARD -i n2n0 -o eth0 -j ACCEPT`
|
||||||
|
There is a major drawback with this solution which thus is the **least
|
||||||
|
recommended**: Connections between **h**ickory and the office network
|
||||||
|
will only work if initiated by **h**ickory – not the other way 'round.
|
||||||
|
By the way, in case _iptables_ are messed up, they can be flushed by:
|
||||||
|
`iptables -F`
|
||||||
|
`iptables -X`
|
||||||
|
`iptables -t nat -F`
|
||||||
|
`iptables -t nat -X`
|
||||||
|
`iptables -t mangle -F`
|
||||||
|
`iptables -t mangle -X`
|
||||||
|
`iptables -t raw -F`
|
||||||
|
`iptables -t raw -X`
|
||||||
|
`iptables -t security -F`
|
||||||
|
`iptables -t security -X`
|
||||||
|
`iptables -P INPUT ACCEPT`
|
||||||
|
`iptables -P FORWARD ACCEPT`
|
||||||
|
`iptables -P OUTPUT ACCEPT`
|
||||||
|
|
||||||
|
## 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
|
|
||||||
the instructions given above.
|
- Just exchange home and office IP addresses and the computer names in
|
||||||
|
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:
|
||||||
- The instructions used above need to be expanded from **h**ickory's IP
|
|
||||||
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on
|
- The instructions used above need to be expanded from **h**ickory's IP
|
||||||
**o**scar:, especially: `ip route add 10.11.12.0/24 via 10.99.99.50 dev
|
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on
|
||||||
n2n0 src 192.168.1.6`.
|
**o**scar:, especially: `ip route add 10.11.12.0/24 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
|
||||||
- In case of adding a static route to the office network router
|
- In case of adding a static route to the office network router
|
||||||
192.168.1.1, the home network 10.11.12.0/24 must be specified instead of
|
192.168.1.1, the home network 10.11.12.0/24 must be specified instead of
|
||||||
**h**ickory's more specific IP address 11.11.12.5. Same for the less
|
**h**ickory's more specific IP address 11.11.12.5. Same for the less
|
||||||
recommended static routes on other office computers.
|
recommended static routes on other office computers.
|
||||||
- Packets from home network's computers to the office network need to be
|
- Packets from home network's computers to the office network need to be
|
||||||
sent through the n2n tunnel. The three alternatives given above can be
|
sent through the n2n tunnel. The three alternatives given above can be
|
||||||
used just with exchanged office and home IP addresses. One needs to be
|
used just with exchanged office and home IP addresses. One needs to be
|
||||||
aware that NAT only (third alternative) on both sides will not allow any
|
aware that NAT only (third alternative) on both sides will not allow any
|
||||||
connection, i.e. at least on one side static routes need to be added
|
connection, i.e. at least on one side static routes need to be added
|
||||||
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
|
||||||
internet traffic will appear to originate from **o**scar and the office
|
internet traffic will appear to originate from **o**scar and the office
|
||||||
network.
|
network.
|
||||||
|
|
||||||
- First, one of the setups described above needs to be in place, with
|
- First, one of the setups described above needs to be in place, with
|
||||||
the following change:
|
the following change:
|
||||||
- NAT on **o**scar (see the three _iptables_ commands above) must be
|
- NAT on **o**scar (see the three _iptables_ commands above) must be
|
||||||
enabled. It will not work without because the office router 192.168.1.1
|
enabled. It will not work without because the office router 192.168.1.1
|
||||||
usually denies forwarding to packets not originating from its own
|
usually denies forwarding to packets not originating from its own
|
||||||
network. It could be in addition to the eventually installed static
|
network. It could be in addition to the eventually installed static
|
||||||
routes for 10.11.12.0/24 in the router 192.168.1.1 or on other office
|
routes for 10.11.12.0/24 in the router 192.168.1.1 or on other office
|
||||||
computers – it will not interfere. However, **o**scar definitely needs
|
computers – it will not interfere. However, **o**scar definitely needs
|
||||||
the route given above: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0
|
the route given above: `ip route add 10.11.12.5 via 10.99.99.50 dev n2n0 src 192.168.1.6`.
|
||||||
src 192.168.1.6`.
|
- To have **h**ickory's complete internet traffic going through the n2n
|
||||||
- To have **h**ickory's complete internet traffic going through the n2n
|
tunnel, its default route needs to be changed:
|
||||||
tunnel, its default route needs to be changed:
|
`ip route del default`
|
||||||
`ip route del default`
|
`ip route add default via 10.99.99.60 dev n2n0 src 10.11.12.5`
|
||||||
`ip route add default via 10.99.99.60 dev n2n0 src 10.11.12.5`
|
|
||||||
|
|
||||||
- **h**ickory's home network should still be reachable as usually,
|
- **h**ickory's home network should still be reachable as usually,
|
||||||
_eth0_ and the associated network 10.11.12.0/24 get their very own
|
_eth0_ and the associated network 10.11.12.0/24 get their very own
|
||||||
route. If not, i.e. it was only covered by default route before, it
|
route. If not, i.e. it was only covered by default route before, it
|
||||||
needs to be added: `ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5`.
|
needs to be added: `ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5`.
|
||||||
- Unfortunately (unless the supernode is on **h**ickory's local
|
- Unfortunately (unless the supernode is on **h**ickory's local
|
||||||
network), n2n supernode becomes unreachable for **h**ickory. To fix it:
|
network), n2n supernode becomes unreachable for **h**ickory. To fix it:
|
||||||
`ip route add <supernode IP address> via 10.11.12.1 dev eth0 src
|
`ip route add <supernode IP address> via 10.11.12.1 dev eth0 src 10.11.12.5`
|
||||||
10.11.12.5`
|
|
||||||
|
|
||||||
The supernode's IP address needs to be known to have this work. However,
|
The supernode's IP address needs to be known to have this work. However,
|
||||||
if the supernode's IP needs to be resolved from some domain name (FQDN),
|
if the supernode's IP needs to be resolved from some domain name (FQDN),
|
||||||
e.g. in case of using dynamic domain name services, a DNS server needs
|
e.g. in case of using dynamic domain name services, a DNS server needs
|
||||||
to remain reachable, too. Either the reachable home network router
|
to remain reachable, too. Either the reachable home network router
|
||||||
10.11.12.1 is good enough for that (if it offers DNS) or another route
|
10.11.12.1 is good enough for that (if it offers DNS) or another route
|
||||||
could to be added and **h**ickory's DNS settings might be set
|
could to be added and **h**ickory's DNS settings might be set
|
||||||
accordingly, maybe to Google's 8.8.8.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.
|
||||||
|
|
||||||
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
|
||||||
8.8.8.8 and not through the n2n tunnel) while the remaining traffic
|
8.8.8.8 and not through the n2n tunnel) while the remaining traffic
|
||||||
ships through the n2n tunnel.
|
ships through the n2n tunnel.
|
||||||
|
|
||||||
To prevent such a DNS leak, the supernode's IP address must be
|
To prevent such a DNS leak, the supernode's IP address must be
|
||||||
determined independently from **h**ickory's DNS configuration, e.g. by
|
determined independently from **h**ickory's DNS configuration, e.g. by
|
||||||
digesting `dig +short mysupernode.myfavoritednsservice.com @8.8.8.8`'s
|
digesting `dig +short mysupernode.myfavoritednsservice.com @8.8.8.8`'s
|
||||||
output in the n2n-edge's setup script for both, the edge node command
|
output in the n2n-edge's setup script for both, the edge node command
|
||||||
line as well as the static route mentioned above. Without further
|
line as well as the static route mentioned above. Without further
|
||||||
additional work, dynamic address changes remain undetected. A static
|
additional work, dynamic address changes remain undetected. A static
|
||||||
route to 8.8.8.8 is still required. **h**ickory's regular DNS
|
route to 8.8.8.8 is still required. **h**ickory's regular DNS
|
||||||
configuration should query a different DNS server for its regular DNS
|
configuration should query a different DNS server for its regular DNS
|
||||||
needs, e.g. 9.9.9.9 or 1.1.1.1 or maybe the office DNS server, maybe
|
needs, e.g. 9.9.9.9 or 1.1.1.1 or maybe the office DNS server, maybe
|
||||||
192.168.1.1. This guarantees the regular DNS queries also to get sent
|
192.168.1.1. This guarantees the regular DNS queries also to get sent
|
||||||
through the n2n tunnel.
|
through the n2n tunnel.
|
||||||
|
|
||||||
A test for DNS leaks can be found [here](https://www.dnsleaktest.com/).
|
A test for DNS leaks can be found [here](https://www.dnsleaktest.com/).
|
||||||
|
|
|
@ -1,35 +1,37 @@
|
||||||
# Requirements
|
# Build on Windows
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
In order to build on Windows the following tools should be installed:
|
In order to build on Windows the following tools should be installed:
|
||||||
|
|
||||||
- Visual Studio. For a minimal install, the command line only build tools can be
|
- Visual Studio. For a minimal install, the command line only build tools can be
|
||||||
downloaded and installed from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017
|
downloaded and installed from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017
|
||||||
|
- Cmake
|
||||||
|
- (optional) The OpenSSL library. Prebuild binaries can be downloaded from https://slproweb.com/products/Win32OpenSSL.html .
|
||||||
|
The full version is required (not the "Light" version). The Win32 version of it is usually required for a standard build.
|
||||||
|
|
||||||
- Cmake
|
NOTE: in order to skip OpenSSL compilation, edit CMakeLists.txt and replace
|
||||||
|
|
||||||
- (optional) The OpenSSL library. Prebuild binaries can be downloaded from https://slproweb.com/products/Win32OpenSSL.html .
|
```plaintext
|
||||||
The full version is required (not the "Light" version). The Win32 version of it is usually required for a standard build.
|
OPTION(N2N_OPTION_AES "USE AES" ON)
|
||||||
|
with
|
||||||
|
OPTION(N2N_OPTION_AES "USE AES" OFF)
|
||||||
|
```
|
||||||
|
|
||||||
NOTE: in order to skip OpenSSL compilation, edit CMakeLists.txt and replace
|
NOTE: to static link OpenSSL, add the `-DOPENSSL_USE_STATIC_LIBS=true` option to the cmake command
|
||||||
OPTION(N2N_OPTION_AES "USE AES" ON)
|
|
||||||
with
|
|
||||||
OPTION(N2N_OPTION_AES "USE AES" OFF)
|
|
||||||
|
|
||||||
NOTE: to static link OpenSSL, add the `-DOPENSSL_USE_STATIC_LIBS=true` option to the cmake command
|
|
||||||
|
|
||||||
In order to run n2n:
|
In order to run n2n:
|
||||||
|
|
||||||
- The TAP drivers should be installed into the system. They can be installed from
|
- The TAP drivers should be installed into the system. They can be installed from
|
||||||
http://build.openvpn.net/downloads/releases (search for "tap-windows")
|
http://build.openvpn.net/downloads/releases (search for "tap-windows")
|
||||||
|
- If OpenSSL has been linked dynamically, the corresponding .dll file should be available
|
||||||
|
into the target computer
|
||||||
|
|
||||||
- If OpenSSL has been linked dynamically, the corresponding .dll file should be available
|
## Build (CLI)
|
||||||
into the target computer
|
|
||||||
|
|
||||||
# Build (CLI)
|
|
||||||
|
|
||||||
In order to build from the command line, open a terminal window and run the following commands:
|
In order to build from the command line, open a terminal window and run the following commands:
|
||||||
|
|
||||||
```
|
```batch
|
||||||
md build
|
md build
|
||||||
cd build
|
cd build
|
||||||
cmake ..
|
cmake ..
|
||||||
|
@ -39,17 +41,17 @@ MSBuild supernode.vcxproj /t:Build /p:Configuration=Release
|
||||||
```
|
```
|
||||||
|
|
||||||
NOTE: if cmake has problems finding the installed OpenSSL library, try to download the official cmake and invoke it with:
|
NOTE: if cmake has problems finding the installed OpenSSL library, try to download the official cmake and invoke it with:
|
||||||
"C:\Program Files\CMake\bin\cmake"
|
`C:\Program Files\CMake\bin\cmake`
|
||||||
|
|
||||||
The compiled exe files should now be available under the Release directory.
|
The compiled exe files should now be available under the Release directory.
|
||||||
|
|
||||||
# Run
|
## Run
|
||||||
|
|
||||||
The `edge.exe` program reads the `edge.conf` file located into the current directory if no option is provided.
|
The `edge.exe` program reads the `edge.conf` file located into the current directory if no option is provided.
|
||||||
|
|
||||||
Here is an example `edge.conf` file:
|
Here is an example `edge.conf` file:
|
||||||
|
|
||||||
```
|
```plaintext
|
||||||
-c=mycommunity
|
-c=mycommunity
|
||||||
-k=mysecretkey
|
-k=mysecretkey
|
||||||
|
|
||||||
|
@ -64,7 +66,7 @@ The `supernode.exe` program reads the `supernode.conf` file located into the cur
|
||||||
|
|
||||||
Here is an example `supernode.conf` file:
|
Here is an example `supernode.conf` file:
|
||||||
|
|
||||||
```
|
```plaintext
|
||||||
-l=5678
|
-l=5678
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
12
doc/macOS.md
Normal file
12
doc/macOS.md
Normal file
|
@ -0,0 +1,12 @@
|
||||||
|
# n2n on macOS
|
||||||
|
|
||||||
|
In order to use n2n on macOS, you first need to install support for TUN/TAP interfaces:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
brew tap homebrew/cask
|
||||||
|
brew cask install tuntap
|
||||||
|
```
|
||||||
|
|
||||||
|
If you are on a modern version of macOS (i.e. Catalina), the commands above will ask you to enable the TUN/TAP kernel extension in System Preferences → Security & Privacy → General.
|
||||||
|
|
||||||
|
For more information refer to vendor documentation or the [Apple Technical Note](https://developer.apple.com/library/content/technotes/tn2459/_index.html).
|
|
@ -1,19 +0,0 @@
|
||||||
|
|
||||||
Using n2n on MacOS
|
|
||||||
------------------
|
|
||||||
|
|
||||||
In order to use n2n on MacOS you need to first install support for the tap interface.
|
|
||||||
if you are a brew (https://brew.sh) user you can do it in a couple of steps
|
|
||||||
|
|
||||||
- brew tap homebrew/cask
|
|
||||||
- brew cask install tuntap
|
|
||||||
|
|
||||||
Note that in the latest OS versions (for instance MacOS High Sierra), you may need to
|
|
||||||
need to enable their kernel extension in
|
|
||||||
|
|
||||||
System Preferences → Security & Privacy → General
|
|
||||||
|
|
||||||
For more information refer to vendor documentation or the Apple Technical Note:
|
|
||||||
|
|
||||||
https://developer.apple.com/library/content/technotes/tn2459/_index.html
|
|
||||||
|
|
4
doc/new-features.md
Normal file
4
doc/new-features.md
Normal file
|
@ -0,0 +1,4 @@
|
||||||
|
# New Features between 2.0.x and 2.1.x
|
||||||
|
|
||||||
|
- Better ming Windows build support.
|
||||||
|
- Added `-E` flag to allow multicast ethernet traffic.
|
|
@ -1,6 +1,6 @@
|
||||||
# Packaging
|
# RPM Packaging
|
||||||
|
|
||||||
```
|
```bash
|
||||||
./autogen.sh
|
./autogen.sh
|
||||||
./configure
|
./configure
|
||||||
make
|
make
|
|
@ -47,7 +47,7 @@ int tuntap_open(tuntap_dev *device /* ignored */,
|
||||||
|
|
||||||
if(device->fd < 0) {
|
if(device->fd < 0) {
|
||||||
traceEvent(TRACE_ERROR, "Unable to open any tap devices /dev/tap0 through /dev/tap254. Is this user properly authorized to access those descriptors?");
|
traceEvent(TRACE_ERROR, "Unable to open any tap devices /dev/tap0 through /dev/tap254. Is this user properly authorized to access those descriptors?");
|
||||||
traceEvent(TRACE_ERROR, "Please read https://github.com/ntop/n2n/blob/dev/doc/n2n_on_MacOS.txt");
|
traceEvent(TRACE_ERROR, "Please read https://github.com/ntop/n2n/blob/dev/doc/macOS.md");
|
||||||
return(-1);
|
return(-1);
|
||||||
} else {
|
} else {
|
||||||
char buf[256];
|
char buf[256];
|
||||||
|
|
Loading…
Reference in New Issue
Block a user