a1facf0f3f
* First attempt at a openwrt CI * Fix action - helps if I dont forget the syntax half way through writing it * Try building /this/ branch for the openwrt CI * Try a build with openssl configured * Dont enable the n2n package until we have built the environment - makes errors easier to see and clearly related to n2n * Attempt to speed up the openwrt build * Upload any created ipkg packages * Dont test with openssl for the moment * Attempt to speed up openwrt build using a cache of the build dir * The make defconfig run turns all the built binaries stale, so stop caching them. Also use a real ref for the cache key * Minor text name changes * Address yamllint concerns * Attempt to simplify and document missing parts of the openwrt makefile * Attempt to fix mystery openwrt make error * Rename build job name * Avoid nested checkouts, use two separate dirs for the two checkouts in this build * Move the n2n checkout to earler, allowing us to skip one defconfig run * We are going to need working tags from the n2n repo, so ensure we unbreak the github checkout braindamage * Calculate and save the n2n version string * Prepare the way to pass the correct external vars into the openwrt build * Hook calculated build variables into the openwrt package definition * Update artifacts source to match moved checkout dir * Pass env vars in to the make * Allow version script to be influenced by external vars * It will help if I use the same variable names everywhere * Add more version variable calculation overrides * Configure openwrt to use the external git checkout instead of their create-tar-then-extract dance * Using the correct syntax for ifdef will help significantly * Use as many jobs as we have cpus * As the USE_SOURCE_DIR option allows us to use a full git checkout, we do not need to hack the version.sh to allow overrides * Ensure scripts/version.sh works from anywhere * Remove unneeded variables * Update openwrt build documentation to match the new build process * Catch failure to cd as per shellcheck suggestion * Limit lengthy openwrt builds to manual triggers or on a release * Also run on specially named branches * Break list into separate lines for easier future editing |
||
|---|---|---|
| .ci | ||
| .circleci | ||
| .github/workflows | ||
| doc | ||
| include | ||
| legacy | ||
| packages | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| win32 | ||
| wireshark | ||
| .gitignore | ||
| .travis.yml | ||
| .yamllint.yml | ||
| autogen.sh | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| community.list | ||
| config.guess | ||
| configure.ac | ||
| contributors.txt | ||
| COPYING | ||
| edge.8 | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.in | ||
| n2n.7 | ||
| README.md | ||
| supernode.1 | ||
| uncrustify.cfg | ||
| VERSION | ||
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).
- Install the n2n package
- Edit
/etc/n2n/supernode.confand add the following:-p=1234 - Start the supernode service with
sudo systemctl start supernode - 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.
Further Readings and Related Projects
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-21 - ntop.org and contributors