=> Install cloudflared => Honk Manual
For FreeBSD, the makefile has the line indicating how to build cloudflared:
git clone --depth=1 https://github.com/cloudflare/cloudflared.git
cd cloudflared
GOOS=freebsd GOARCH=amd64 go build -mod=vendor -v ./cmd/cloudflared
Honk requires the libraries for SQLite3. Then just follow the steps from the admin manual:
go install humungus.tedunangst.com/r/honk@latest
honk -datadir ./honking init
honk -datadir ./honking admin
cp -R ~/devel/honk/views .
honk -datadir ./honking -log honk.log run
Prefer the commandline method for creating the tunnel (described on the Cloudflare page).
Then make the configuration file .cloudflared/config.yml
to redirect webfinger:
tunnel: <Tunnel-ID>
credentials-file: /home/unprivileged/.cloudflared/<Tunnel-ID>.json
ingress:
- hostname: honk.example.com
path: \.?well-known
service: http://localhost:8077
- hostname: honk.example.com
service: http://localhost:31337
- service: http_status:404
Why redirect webfinger? There seems to be sanitizing by the tunnel which removes the dot prefix from the URL. It never reaches the webfinger route on its own. We wrote a simple webfinger server to only respond with the static webfinger JSON. Then tested by making the regex path for both dot/none prefix, and forwarded to this static server on port 8077
. At that point, going to https://webfinger.net
and searching for our [email protected]
became successful.
Why tunnel? So Cloudflare made the cloudflared tunnel available for free otherwise we wouldn’t even try. That’s reason #1. Next, it had a great claim which was to hide your internal services. In the past, I think this only applied to HTTP/S, but the features have expanded to TCP and more ports. Anyways if the configuration fits, we never have to expose public IP addresses; the Cloudflare proxy becomes the public layer and our services stay inside private subnets (e.g., 10.0.0.1). We don’t need to configure firewall rules or spin up our own VPN. We need to have a domain name such as example.com
then our service listening at http://localhost:8077
can be accessed externally by https://example.com
. Besides the frictionless setup, having Cloudflare as the public surface should give one element of security because known attackers can be detected by Cloudflare infrastructure before they forward the request to our server.