search

n42n / n3n

Peer to Peer VPN
47 stars 5 forks source link

Allow p2p communication only #37

Open nkxingxh opened 2 weeks ago

nkxingxh commented 2 weeks ago

Is it possible to put a restriction on the super node to only allow p2p communication without relaying traffic from edge 🧐

hamishcoleman commented 1 week ago

It is probably possible to add some limits to how much is allowed to be sent via the supernode, but the current protocol actually uses this traffic to trigger the p2p communication. There is also the problem that if p2p connection cannot be established, it leaves the network in a hard to detect partitioned state.

nkxingxh commented 1 week ago

Thank you for answering.

Is there any way to separate the “NAT hole-punching” traffic (or the initial traffic to establish a p2p connection)? Would this again cause compatibility issues with the original n2n edge?

On top of that, I'm curious as to why n3n's logging output defaults to errout.

nkxingxh commented 1 week ago

By the way, in use, I tested different NAT environments and found some issues:

I have categorized the mapping and filtering behaviors in the following table

image

I think it should be possible to establish p2p connections between class C users, but not in practice

hamishcoleman commented 1 week ago

The nat hole punching supernode traffic is both indistinguishable to the regular network packets and is encrypted such that the supernode cannot look at the packet data - so it will probably require an incompatible protocol change to achieve this seamlessly. It might be plausible to do some kind of rate limiting at the supernode, but the initial traffic would always need to traverse the supernode. Can you explain your use case in more detail?

There are a number of advances in the NAT traversal technology that we would like to add to the system - but from my side, that is waiting for a bunch of refactoring of the core code to make it easier to add in changes.

Where do you think the log output should go? In most cases, it is expected that these outputs are consumed by whatever is starting the daemon. When doing debugging and testting it is very handy to have the main log in stderr and separated from the output from the requested actions (in stdout)

nkxingxh commented 1 week ago

Modifying the code related to NAT hole-punching is really a challenge. As the title says, I want my supernode to be used only for “nat discovery” and not to forward traffic between edges.

Regarding the log output, I observed that there is output from both stdout and errout. With traceEvent the output is defaulted to errout, but the one located in src/win32/wintap.c uses printf and system output to stdout. this is different from the n2n which all outputs to stdout, so I have this question

hamishcoleman commented 1 week ago

Why are you wanting to force this use of your supernode? If we can understand better what you are trying to achieve then it might be possible to know what kinds of workaround would be possible to use.

Unfortunately, the win32 code was largely written without reference to the coding styles that are used in the entire rest of the codebase. As that code gets refactored, it should start using the traceEvent method for generating log messages for consistency. The output from the child processes and system() calls may be a little different, since their code cannot be updated to use traceEvent.

The longer term answer for logging on windows platforms may simply be to run the daemon as a windows service. Probably then sending the logging to the windows event log system (and losing any ability to see the messages from the child processes)