search

ntop / n2n

Peer-to-peer VPN
GNU General Public License v3.0
6.19k stars 933 forks source link

Did federation do this? #954

Closed lucktu closed 2 years ago

lucktu commented 2 years ago

I had a question the other day, v3's cpu using is high #933(https://github.com/ntop/n2n/issues/933)

It was caused by an ip, which was later banned on up router. the problem was temporarily solved.

Today through the "extranet packet capture" discovery, from this ip data too much, and are for the federation.

I didn’t tell him federation name, it shouldn’t send too many packets like this day and night, affecting my supernode.

Besides, I didn’t tell him federation name, and it can’t make federation with me, or if I change my federation name, then its edges should also be out of contact with me. but that’s not how it works.

lucktu commented 2 years ago

Or it should be set to, if the federation name doesn’t match my, stop building federation until the next manual operation.

lucktu commented 2 years ago

My sn: xxx.com:10090

SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=118.22.155.158 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=118.22.155.158 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=118.22.155.158 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090 SRC=82.157.65.12 DST=192.168.3.3 LEN=132 PROTO=UDP SPT=10090 DPT=10090

Logan007 commented 2 years ago

Just for clarification, the 82.157.xx.xx IP address is another supernode of yours?

And that other supernode does not share the same federation name?

And it sends traffic to your supernode?

Do they know each other from -l?

lucktu commented 2 years ago

Not, I don't know, To my supernode? not, when I kill my supernode, it's going like before. I don't use the -l.

Logan007 commented 2 years ago

Then my best guess is that the traffic you see is some other traffic sent to your supernode's port.

The supernode tries to determine if traffic is encrypted (header encryption) or federation (also encrypted) before determining to discard unwanted packets. That costs a bit of CPU power for decryption and checking.

lucktu commented 2 years ago

The traffic is about 400kb/s, attack?

Logan007 commented 2 years ago

Can't say, maybe the packet content would indicate something. Just to be safe, chose a random federation name for you r supernode then.

But if it were another supernode (maybe because it tries to connect to yours not knowing the correct federation name), traffic would be much less (one register every 20 seconds or so). A misled edge would retry every six seconds with a register packet – far less than 400 KB/s.

lucktu commented 2 years ago

I did an experiment, another supernode, using a different federation name and same port, and I didn't have any cooperation(no -l xxx), it actually succeeded in alliance with me. he knows my supernode(abc.com:10090).

Logan007 commented 2 years ago

What do you mean by "it actually succeeded in alliance with me"?

lucktu commented 2 years ago

When it restarted(I add -l xxx to it and let it take effect), all its edges came to me.

A misled edge would retry every six seconds with a register packet – far less than 400 KB/s. --- What if it had a lot of edges? this question can be put on, maybe an attack.

Logan007 commented 2 years ago

I did an experiment, another supernode, using a different federation name and same port, and I didn't have any cooperation(no -l xxx), it actually succeeded in alliance with me. he knows my supernode(abc.com:10090).

How could that independent supernode know about your supernode? It must have gotten a hint from another supernode to which it connected. But if it did not have a -l and no other supernode links to that supernode, it cannot have a clue.

If it had a different federation name, it should not be able to meanfully communicate with your supernode at all (federation name used for encryption).

Sorry, I was wrong with the 6 seconds. It's actually 3 seconds. 400 KB/s corresponds to 15,000 edges' (400,000 B/s / 80 bytes ) * 3 s REGISTER traffic.

lucktu commented 2 years ago

Another supernode, I managed for my friend. it have worked in a federation with my before, but I think there are many problems, so I didn't do it anymore. In this experiment, I modified my federation name to the one that has never been used before, but this result still happened. my supernode(n2n.lucktu.com:10090), everyone knows from supernode.ml.

Yes, if federation name is different, can't communicate between supernodes, but as long as it uses -l xxx(+ same port?) with me, its edges can be connected to my supernode. it's something I don't want to see.

attack? in fact, my experiment can't be reproduced either.

Logan007 commented 2 years ago

but as long as it uses -l xxx(+ same port?) with me, its edges can be connected to my supernode. it's something I don't want to see

Ah, I see. Then it probably is broadcast traffic from the other supernode (at that other IP address) which still links (-l) to yours.

Everyone who knows your supernode IP address can connect to it – including the edges from the other supernode. Only locked communities (-c at the supenode), maybe plus header encryption (-H at the edge), or authentication (-I, -J at the edge, keys at the supernode) can prevent it.

Yes, if federation name is different, can't communicate between supernodes

Correct, they do not federate.

Logan007 commented 2 years ago

So, you might want to ask your friend to remove -l.

To prevent unnecessary broadcasts, #958 only forwards to active supernodes (those who answered the encrypted REGISTER_SUPER in federation).

lucktu commented 2 years ago

I can't ask anyone else except to be myself, because I don't know him.

Logan007 commented 2 years ago

Then, best thing to do is to further block that IP address.

And certainly, a port change will help it. You would need to inform your community then. Maybe start announcements and a parallel supernode now and change in a week.

And, if you additionally want to limit access to your so-far public supernode for other edges, use one of the means mentioned above.

lucktu commented 2 years ago

No, I 'd rather let those（supernodes and edges） who don't know my federation name can't connect to my supernode by federation(Unless directly through my supernode).

Logan007 commented 2 years ago

This is where the current system of pre-shared keys reaches the limits. Edges do not and cannot know federation key. The only access protection for edges would be through secret community names, optionally paired with header encryption, and edge authentication.

Private-public keys in 4.0 might handle it differently.

lucktu commented 2 years ago

Why don't you do that?

Everyone(edge) has only one father(supernode). He(father) says that someone is his younger brother(federation), he mybe is, and says not(or not says), he must is't. Similarly, only that person is willing to be an uncle, he mybe is, if not, not.

When my father leaves temporarily, I am protected by my uncle, and when my father returns, I return to my father(or with uncle together). when uncle stopped calling uncle, I could only leave to my father.

lucktu commented 2 years ago

This seems to be back to the issue discussed before, I think it has always been a problem, ... ...

Logan007 commented 2 years ago

That would require another "family key" known to supernodes and edges only. That would need to be provided to edges and supernodes. We don't have that as a general key. And I am not sure if we can add it to 3.x. Locked communities with header encryption exactly fulfill this purpose on a more fine-grained basis – if I am not mistaken here.

lucktu commented 2 years ago

I always feel that you like to use passwords/key, but too many passwords are complicated. If it can be solved by logical, why add another parameter?

Logan007 commented 2 years ago

but too many passwords are complicated

Indeed. We are on the same page here.

If it can be solved by logical, why add another parameter?

I am not sure if I understand your idea correctly. Are you proposing a supernode selection strategy which prefers the -l-provided ones?

lucktu commented 2 years ago

Yes, for edge, which is its greatest reliance.

Please see a metaphor I made above.

Everyone(edge) has only one father(supernode). He(father) says that someone is … …

lucktu commented 2 years ago

The above only represents a personal point of view, and I don't know how the program runs, I am just a user, so my point of view is for reference only.

lucktu commented 2 years ago

Now there’s another ip (actually it is a supernode, not in edges) that keeps sending me data, and if I turn off my supernode, it stops.

Rebooting supernode twice, it stops, too.

lucktu commented 2 years ago

1's message:

This is what I saw on the openwrt page (When I gave “1.15.X.251” temporary access on up router by "iptables -I FORWARD 1 -s 1.15.X.251 -j ACCEPT") 001 That’s what I saw in ssh (using: iftop -P) at this point. 002

2's message:

The other ip's traffic is intermittent. I didn’t ban it.

Note:

  1. There is only n2n's traffic on the router (a openwrt router in docker).
  2. Those ips we’ve blocked, they’re all supernodes.

This problem may only be solved when the other people updates the program?

lucktu commented 2 years ago

2022-3-28

  1. The problem that have been solved: "Even if you don’t know my federation's name, you can join my federation only by -l xxx:yyy" (but the problem persists: "I was join in. I can’t cancel").
    1. The problem that have been solved: "sn_a and sn_b are in a federation, edge_a and edge_b are in a COM., but edge_a is in sn_a, edge_b is in sn_b, edge_a can't ping edge_b".
Logan007 commented 2 years ago

but the problem persists: "I was join in. I can’t cancel"

The point is that n2n so far has been considered to be open to everyone by default.

So, edges of all communities shall be able to connect to every supernode by default. If some edges (of originally some other place) link to your supernode (directly or indirectly by some other supernode information), your supernode will have to deal with the edges wanting to connect.

If a supernode shall not accept connections from certain edges, the admin can't leave the supernode open – meaning that community restrictions (-c at the supernode), header encryption (-H at edge) or user authentication (-I ... and -J ...) need to be enabled.

Unwanted connections from other supernodes can be prevented by a different federation name indeed.

The problem that have been solved: "sn_a and sn_b are in a federation, edge_a and edge_b are in a COM., but edge_a is in sn_a, edge_b is in sn_b, edge_a can't ping edge_b".

I have not been aware that this had been an issue so far.

lucktu commented 2 years ago

I couldn’t agree more: n2n has been considered to be open to everyone by default.

"Unwanted connections from other supernodes can be prevented by a different federation name indeed." that’s not how it works.

I just did an experiment like this: 1, first (original) SNA: supernode3 -p 10090 -F AAAA (community1/2/3/4/5) SNB: supernode3 -p 10090 -F BBBB (communityA/B/C/D/E) 2, restart SNB with "supernode3 -p 10090 -F AAAA -l SNA_IP:10090"

  1. return SNB with "supernode3 -p 10090 -F BBBB"
  2. then community 1/3/4/C/E in SNA, community 2/5/A/B/D in SNB, or others.
  3. stop SNA & SNB for a minute, then start them with original setting. then not community1/2/3/4/5 in SNA and communityA/B/C/D/E in SNB, it’s like this, community 1/2/3/B/D in SNA, community 4/5/A/C/E in SNB, or others. It’s been tested many times. even if you change the -F xxx of SNA, it’s the same.
  4. reboot PC (SNB), back to normal.
Logan007 commented 2 years ago

then community 1/3/4/C/E in SNA, community 2/5/A/B/D in SNB, or others.

Yes, the effect you observe is not about federation name, it is about community names. And every supernode is open to every community by default, no matter what federation it belongs to. You would need to limit communities then (-c at supernode).

Actually, implementation of federation was thought to work on top of limited communties, i.e.

open supernode >> supernode with limited communities >> federated supernodes with limited communities

If communities are unlimited, the supernodes will work with every edge from every community which wants to connect.

Your input on this might lead us to think about enforcing limited communities with federation or even apply changes to encryption scheme, if feasible (additionally fed-header-encrypt forwarded PACKET and REGISTER traffic between supernodes, might conflict with already header-encrypted communities though which are, well, pre-defined by -c).

lucktu commented 2 years ago

I couldn’t agree more: supernode is open to every community by default, no matter what federation it belongs to.

Advice(slight): in addition to having the same federation's name, you also need to add each other with -l xxx:yyy in order for the federation to succeed. so the official supernode doesn’t crash

In fact, after I did step 123 above, nodes that be in the same community may now belong to different supernode (SNA or SNB), so they can no longer ping each other. what about the new edge node? who does it belong to? that’s what matters to me.

(After my permission, joined my federation, now I no longer allow, but can not simply exit, causing some nodes can not work properly)

Logan007 commented 2 years ago

what about the new edge node? who does it belong to? that’s what matters to me.

Edges belong to communities.

As long as you do not construct supernode-based restrictions (such as user/password-authentication), you can't really say that edges belong to federations. Federations are between supernodes.

lucktu commented 2 years ago

The problem is, the same community now belongs to both SNA and SNB at the same time (after step 123). communityA have 3 edges, 2 belong to SNA, 1 belong to SNB.

Metaphorically speaking, I’m sorry if I offended you: Each community has only one father, and the others are called uncles.

Logan007 commented 2 years ago

Metaphorically speaking, I’m sorry if I offended you:

Don't worry! :orange_heart:

The problem is, the same community now belongs to both SNA and SNB (after step 123).

Each community has only one father, and the others are called uncles.

Yes, yes, every supernode can have any community if not restricted.

But federation is not thought of as father or uncle. Again, it is just a thing to connect supernodes for load-balancing.

In your case the issue is that some (edges and supernodes) think your supernode belongs to the federation while your supernode does not think so.

However, I get your point. 4.x will most likely include this more hierarchical idea of a "domain" which has (only) its (own) "communities".

lucktu commented 2 years ago

Is the issue being handling, or is it going to take until 4.x to solve it?

Logan007 commented 2 years ago

If the supernode is open to everyone, the edges do not even know about federation key (because it's a thing between supernodes). And as long as you leave your supernode open to everyone, you will see connection attempts from others who still have it in their list – even if falsely advertised.

Edges cannot be excluded from connecting to an open supernode just because they connected to another open supernode before.

That's the expected behavior for open supernodes in 3.x series. So, I understand your situation but I do not see too much of an issue to be solved by code here.

Best advice is to either block unwanted connections, change port, or restrict access (-C, -H, -I/-J).

As you mention 4.x, it will handle these things a bit differently. I plan on "domains" which can only be joined by nodes from the same domain. Each domain has communities again. However, it also will have an open domain (which will be like the open supernodes). But the domains will be easier to handle, like just pass -D <domain> to each node's conf. But, you need to publish your domain name along with your public node's data then.

lucktu commented 2 years ago

OK, Thank you!