Fix tailnet access to LAN-gated apps, and Caddy access logging

[mathewcsims]

Found while debugging docs.mathewcsims.uk being unreachable from an Android client on mobile data. Two separate latent faults, neither in this repo's configuration.

Tailnet access

A subnet route is a separate ACL destination from the tailnet IPs of the devices behind it. Babel advertised 10.0.1.0/24, the route was approved in the console, and the client had "use subnet routes" enabled — all three necessary, none sufficient, because no grant ever named the CIDR. Traffic was dropped by policy at the receiving node.

That is why every server-side check came back clean. Caddy's @lan matcher, the DigitalOcean and NextDNS records, the tailnet's own resolver and HedgeDoc itself were all verified correct and none of them was the problem.

The symptoms actively misdirect:

Path	Symptom	Why
With exit node	timeout	Tailscale keeps RFC1918 destinations off the exit path, so the packet leaves via the local interface
Without exit node	ERR_CONNECTION_REFUSED	browser falls back to the public A record, reaches Caddy from the internet, hits handle { abort }

Neither leaves a trace on the Pi — a full packet capture of the client's traffic showed no connection attempt toward the LAN address at all.

The grant itself is applied to the live tailnet already (verified present in babel's enforced packet filter, where the 10.x list was previously empty). This PR adds scripts/tailscale-acl.sh so the policy is managed the same way as everything else here: key used only inside a Python process via urllib so it never reaches argv, /acl/validate before applying, and If-Match so a concurrent console edit is a 412 rather than a silent clobber.

Caddy access logging

Caddy emits access logs only for site blocks carrying the log directive. The global log block configures the default logger's sink, which is not the same thing — so no request has ever been logged.

The consequence is that the caddy-abuse fail2ban jail has been watching a file it was never fed. Its lifetime counter stood at exactly 3: the one synthetic and two hand-fed lines used to verify it nine days ago, and nothing since.

Fixed with an (access_log) snippet imported by all 25 site blocks. Verified after reload: a probe with a unique path lands in logs/access.log, and fail2ban-regex matches the emitted format (1 matched, 0 missed).

Docs

SETUP.md's "Accessing LAN-only apps over Tailscale" said two things were required and claimed the arrangement was "confirmed working end-to-end". It now documents three, and records plainly that no LAN-gated app had ever been reachable from a genuinely off-LAN tailnet device. Testing from a device sitting on the physical LAN passes regardless, which is how it went unnoticed.

Verification

• ACL grant present in babel's tailscale debug netmap packet filter (was NONE)
• User confirmed docs.mathewcsims.uk loads over the tailnet
• Caddyfile passes caddy validate; applied with caddy reload, no downtime
• Access logging confirmed by probe; fail2ban-regex confirmed against the real emitted format
• tcpdump, installed on the Pi for the diagnosis, has been removed again

🤖 Generated with Claude Code