n2n/doc/Faq.md

48 lines
2.8 KiB
Markdown
Raw Normal View History

2020-08-26 10:04:15 +02:00
# n2n Frequently Asked Questions
2020-08-27 11:48:02 +02:00
2020-08-26 10:04:15 +02:00
## Supernode
2020-08-27 11:48:02 +02:00
2020-08-26 10:04:15 +02:00
### I want to setup a supernode that only I can use. Perhaps even password protected?
Please think of the community-name as password and start the supernode with the `-c <community file>` parameter where the `<community file>` is the path to a simple text file containing a single line with the name of your secret community. It will be the only community allowed. Only edge nodes from that community can join (`-c <community name>` at the edge).
If you additionally want to prevent open transmission of your secret community name via the network, **all** edge nodes should use `-H` command line option for header encryption.
Also, please see the community.list file for advanced use of that file.
Beyond this access barrier you may want to use payload encryption `-A_` at the edges. Only the edges not the supernode are able to decipher the payload data. So, even if anyone would be able to break the access barrier to the supernode, the payload remains protected by the payload crypto, see [this document](https://github.com/ntop/n2n/blob/dev/doc/Crypto.md) for details.
2020-08-27 11:48:02 +02:00
2020-08-26 10:04:15 +02:00
### Can I get a list of connected edge node and their community and source IP from the supernode?
2020-08-27 11:48:02 +02:00
The supernode provides basic information via its localhost udp management port. It defaults to 5645 and can be changed using supernode's `-t` command line option.
2020-08-26 10:04:15 +02:00
2020-08-27 11:48:02 +02:00
You can request the current status by just sending a new line, i.e. pressing [ENTER] key, running the following command (localhost only)
2020-08-26 10:04:15 +02:00
`netcat -u localhost 5645`
2020-09-14 17:22:03 +02:00
### Is there support for multiple supernodes?
As of now, one additional supernode is supported. The additional supernode is handled in a backup-fashion: A reserve-supernode can be started if one fails. The reserve-supernode just has to be known to the edges beforehand (simply by an additional `-l <ip:port>` at the edge).
Actively using several in parallel will have your network fall apart (partitioned some edges connected to one supernode, some to another).
Considering these known limitations, current discussions however seem to move more towards a fully p2p-approach which then would require no supernode at all, every node might be equal highly increasing network resilience.
2020-08-27 11:48:02 +02:00
2020-08-26 10:04:15 +02:00
## Edge
2020-08-26 10:06:54 +02:00
### How can I know if peer-to-peer connection has successfully been established?
2020-08-26 10:04:15 +02:00
2020-08-27 11:48:02 +02:00
The edge also offers a local udp management port at which it provides some information about connected _peers_ allowing a peer-to-peer connection, and _pending peers_ whose connections are forwarded through the supernode.
2020-08-26 10:04:15 +02:00
2020-08-27 11:48:02 +02:00
The edge's management port defaults to 5644 and can be changed using edge's `-t` command line option. Connecting using the following command (localhost only)
2020-08-26 10:04:15 +02:00
`netcat -u localhost 5644`
2020-08-27 11:48:02 +02:00
answers every new line, i.e. pressing [ENTER] key, with current information. The edge even understands some simple commands, try `help`.