diff --git a/README.md b/README.md index 2f6fe8f..66d910f 100644 --- a/README.md +++ b/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 diff --git a/android/BUILD.txt b/android/BUILD.txt deleted file mode 100644 index 52b9a9f..0000000 --- a/android/BUILD.txt +++ /dev/null @@ -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. diff --git a/android/README.md b/android/README.md new file mode 100644 index 0000000..2c5f166 --- /dev/null +++ b/android/README.md @@ -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. diff --git a/doc/IPv6.md b/doc/IPv6.md index 3173af7..b32b5e0 100644 --- a/doc/IPv6.md +++ b/doc/IPv6.md @@ -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` diff --git a/doc/MTU.md b/doc/MTU.md index f9f512e..05fb6fc 100644 --- a/doc/MTU.md +++ b/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. diff --git a/doc/NEW_FEATURES.txt b/doc/NEW_FEATURES.txt deleted file mode 100644 index a4ab58f..0000000 --- a/doc/NEW_FEATURES.txt +++ /dev/null @@ -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. diff --git a/doc/Routing.md b/doc/Routing.md index 9f3eff0..030cbee 100644 --- a/doc/Routing.md +++ b/doc/Routing.md @@ -1,166 +1,163 @@ -# 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). -- These networks are connected to the internet via routers 10.11.12.1 -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. + +- 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 + 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. - 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. -- 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 -**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`. +## Reach Complete Office Network from n2n Node at Home -**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. -To make the complete office network aware of how packets or answers are -sent to **h**ickory, one more step is required: +- 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 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 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 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. +To make the complete office network aware of how packets or answers are +sent to **h**ickory, one more step is required: -## 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: -- 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 -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: -- 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`. -- 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. -- 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. + +- 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`. +- 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. +- 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. ## Route All Internet Traffic from n2n Node at Home through Office Network -This scenario could be considered a n2n-tunneled VPN connection which -also would work for travelling users on their laptop. All external -internet traffic will appear to originate from **o**scar and the office +This scenario could be considered a n2n-tunneled VPN connection which +also would work for travelling users on their laptop. All external +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: -- 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`. -- 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` +- First, one of the setups described above needs to be in place, with + 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`. +- 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` -- **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`. -- Unfortunately (unless the supernode is on **h**ickory's local -network), n2n supernode becomes unreachable for **h**ickory. To fix it: -`ip route add via 10.11.12.1 dev eth0 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`. +- Unfortunately (unless the supernode is on **h**ickory's local + network), n2n supernode becomes unreachable for **h**ickory. To fix it: + `ip route add 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), -e.g. in case of using dynamic domain name services, a DNS server needs -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 -could to be added and **h**ickory's DNS settings might be set -accordingly, maybe to Google's 8.8.8.8. +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), +e.g. in case of using dynamic domain name services, a DNS server needs +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 +could to be added and **h**ickory's DNS settings might be set +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. -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 -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 -ships through the n2n tunnel. +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 +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 +ships through the n2n tunnel. -To prevent such a DNS leak, the supernode's IP address must be -determined independently from **h**ickory's DNS configuration, e.g. by -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 -line as well as the static route mentioned above. Without further -additional work, dynamic address changes remain undetected. A static -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 -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 +To prevent such a DNS leak, the supernode's IP address must be +determined independently from **h**ickory's DNS configuration, e.g. by +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 +line as well as the static route mentioned above. Without further +additional work, dynamic address changes remain undetected. A static +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 +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 through the n2n tunnel. A test for DNS leaks can be found [here](https://www.dnsleaktest.com/). diff --git a/doc/Windows.md b/doc/Windows.md index b95fdc6..5edf60a 100644 --- a/doc/Windows.md +++ b/doc/Windows.md @@ -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 - downloaded and installed from https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2017 +- 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. - - 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 . - The full version is required (not the "Light" version). The Win32 version of it is usually required for a standard build. + ```plaintext + 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 - 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 + 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 - http://build.openvpn.net/downloads/releases (search for "tap-windows") +- 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 - - 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 ``` diff --git a/doc/macOS.md b/doc/macOS.md new file mode 100644 index 0000000..f3c610e --- /dev/null +++ b/doc/macOS.md @@ -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). diff --git a/doc/n2n_on_MacOS.txt b/doc/n2n_on_MacOS.txt deleted file mode 100644 index 38a03bb..0000000 --- a/doc/n2n_on_MacOS.txt +++ /dev/null @@ -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 - diff --git a/doc/new-features.md b/doc/new-features.md new file mode 100644 index 0000000..b3e051c --- /dev/null +++ b/doc/new-features.md @@ -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. diff --git a/doc/Centos.md b/doc/rpm-packaging.md similarity index 78% rename from doc/Centos.md rename to doc/rpm-packaging.md index b1d2e00..b671a7f 100644 --- a/doc/Centos.md +++ b/doc/rpm-packaging.md @@ -1,6 +1,6 @@ -# Packaging +# RPM Packaging -``` +```bash ./autogen.sh ./configure make diff --git a/tuntap_osx.c b/tuntap_osx.c index 8e85e86..52a1d28 100644 --- a/tuntap_osx.c +++ b/tuntap_osx.c @@ -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];