mirror of
https://github.com/ntop/n2n.git
synced 2024-09-20 00:51:10 +02:00
sync 'upstream/dev' into dev
This commit is contained in:
commit
a9e48bb353
|
@ -7,7 +7,7 @@ GIT_COMMITS=@GIT_COMMITS@
|
|||
|
||||
CC?=gcc
|
||||
DEBUG?=-g3
|
||||
#OPTIMIZATION?=-O2
|
||||
OPTIMIZATION?=-O3
|
||||
WARN?=-Wall
|
||||
|
||||
#Ultrasparc64 users experiencing SIGBUS should try the following gcc options
|
||||
|
|
67
README.md
67
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 enstablish 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,12 +29,11 @@ $ 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 adviced 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 exmplained 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:
|
||||
|
@ -48,8 +45,7 @@ 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
|
||||
|
||||
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,26 +126,26 @@ 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 variuos ways:
|
||||
You can contribute to n2n in various ways:
|
||||
|
||||
- Update an [open issue](https://github.com/ntop/n2n/issues) or create a new one with detailed information
|
||||
- Propose new features
|
||||
- Improve the documentation
|
||||
- Provide pull requests with enhancenents
|
||||
- Provide pull requests with enhancements
|
||||
|
||||
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.
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
# NOTE: update version in CMakeLists.txt after changing these
|
||||
N2N_MAJOR="2"
|
||||
N2N_MINOR="5"
|
||||
N2N_PATCH="1"
|
||||
N2N_MINOR="7"
|
||||
N2N_PATCH="0"
|
||||
|
||||
N2N_VERSION_SHORT="$N2N_MAJOR.$N2N_MINOR.$N2N_PATCH"
|
||||
|
||||
|
|
|
@ -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.
|
|
@ -1,5 +1,7 @@
|
|||
# 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).
|
||||
- These networks are connected to the internet via routers 10.11.12.1
|
||||
|
@ -13,8 +15,8 @@ devices shall be called _n2n0_, and their n2n IP addresses are
|
|||
- 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
|
||||
|
||||
- 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.
|
||||
|
@ -27,11 +29,9 @@ any further configuration.
|
|||
|
||||
- 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`.
|
||||
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.
|
||||
|
@ -41,23 +41,21 @@ 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
|
||||
- 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
|
||||
- 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
|
||||
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 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
|
||||
|
@ -80,6 +78,7 @@ By the way, in case _iptables_ are messed up, they can be flushed by:
|
|||
## 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.
|
||||
|
||||
|
@ -87,10 +86,10 @@ the instructions given above.
|
|||
|
||||
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`.
|
||||
**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
|
||||
|
@ -118,8 +117,7 @@ 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`.
|
||||
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`
|
||||
|
@ -131,8 +129,7 @@ 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`
|
||||
`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,19 +1,22 @@
|
|||
# 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
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
|
@ -21,15 +24,14 @@ In order to run n2n:
|
|||
|
||||
- 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
|
||||
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
|
2
edge.c
2
edge.c
|
@ -598,6 +598,7 @@ static void daemonize() {
|
|||
|
||||
static int keep_on_running;
|
||||
|
||||
#ifdef __linux__
|
||||
#ifdef WIN32
|
||||
BOOL WINAPI term_handler(DWORD sig)
|
||||
#else
|
||||
|
@ -619,6 +620,7 @@ static void term_handler(int sig)
|
|||
return(TRUE);
|
||||
#endif
|
||||
}
|
||||
#endif
|
||||
|
||||
/* *************************************************** */
|
||||
|
||||
|
|
4
sn.c
4
sn.c
|
@ -913,6 +913,7 @@ static int loadFromFile(const char *path, n2n_sn_t *sss) {
|
|||
|
||||
/* *************************************************** */
|
||||
|
||||
#ifdef __linux__
|
||||
static void dump_registrations(int signo) {
|
||||
struct sn_community *comm, *ctmp;
|
||||
struct peer_info *list, *tmp;
|
||||
|
@ -941,11 +942,13 @@ static void dump_registrations(int signo) {
|
|||
|
||||
traceEvent(TRACE_NORMAL, "====================================");
|
||||
}
|
||||
#endif
|
||||
|
||||
/* *************************************************** */
|
||||
|
||||
static int keep_running;
|
||||
|
||||
#ifdef __linux__
|
||||
#ifdef WIN32
|
||||
BOOL WINAPI term_handler(DWORD sig)
|
||||
#else
|
||||
|
@ -967,6 +970,7 @@ static void term_handler(int sig)
|
|||
return(TRUE);
|
||||
#endif
|
||||
}
|
||||
#endif
|
||||
|
||||
/* *************************************************** */
|
||||
|
||||
|
|
|
@ -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