feat: add opt-in LAN access for managed services

[381181295]

Summary

Add explicit, opt-in LAN access for Lerd-managed databases, caches, mail, and custom services.

• Add lerd lan:services on|off|status.
• Persist the setting independently from normal LAN exposure.
• Rebind installed managed services when either LAN setting changes.
• Apply the policy automatically when services start or change ports.
• Add controls and effective-state reporting to the dashboard, CLI status, TUI, and system tray.
• Require authentication for remote dashboard access.
• Make remote host actions explicitly opt in with lerd remote-control full-access on|off|status.
• Prevent reverse proxies from bypassing authentication merely because they connect over loopback.

Behavior

Managed service ports are reachable from the LAN only when both settings are enabled:

lerd lan:expose
lerd lan:services on

The managed-service setting defaults to off.

Disabling either setting returns managed service ports to loopback. Inactive services remain stopped during rebinding. Site and worker containers are not exposed by this setting.

The interfaces distinguish between:

• disabled
• enabled but inactive because LAN exposure is off
• enabled and reachable

The dashboard and CLI warn that development services can use weak or empty credentials and should only be exposed on trusted networks with appropriate firewall rules.

Remote dashboard requests must pass the existing LAN exposure and Basic/session authentication gates. After authentication, the remote session can use ordinary dashboard controls. Host actions remain local-only unless full access is explicitly enabled from the Lerd host. Enabled host actions run on the machine that runs Lerd.

Testing

• make test
• CGO_ENABLED=1 go vet ./...
• gofmt -l .
• Frontend access-mode and affected component tests
• Production dashboard build
• Handler-level authority tests for Basic-auth and session-cookie requests
• Exact browser control comparison between robotbox through a local SSH tunnel and through the authenticated Tailscale URL with remote full access enabled:
  • System controls matched
  • Sites controls matched
  • Services controls matched
• Manual browser checks for disabled, configured-but-inactive, active, local, and authenticated remote states
• Manual authenticated remote browser mutation: managed-service LAN access toggled off and back on
• Manual Redis checks:
  • connection refused while exposure was inactive
  • PING returned PONG while exposure was active
• Full frontend run: 143 files passed; src/lib/notify.test.ts notification-dispatch test timed out

[geodro]

thanks for this, the LAN services half is good work and I took it more or less as it stands. the unit aware bind policy actually fixes an inconsistency that was already on main, where only nginx was regenerated but WriteQuadlet applied BindForLAN to every quadlet, so a service that got rewritten for an unrelated reason quietly picked up a 0.0.0.0 bind while exposed. and the IPv6 pairing addition is needed, without it the 127.0.0.1 line is lost on the way back from LAN to loopback, I checked that on a real install.

I pushed two commits to your branch rather than sending you round again, hope that is alright.

the first one is about the loopback only route list. I understand the reasoning in the description, if you trusted the password enough to expose the dashboard then why cripple it, and that is a fair position, but I want it opt in rather than the default. as it stood, one password stood between the LAN and every site's .env, the host filesystem, database drops and command execution, and there is no lockout on that basic auth path, I measured 100 wrong guesses in 4 seconds with the correct one still accepted afterwards. so the list is back and the gate consults a new ui.remote_full_access setting instead of refusing outright. lerd remote-control full-access on gets you what your branch did, there is a toggle in the dashboard card too, and both refuse to run from a remote session so a session cannot widen its own authority. I also renamed the authority helpers, isLoopbackRequest was returning true for authenticated remote sessions and about a dozen handlers gate on it, so the next handler someone adds would have inherited remote authority just by using the obvious looking function.

the second commit is a bug. if a container fails to restart during a rebind the loop returned on the first error, and because the quadlets on disk were already rewritten, a later run found nothing to do. I reproduced it by interrupting lan:services off two seconds in, which left the config saying off, the file saying loopback, lan:services status saying loopback only, and redis still answering PING from another machine on 6379. lan:unexpose did not clear it either. now every unit is attempted and the failures are reported together, and the restart decision compares each container's actual published ports against the policy, so an interrupted toggle heals on the next run.

one more thing folded into the first commit, the Host header check in isLocalControlRequest. the intent is right, a proxy connecting from 127.0.0.1 should not be trusted, but requiring a localhost Host also locks out a browser on the machine itself reaching lerd by the hostname, which on Debian and Ubuntu resolves to 127.0.1.1, and there is no credential that helps in that state. it now keys off X-Forwarded-For and friends instead, which is what a proxy actually adds, so Tailscale Serve still faces the auth gate and the local user keeps getting in.

could you update the description when you get a chance, the line about authenticated remote sessions receiving the same authority as local ones is no longer what the branch does. I tested all of this on an Ubuntu 26.04 guest, services reachable and not reachable both ways, the toggle in both directions, and the interrupted toggle case.

[381181295]

thanks, no issue with you pushing the fixes, both make sense. i'll update the PR description