If the user manually configures to use a stable MAC based IPv6 and runs Syncthing with global discovery enabled, i'd argue that he wants those IPs published. As long as the user doesn't disable random identifiers and switches to EUI-64 address generation instead, these addresse still don't leak the device MAC. The main concern raised by is about user privacy. The only option left would be to lookup globally routable IPv6 addresses via interface as we do already for private IPv4 ranges. The same goes for hardcoding the listening address as the prefix is renewed by the ISP once in a while. The result is that global IPv6 connectivity only works if either no firewall is involved or UDP/TCP holepunching succeeds.ĭisabling the creation of temporary addresses is not a workaround as it allows for website operators to freely track single devices. With temporary addresses enabled, neither of those two currently gets published to the discovery server. An IPv6 "port forwarding" configured via the router therefore doesn't apply to temporary addresses. The firewall rules only target EUI-64 (aka MAC generated) addresses and _maybe_ DHCPv6 IA_NA addresses if supported by the router vendor. The biggest drawback is that other clients are _very_ likely to hit the firewall of the router even if the user properly configured it. Running a local STUN server: seems overkill, too.Ĭontinuing the (lengthy) discussion from … issues/8443#issuecomment-1197320918 here.Īs of now Syncthing only publishes temporary IPv6 addresses to the global discovery server as these are enabled and used for outgoing connections on nearly all platforms by default. Using a local Relay Server: I did not pursue this too far, but it seems overkill somehow and I am not sure again if that would be any more elegant. This would be the only service running in host networking mode. Running the Syncthing container with host networking mode: doesn't really seem more elegant to me. The downsides are that this does not look very elegant, might not actually be the desired/expected behaviour and pollutes the log with periodic failure messages (rightly so, about not being able to bind those IPs). This seems to make Syncthing announce it to the Discovery Server regardless of the fact it can't bind the address. **Workaround** used for now: I added the internally-reachable IP as listen address together with wildcard listen addresses. Or in any other setup where the instance is actually reachable on a fixed/known IP address that is, however, not one of it's own/visible interfaces. I guess this could be useful for others running Syncthing in a dockerized setup. **Feature needed/suggested**: It would be a useful feature if one could manually specify IP addresses that the Syncthing instance announces to the Discovery Server (in addition or instead of the local interface IPs). And it's of course clear that Syncthing couldn't possibly know/find out the other IP. Both aren't the IPs under which other instances can reach it (this would be one of the VPS internal IPs). Syncthing synology plus#Now I just migrated one of the server instances into a Docker container and face one issue: that Syncthing instance only announces its internal container IP (when NAT disabled), plus the VPS' external/public IP (when NAT enabled). Since then, everything works very smoothly and reliably. To have all instances mutually discover each over smoothly and yet to keep everything within our network/VPN, we also started running a discovery server a while ago. Each staff member runs one instance on their laptop, and two instances run on our servers (one on-premise, one cloud/VPS). **Background**: We use Syncthing (extremely satisfied, btw!) in a small team of … staff members within the organisation's local network & VPN.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |