-- Leo's gemini proxy

-- Connecting to perso.pw:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini;

Run your own Syncthing relay server on OpenBSD


Author: Solène

Date: 03 November 2023

Tags: syncthing openbsd privacy security networking


Comment on Mastodon


Introduction


In earlier blog posts, I covered the program Syncthing and its features, then how to self-host a discovery server. I'll finish the series with the syncthing relay server.


The Syncthing relay is the component that receives file from a peer to transmit it to the other when two peers can't establish a direct connection, by default Syncthing uses its huge worldwide community pool of relays. However, while data are encrypted, this leaks some information and some relays may be malicious and store files until it could be possible to make use of the content (weakness in encryption algorithm, better computers etc…).


Running your own Syncthing relay server will allow you to secure the whole synchronization between peers.


https://relays.syncthing.net/

Syncthing official documentation: relay server


Related blog posts


Presenting Syncthing features

Blog post about the complementary discovery server


A simple use case for a relay: you have Syncthing configured between a smartphone on its WAN network and a computer behind a NAT, it's unlikely they will be able to communicate to each other directly, they will need a relay to synchronize.


Setup


On OpenBSD, you will need the binary `strelaysrv` provided by the package `syncthing`.


# pkg_add syncthing

There is no rc file to start the relay as a service on OpenBSD 7.3, I added it to -current and will be available from OpenBSD 7.5, create an rc file `/etc/rc.d/syncthing_relay` with the following content:


#!/bin/ksh

daemon="/usr/local/bin/strelaysrv"
daemon_flags="-pools=''"
daemon_user="_syncthing"

. /etc/rc.d/rc.subr

rc_bg=YES
rc_reload=NO

rc_cmd $1

The special flag `-pools=''` is there to NOT join the community pool. If you want to contribute to the pool, remove this flag.


There is nothing else to configure, except enabling the service at boot, and running it, at the exception the need to retrieve an information from its runtime output:


rcctl enable syncthing_relay
rcctl -d start syncthing_relay

In the output, you will have a line looking like this:


2023/11/02 11:07:25 main.go:259: URI: relay://0.0.0.0:22067/?id=SCRGZW4-AAGJH36-M71EAPW-6XK7NXA-5CC1C4R-R2TKL2F-FNFF2OW-ZWA6WK5&networkTimeout=2m0s&pingInterval=1m0s&statusAddr=%3A22070

You need to note down the displayed URI, this is your relay address, just replace `0.0.0.0` by the actual server IP.


Firewall setup


You need to open the port TCP/22067 for the relay to work, in addition, you can open the port 22070 which can be used to display a JSON with statistics.


To reach the status page, you need to visit the page `http://$SERVER_IP:22070/status`


Client configuration


On the client Web GUI, click on "Actions" and "Settings" to open the settings panel.


In the "Connections tab", you need to enter the relay URI in the first field "Sync Protocol Listen Addresses", you can add it after `default` by separating the two values with a comma, that would add your own relay in addition to the community pool. You could entirely replace the value with the relay URI, in such situation, all peers must use the same relay, if they need a relay.


Don't forget to check the option "Enable relaying", otherwise the relay won't be used.


Conclusion


Syncthing is greatly modular, it's pretty cool to be able to self-host all of its components separately. In addition, it's also easy to contribute to the community pool if one decides to.


My relay is set up within a VPN where all my networks are connected, so my data are never leaving the VPN.


Going further


It's possible to use a shared passphrase to authenticate with the remote relay, this can be useful in the situation where the relay is on a public IP, but you only want the nodes holding the shared secret to be able to use it.


Syncthing relay server documentation: Access control for private relays

-- Response ended

-- Page fetched on Mon May 6 07:46:10 2024