The advantage to the current approadch of Syncthing would be, that even the metadatas are encrypted.
So for the spys it would be not even visible, that the datas are from Syncthing and it would be much more hard to see, who is transfering datas to who.
As we saw in NSA-leeks, more interessting for spying countrys are the metadatas.
I wanted only to show you this option in case you haven’t heard from it before
To expand on that… Protecting your data in flight is “easy” - and we do that as well as it’s possible with commonly available technology. Hiding who you’re communicating with is hard, very hard. We don’t even try, and the people who do try (Tor for example) seem to have lets say “varying” amounts of success. If you have an actual reason to worry about NSA surveillance, get off the internet right now. Their resources, and those of similar state level players, are such that this is not a game you’re winning.
I’ll jump in here as someone who’s familiar with how CJDNS works:
CJDNS creates a tun interface that it listens on (on *nix, I have no idea what the equivalent is on windows), and tunnels traffic over it. It’s encrypted end to end using a public key you can verify based on the destination’s ipv6 address. (I believe the address is derived /from/ the key)
If syncthing is able to be completely agnostic about what sort of interface it passes data over, this should already work with one caveat: the introducer/announcer for syncthing should be hosted inside cjdns so that it correctly announces the ip addresses of your connected shares (which are fe80::/10), or just be aware of peers announcing local IP’s in that range. the former seems less likely to accidentally clobber anything.
Hi, I am using Cjdns on two nodes and Yggdrasil-network not linked as I am told that new users can only put 2 links in a comment and the issues are more important (similar to Cjdns) on three that are also running Syncthing. I am often either behind NAT or CGN and would prefer to avoid using Syncthing relays as the nodes can connect to each other directly through Yggdrasil and Cjdns (and sometimes those nodes even autopeer when they happen to end up in the same WLAN).
I understand that there might not be interest in supporting all overlay networks by Syncthing, but I wanted to ask if they would get supported as a side effect of either of these two issues?
From the second issue, especially part of one comment:
Devices should exchange all their information. This could be alternative IPv6 addresses, as well as additional IPv4 addresses.
Wouldn’t this mean that if implemented, my Cjdns & Yggdrasil nodes also announced their addrsses within those networks and would be automatically connected to by my other nodes as long as they were on the networks?
PS. Sorry for necromancing the thread in case you have a policy against that, this just seemed more relevant place to ask than either of those GitHub issues and this is the only thing I can find while googling for “cjdns syncthing”.
I have no idea what those things are, but I don’t think overlay network will ever be implemented in syncthing. If you already have an overlay, perhaps announcing all local addresses as the ticket explains would help nodes connect via an overlay if you already happen to have one.
I also don’t know about those things, but one of them has “DNS” in the name. You can tell Syncthing to try multiple addresses in order, and they can be names. So perhaps you can set a device address to tcp://whatever.yggdrasil, dynamic to first try to look up the whatever.yggdrasil name and then use the default discovery stuff. Assuming your overlay stuff supports name lookup and something that behaves like DNS.
I think I can summarize and re-ask the question here:
Does Syncthing, when sharing its network addresses with peers, give “internal” ipv6 addresses in the list?
If yes to 1, is it possible to configure syncthing such that it only uses that (perhaps manually specified) address? (I know the answer to this is yes).
The way I’ve built a syncthing node group using overlay networks is, basically, to disable global services (discovery, relays, etc), and manually specify a central node peer (set it as an introducer) to which all others connect…
As a small clarifier, no direct support for any of this is required in syncthing – as far as syncthing is concerned cjdns (and other similar overlay networks) appear as yet another network connection between nodes. It may, however, need to be coaxed to use that particular connection.
Global discovery (which you’ve disabled, so not really relevant but still) doesn’t announce internal addresses. The IPv6 source address as seen by the discovery server is what it will tell other devices. Local discovery doesn’t either, but the source address of the packet is what is used for the connection as the discovery is LAN-local.
(The concept of “internal” addresses is vague for IPv6 btw. Link local addresses are not announced ever. Other global unicast addresses will be announced if the sync address is bound to one explicitly, but not if the socket is bound to ::.)
Ok. CJDNS addresses are NOT link-local. These are unicast addresses. Wiki says it’s a unique local address. I would assume syncthing should be bound on that address by default, if it’s binding to ::.
I have other overlay networks running, so let me see if I can get syncthing to connect directly to my server via cjdns (hardcode the address).
Ok, confirmed, it can be done. Manually entered tcp6://[address]:22000 and found success. Same for a AAAA record with same IP. nice.
So, yeah, footguns: local peer discovery won’t work over cjdns due to properties of that particular network, but other mesh/overlays may support it if they can do multicast.
So, to bring it all the way back around to the original question: No, for the reason I mentioned in my previous post – local peer discovery won’t work in cjdns. However, you can easily link all nodes if you set one (1 w/best uptime) as introducer to ease connections. A hub+spoke architecture, basically, which is how much of cjdns is done already. One thing to note here is that cjdns addresses are perfectly stable, so in this particular scenario it’s actually 100% OK to hardcode the ipv6 address. If the address has changed, it’s technically a new peer.
Local peer Discovery WILL (probably) work on same wifi mesh due to regular network transport (public ipv6/4) unless there are actually no other ip services running. And even still, I think most OS’s at this point will try ipv6 broadcasts on LAN to discover peers at that level of the stack (which would result in physically-local syncthing nodes finding eachother, if local peer discovery is enabled).
(please correct me if anything sounds wrong – it’s been about 2y since I’ve dug into the specifics like this)
