1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
CJDNS autopeering approach
I am working lately to figure out how to integrate CJDNS ip6/publickey with an autopeering mechanism.
I 'll find a way to publish and republish new peering settings. This would also be a log of "logins" so you know the history of your connections which, if comes to it, a public one(log).
Note:
Be sure that you know and understand the privacy settings that are made by this. You will most probably, publish your history of IPs that you connected from, if you are an accepting connection peer, hence your public IP.
We are going to maintain a list or just announce the latest.
However, since it's possible that your ISP is logging which connections you are making, it's better to know from which places you connected from. This is about public IP that you may need a firewall rule exception to allow incoming peerings. If you do so, then for sure your public IP will be announced. It would be announcing the current IP that you are accepting probably or preferable to your authorizedPasswords, which could possibly apply a thin layer of privacy there.
We will be making this with cjdnsadmin and try to add automatically the public IP to connect.
It maybe proved useful as the mobile data connections or the home dialup connection where dynamic IPs.
Which ever the cause of changing, since you are a provider of network in the way of are accepting incoming connections, it's better to inform them your contacts about your newest appearance. This could be also include local networking IPs if someone wants to do also.
We would be detecting the IP of the host, in two ways:
1) By scanning interfaces and gather an IP array
Example:
10.0.0.12
We scan the 10.0.0.0/24 network
Example:
10.0.0.12
192.168.0.21
We scan both, 10.0.0.0/24 and 192.168.0.0/24.
What do we achieve? We achieve a list of results. If we 've seen a peer in the configuration file, but we can not find them in the same place, we scan the whole network to find them :D We use the same ports since mostly we are not going to change port every time (possibly, it could be an "aggressive scanning/peering" technique, which could be as an option). Reminds me of what I understand of DHT system but I prefer it like this for now. Commenting is on discussion on pkt.chat or arching-kaos IRC network. :)
In the end, we will be just reusing the saved in cjdroute.conf file to parse the IPs and search for them in the local and public subnets. By scanning local nodes around the local network IPs for possible cjdns users according to already having infomation.
I would mostly work on it with CJDNSadmin, to try the connections, rather than restarting CJDNS for every try.
2) Make sure that the public IP is valid by quering the IP of the provider we are connected to using the configuration file. For example:
$ peerStats | grep EST | awk '{print $1}' | sed -e 's/\:[0-9]*$//g'
This is outputing the thing. The current connected peers. We will just ask them from a port that we are listening to as a tool that could be running along, or it could be another command whatever, no idea... actually this is started to interconnect other instances and exchange of credentials to put autopeering on ArchingKaos network backend.
In the end, I think it more like, insert some more code on CJDNS to do this, or use a library that already exists. I know it's not NEWS is my latest thoughs. Maybe not even well written for the moment.
Clean up:
1) We have stored a CJDNS peer for IPv4 connection:
"192.168.20.5:43231"{...}
But 192.168.20.5 is not appearing as ESTABLISHED connection. We try the same credentials over to 192.168.20.1-254 range. Succeed or fail, we stop until the next scan.
2) We have incoming connection to "alice" and "bob".
We convert their publickeys to IPs, search for them, and if we have new IPv4/6 we are available from, we announce it to them. This means that they should already been connected through another node into the network.
|
