VPS: run frps under Quadlet #101

New issue

Open

opened 2026-08-17 15:07:09 -04:00 by mysticalsoap · 1 comment

mysticalsoap commented

2026-08-17 15:07:09 -04:00

Owner

Upgrade frps to current alongside the homelab frpc, and fold it into Quadlet for uniformity with the rest of the VPS.

Depends on the source-IP handling decided in the Debian 13 upgrade -- frps is the service that notices a masquerading port handler first.

Upgrade frps to current alongside the homelab frpc, and fold it into Quadlet for uniformity with the rest of the VPS. Depends on the source-IP handling decided in the Debian 13 upgrade -- frps is the service that notices a masquerading port handler first.

mysticalsoap added the

vps

new-service

labels

2026-08-17 15:07:09 -04:00

mysticalsoap commented

2026-08-17 17:49:57 -04:00

Author

Owner

Two hardening items to fold in while touching frps:

transport.tls.force = true on frps once both sides are current. frpc defaults TLS on (≥0.50), but frps doesn't require it — a misconfigured or downgraded client could authenticate over plaintext. The proxied HTTP payload is end-to-end TLS regardless (Traefik terminates at home); this is about the control channel.
The current unit runs frps as root with no sandboxing (User= absent). Quadlet migration covers this if the container runs rootless; if frps stays a bare binary instead, give it a dedicated user + the usual ProtectSystem=strict/NoNewPrivileges=true set. It needs no privileged ports directly — 80/443 arrive via allowPorts proxies bound by frps itself, so binding <1024 needs CAP_NET_BIND_SERVICE or a sysctl, worth checking during the move.

Two hardening items to fold in while touching frps: - **`transport.tls.force = true`** on frps once both sides are current. frpc defaults TLS on (≥0.50), but frps doesn't *require* it — a misconfigured or downgraded client could authenticate over plaintext. The proxied HTTP payload is end-to-end TLS regardless (Traefik terminates at home); this is about the control channel. - The current unit runs frps as root with no sandboxing (`User=` absent). Quadlet migration covers this if the container runs rootless; if frps stays a bare binary instead, give it a dedicated user + the usual `ProtectSystem=strict`/`NoNewPrivileges=true` set. It needs no privileged ports directly — 80/443 arrive via `allowPorts` proxies bound by frps itself, so binding <1024 needs `CAP_NET_BIND_SERVICE` or a sysctl, worth checking during the move.

mysticalsoap referenced this issue

2026-08-17 17:50:17 -04:00

Stack analysis: feature gaps and divergence from other homelabs #116