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:
Felix Pojtinger
GitHub
parent
317a425904
commit
8d64ed3ff8
69
README.md
69
README.md
|
|
@ -1,21 +1,19 @@
|
|||
# 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:
|
||||
|
||||
- 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-get 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 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:
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
**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
|
||||
2. Edit `/etc/n2n/supernode.conf` and add the following:
|
||||
```
|
||||
-l=1234
|
||||
```
|
||||
```
|
||||
-l=1234
|
||||
```
|
||||
3. Start the supernode service with `sudo systemctl start 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.
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -77,12 +73,11 @@ $ sudo ip route del default
|
|||
$ 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:
|
||||
|
||||
|
|
@ -96,11 +91,9 @@ make install
|
|||
```
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -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`.
|
||||
|
||||
Contribution
|
||||
------------
|
||||
## Contribution
|
||||
|
||||
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).
|
||||
|
||||
Related Projects
|
||||
----------------
|
||||
## Related Projects
|
||||
|
||||
Here is a list of third-party projects connected to this repository.
|
||||
|
||||
- N2n for android: [hin2n](https://github.com/switch-iot/hin2n)
|
||||
- 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/)
|
||||
- N2N for Android: [hin2n](https://github.com/switch-iot/hin2n)
|
||||
- N2N v1 and v2 version from meyerd: [meyerd n2n](https://github.com/meyerd/n2n)
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
the edge command line.
|
||||
|
||||
eg. under linux:
|
||||
Eg. under linux:
|
||||
|
||||
on hostA:
|
||||
`[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
|
||||
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
|
||||
maximize bandwidth.
|
||||
|
||||
PMTU Discovery Failures
|
||||
-----------------------
|
||||
## PMTU Discovery Failures
|
||||
|
||||
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
|
||||
|
|
@ -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
|
||||
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
|
||||
has been provided:
|
||||
|
||||
- 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.
|
||||
|
||||
- As examplained above, a lower MTU is set on the VPN interface, thus removing excessive fragmentation on
|
||||
the sender.
|
||||
|
||||
- 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
173
doc/Routing.md
173
doc/Routing.md
|
|
@ -1,37 +1,37 @@
|
|||
# IP v4 Routing (Linux)
|
||||
# IPv4 Routing (Linux)
|
||||
|
||||
## 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).
|
||||
**h**ome) and 192.168.1.0/24 (maybe in **o**ffice).
|
||||
- These networks are connected to the internet via routers 10.11.12.1
|
||||
and 192.168.1.1, respectively.
|
||||
and 192.168.1.1, respectively.
|
||||
- In each network, there is a computer running a successfully setup n2n
|
||||
node: 10.11.12.5 (**h**ickory) and 192.168.1.6 (**o**scar). They are
|
||||
connected to their networks through a device called _eth0_. Their n2n
|
||||
devices shall be called _n2n0_, and their n2n IP addresses are
|
||||
10.99.99.50 (**h**ickory) and 10.99.99.60 (**o**scar) in the
|
||||
10.99.99.0/24 network.
|
||||
node: 10.11.12.5 (**h**ickory) and 192.168.1.6 (**o**scar). They are
|
||||
connected to their networks through a device called _eth0_. Their n2n
|
||||
devices shall be called _n2n0_, and their n2n IP addresses are
|
||||
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.
|
||||
|
||||
## 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.
|
||||
|
||||
- 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.
|
||||
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
|
||||
|
||||
- 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
|
||||
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, **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: `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
|
||||
using just their regular (non-n2n) IP addresses 10.11.12.5 and 192.168.1.6.
|
||||
|
|
@ -39,69 +39,68 @@ To make the complete office network aware of how packets or answers are
|
|||
sent to **h**ickory, one more step is required:
|
||||
|
||||
- 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`
|
||||
**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:
|
||||
|
||||
- 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
|
||||
|
||||
This is not too complicated either. Basically, follow the given example
|
||||
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
|
||||
**o**scar:, especially: `ip route add 10.11.12.0/24 via 10.99.99.50 dev
|
||||
n2n0 src 192.168.1.6`.
|
||||
10.11.12.5 to its full network 10.11.12.0/24 in the route commands on
|
||||
**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
|
||||
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
|
||||
recommended static routes on other office computers.
|
||||
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
|
||||
recommended static routes on other office computers.
|
||||
- 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
|
||||
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
|
||||
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
|
||||
able to connect to the other network.
|
||||
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
|
||||
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
|
||||
either to the router (best option) or all those computers that shall be
|
||||
able to connect to the other network.
|
||||
|
||||
## Route All Internet Traffic from n2n Node at Home through Office Network
|
||||
|
||||
|
|
@ -111,28 +110,26 @@ internet traffic will appear to originate from **o**scar and the office
|
|||
network.
|
||||
|
||||
- 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
|
||||
enabled. It will not work without because the office router 192.168.1.1
|
||||
usually denies forwarding to packets not originating from its own
|
||||
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
|
||||
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
|
||||
src 192.168.1.6`.
|
||||
enabled. It will not work without because the office router 192.168.1.1
|
||||
usually denies forwarding to packets not originating from its own
|
||||
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
|
||||
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 src 192.168.1.6`.
|
||||
- To have **h**ickory's complete internet traffic going through the n2n
|
||||
tunnel, its default route needs to be changed:
|
||||
`ip route del default`
|
||||
`ip route add default via 10.99.99.60 dev n2n0 src 10.11.12.5`
|
||||
tunnel, its default route needs to be changed:
|
||||
`ip route del default`
|
||||
`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,
|
||||
_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
|
||||
needs to be added: `ip route add 10.11.12.0/24 dev eth0 src 10.11.12.5`.
|
||||
_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
|
||||
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
|
||||
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
|
||||
10.11.12.5`
|
||||
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 10.11.12.5`
|
||||
|
||||
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),
|
||||
|
|
|
|||
|
|
@ -1,35 +1,37 @@
|
|||
# Requirements
|
||||
# Build on Windows
|
||||
|
||||
## Requirements
|
||||
|
||||
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
|
||||
|
||||
- Cmake
|
||||
|
||||
- (optional) The OpenSSL library. Prebuild binaries can be downloaded from https://slproweb.com/products/Win32OpenSSL.html .
|
||||
- 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.
|
||||
|
||||
NOTE: in order to skip OpenSSL compilation, edit CMakeLists.txt and replace
|
||||
|
||||
```plaintext
|
||||
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:
|
||||
|
||||
- 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")
|
||||
|
||||
- If OpenSSL has been linked dynamically, the corresponding .dll file should be available
|
||||
- If OpenSSL has been linked dynamically, the corresponding .dll file should be available
|
||||
into the target computer
|
||||
|
||||
# Build (CLI)
|
||||
## Build (CLI)
|
||||
|
||||
In order to build from the command line, open a terminal window and run the following commands:
|
||||
|
||||
```
|
||||
```batch
|
||||
md build
|
||||
cd build
|
||||
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:
|
||||
"C:\Program Files\CMake\bin\cmake"
|
||||
`C:\Program Files\CMake\bin\cmake`
|
||||
|
||||
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.
|
||||
|
||||
Here is an example `edge.conf` file:
|
||||
|
||||
```
|
||||
```plaintext
|
||||
-c=mycommunity
|
||||
-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:
|
||||
|
||||
```
|
||||
```plaintext
|
||||
-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
|
||||
./configure
|
||||
make
|
||||
|
|
@ -47,7 +47,7 @@ int tuntap_open(tuntap_dev *device /* ignored */,
|
|||
|
||||
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, "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);
|
||||
} else {
|
||||
char buf[256];
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user