I can't use the -H parameter

[xjl456852]

I use the 3.1.1 version of n2n server. When I use windows client to connect the server, it can connect. The command is as follows edge edge.conf

The return is: [edge_utils.c:2515] [OK] edge <<< ================ >>> supernode

The edge.conf's content like this:

-c=xxx
-l=xxx:xxx
-a=xxx.xxx.xxx.xxx
-d=xxx
-k=xxx

When I add -H parameter into the content,It is not working. like this:

-c=xxx
-l=xxx:xxx
-a=xxx.xxx.xxx.xxx
-d=xxx
-k=xxx
-H

It only prompts me: like this: [edge_utils.c:1154] successfully joined multicast group xxx.0.0.xxx:xxxx 01/Sep/2022 14:16:37 [edge_utils.c:1563] WARNING: supernode not responding, now trying [xxx:xxx]

How should I use the -H parameter? How can I enable header encryption?

Thank you. Best regards.

[Logan007]

For -H, the supernode needs to have the community name in its list of locked community list (-c ... at the supernode).

[xjl456852]

I had set the community name in the supernode. the supernode configuration: vim /etc/n2n/supernode.conf -p=xxx -c=/etc/n2n/community.txt

vim /etc/n2n/community.txt xxxxxx

Then I run the command: systemctl start supernode But the client still can't connect the supernode.

[Logan007]

Can it connect if edge not using -H but same community name?

[xjl456852]

yes, If edge not using -H, It can connect.

[Logan007]

And if not using -H and some other/random community name at the edge?

[xjl456852]

Yes, I can't use the -H, even if I use other community name.

[Logan007]

Ah... no no no, I just want to make sure that community names are identical. So, my idea was to check if it works without -H at the edge but still keep the locked community name at the supernode -c <file>. If you then afterward (in a next step) use different community name at the edge, it should not connect.

However, only hint I can give for now is about supernode behavior. The supernode treats communities provided by -c <file> "undecided" with a view to header encryption after start-up. The first packet of that community locks the community either to header-encrypted or not header-encrypted, depending on if the edge sent encrypted or not. So, if you want to use -H, you also should make sure that there are no unecrypted edges with same community name, i.e. without -H, which eventually contact the supernode before and lock it to "unecrypted" community.

And of course, edge and supernode should be same version, but you certainly got that already.

[xjl456852]

Now the situation is: when -H is not used, you can connect using the project's community name, but if the community name is different, you cannot connect. I couldn't connect to supernode when I had the -H parameter enabled in Edge Now My configurations, It can work, It can connect the supernode: supernode:

edge:

Result:

=====

When I use the -H parameter in edge.conf, It didn't work.

Result:

[Logan007]

Did you re-start supernode each time after trying? Just to make sure it is not locked on "unencrypted header" community...

Other than that, could you please run edge and supernode with -vvvvv to get a more detailed log?

[xjl456852]

I try to restart all of the edges and supernode, and then add the -H in the edge configuration, It can connect. Thank you very much.

[mythsman]

I try to restart all of the edges and supernode, and then add the -H in the edge configuration, It can connect. Thank you very much.

It worked for me too ... I have to stop all the edges and supernode , then change the -H options , and then start all the edges and supernode .... Change that option one by one will make the cluster crash...

[Logan007]

Well, not really crash. But as documented, decision for a community to be header-encrypted or not is determined by supernodes (inspecting first packet, per community) once and then locked for security reasons (so it cannot be upgraded or downgraded by attackers). That's why it requires a restart of the supernodes after all edges have been set to the same -H setting (on or off).

I hope to overcome this somewhat complicated handling whenever we get to implement the 4.0 ideas...