Go to file
Hamish Coleman 4438f1aa2a
added mingw test platform (#829)
* Provide a minimal reimplementation of our autoconf, to try windows builds

* Try building with windows

* Fix thinko in spelling

* Ensure shell script runs inside a shell

* Add a hack to aid include discovery

* Just keep adding tech debt...

* Assume that we will have slashes in some of the replacement strings and avoid that char with sed

* Restore one slash

* Hack around the tools makefile interdependancy bug

* A correct cflags include hack for each compile dir

* Ensure we link against winsock (note, even though this says 32bit, it should link the 64bit library ... I think)

* Bad link ordering if we dont use LDLIBS

* Remove unused make variable

* Remove makefile duplication using inheritance (this does mean you can no longer cd tools; make, but must do make tools)

* Add missing library for win32

* Show OS variable

* Make hack autoconf more robust for tests on non gitlab runners

* Remove no longer used substitutions from hack autoconf

* Add missing include path to tools under win32

* Build the win32 subdir when the compiler is Msys

* The different subdirs have different dependancies

* Ensure we can find the include files

* Fix library link ordering

* Ensure the tools dir can find the special win32 lib

* Deal with the differing basic type sizes on both linux/64bit and windows/64bit

* Document the steps to mimic the github windows/mingw build locally - to allow for simpler debugging

* Ensure branch name in instructions matches my test branch name

* Clarify the shell needed to build with mingw

* Since the makefile depends on knowing the OS, raise a fatal error if we cannot determine this

* Handling different compile environments is hard.

- Linux: sane and reasonable results for both uname -s (=Linux) and
  uname -o (=GNU/Linux)
- Windows/Mingw: insane results for uname -s
  (=MSYS_NT-$MAJOR.$MINOR-$BUILDNR) but sane results for uname -o (Msys)
- Macos: sane results for uname -s (=Darwin) but does not support
  uname -o at all

* Revamp the way that Mingw is detected

* Avoid attempting to generate gcovr report when running under windows

* Whoops, isolate the right step

* Fix spelling mistake

* win32/Makefile: Remove unused setting and add comment

* ensure that all win32 includes use the same expected path

* Allow simpler cross compilation by letting configure pass the CC and AR environment through

* Avoid multiple '_CRT_SECURE_NO_WARNINGS redefined' warnings

* Convert to a consolidated CONFIG_TARGET variable to select any different compile options

* Use the more generic printf defines to avoid warnings on mingw

* Update mingw build docs

* English better for reader happy make

* Address a number of mingw compiler warnings

* Fix Visual C compile

* Be sure to document some of the hacky nature of the mingw build
2021-10-06 00:52:15 +05:45
.ci Traffic Restrictions, Pass Build on CircleCI and local Windows 10 VS2019 (#499) 2020-11-16 21:27:42 +01:00
.circleci Traffic Restrictions, Pass Build on CircleCI and local Windows 10 VS2019 (#499) 2020-11-16 21:27:42 +01:00
.github/workflows added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
doc added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
include added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
legacy Code rework changes 2019-04-27 15:55:07 +02:00
packages Major documentation improvements (#752) 2021-08-19 20:02:53 +05:45
scripts added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
src added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
tests added test framework and code coverage reporting (#797) 2021-09-27 15:26:06 +05:45
tools added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
win32 added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
wireshark Add dissector port note 2019-08-15 18:13:59 +02:00
.gitignore added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
.travis.yml Added travis build file 2020-11-11 10:20:39 +01:00
autogen.sh Update autogen.sh (#655) 2021-04-05 19:27:17 +02:00
CHANGELOG.md updated CHANGELOG.md 2020-08-07 22:26:32 +05:45
CMakeLists.txt added test framework and code coverage reporting (#797) 2021-09-27 15:26:06 +05:45
community.list removed begin and end from reg exp 2020-09-16 02:41:50 +05:45
config.guess Added configure and autogen.sh 2018-10-07 11:37:19 +02:00
configure.seed added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
contributors.txt Updated contributors 2020-08-12 12:21:07 +02:00
COPYING Initial SVN import of n2n v2 2016-10-23 10:46:15 +02:00
edge.8 updated n2n.7 man page (#825) 2021-09-27 14:57:26 +05:45
INSTALL Initial SVN import of n2n v2 2016-10-23 10:46:15 +02:00
LICENSE Initial commit 2016-10-23 10:42:16 +02:00
Makefile.in added mingw test platform (#829) 2021-10-06 00:52:15 +05:45
n2n.7 updated n2n.7 man page (#825) 2021-09-27 14:57:26 +05:45
README.md updated README.md 2021-02-27 22:36:44 +05:45
supernode.1 updated n2n.7 man page (#825) 2021-09-27 14:57:26 +05:45

Build Status

n2n

n2n is a light VPN software which makes 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.
  • edge nodes: the nodes which will be a 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 computer 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 peer-to-peer connection via udp 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

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.

On host1 run:

$ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.1 -f -l supernode.ntop.org:7777

On host2 run:

$ sudo edge -c mynetwork -k mysecretpass -a 192.168.100.2 -f -l supernode.ntop.org:7777

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 from connecting to your computer. For the privacy of your data sent and to reduce the server load of supernode.ntop.org, it is also suggested to set up a custom supernode as explained below.

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).

  1. Install the n2n package
  2. Edit /etc/n2n/supernode.conf and add the following:
    -p=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.

Manual Compilation

On Linux, compilation from source is straight forward:

./autogen.sh
./configure
make

# optionally install
make install

Some parts of the code significantly benefit from compiler optimizations and platform features such as NEON, SSE and AVX. To enable, use ./configure CFLAGS="-O3 -march=native" for configuration instead of ./configure.

For Windows, MacOS and general building options, please check out Building documentation for compilation and running.

IMPORTANT It is generally recommended to use the latest stable release. Please note that the current dev branch usually is not guaranteed to be backward compatible neither with the latest stable release nor with previous dev states. On the other hand, if you dare to try bleeding edge features, you are encouraged to compile from dev just keep track of sometimes rapidly occuring changes. Feedback in the Issues section is appreciated.

Security Considerations

When payload encryption is enabled (provide a key using -k), the supernode will not be able to decrypt the traffic exchanged between two edge nodes but it will know that edge A is talking with edge B.

The choice of encryption schemes that can be applied to payload has recently been enhanced. Please have a look at Crypto description for a quick comparison chart to help make a choice. n2n edge nodes use AES encryption by default. Other ciphers can be chosen using the -A_ option.

A benchmark of the encryption methods is available when compiled from source with tools/n2n-benchmark.

The header which contains some metadata like the virtual MAC address of the edge nodes, their IP address, their real hostname and the community name optionally can be encrypted applying -H on the edges.

Advanced Configuration

More information about communities, support for multiple supernodes, routing, traffic restrictions and on how to run an edge as a service is available in the more detailed documentation.

Contribution

You can contribute to n2n in various ways:

  • Update an open issue or create a new one with detailed information
  • Propose new features
  • Improve the documentation
  • Provide pull requests with enhancements

For details about the internals of n2n check out the Hacking guide.

Answers to frequently asked questions can be found in our FAQ document.

Here is a list of third-party projects connected to this repository:

  • Collection of pre-built binaries for Windows: lucktu
  • n2n for Android: hin2n
  • Docker images: Docker Hub
  • Go bindings, management daemons and CLIs for n2n edges and supernodes, Docker, Kubernetes & Helm Charts: pojntfx/gon2n

(C) 2007-2021 - ntop.org and contributors