Fix CIDR whitelist entries being discarded on hot reload

[Robbie1977]

The bug

A CIDR range added to /logs/whitelist.txt works until the next hot reload, then silently stops:

Ignoring invalid whitelisted IP entry in /logs/whitelist.txt: 10.42.0.0/16
Ignoring invalid whitelisted IP entry in /logs/whitelist.txt: 129.215.0.0/16

Root cause

The list compiler had two copies. docker-entrypoint.sh compiles the lists once at container start; health-monitor.sh recompiles them on every change to blocked.txt/whitelist.txt, then reloads nginx.

When the entrypoint learned to route CIDR ranges into a geo map (273c827, 1ae044e), the monitor's private copy of the compiler did not. So:

• a range accepted at boot is discarded by the first hot reload, and
• because the monitor never writes whitelisted-cidrs.map at all, a range added after boot never takes effect without restarting the container.

That is why both 129.215.0.0/16 (a VPN pool) and 10.42.0.0/16 (the Rancher/Canal pod network the VFBquery warmup tool runs from) were being rejected.

The fix

Both scripts now source a shared ip-maps.sh, so they cannot drift again. Drift was the bug, so a third copy of the function would have been the wrong shape of fix.

The test suite includes static wiring assertions that grep both callers and fail if either stops sourcing the library, reintroduces a private copy of the compiler, or stops passing the CIDR map. Unit tests alone would not have caught the original bug — each copy of the compiler was individually correct.

Second defect, same asymmetry

The auto-block exemption used an exact string match (is_ip_listed), so an address inside a whitelisted CIDR could trip a probe pattern and get auto-blocked despite the operator having whitelisted its whole network — after which the two map files disagree about the same address. It is now range-aware (is_ip_whitelisted).

IPv6 ranges are not matched arithmetically (no bitwise ops in BusyBox awk, and :: compression makes textual prefix matching unsafe). Instead, if any IPv6 range is whitelisted at all, no IPv6 address is auto-blocked — erring towards leaving a scanner unblocked rather than locking out a trusted host, which is the right way round here: the probe filter still returns 403 either way, auto-blocking only saves the work of matching it.

BusyBox finding

Range membership is computed by division rather than 2^(32-bits). BusyBox can be built without libm, and there ^ aborts with Math support is not compiled in — which made every in-range address read as out-of-range. This was caught only by running the suite under the runtime image's own awk; it would have shipped silently and failed only in production.

Tests

test/ip-maps-test.sh, 46 checks: line classification, whitelist compilation (dedupe, sort, CRLF, uppercase hex, comments, junk, and an explicit assertion that 129.215.0.0/16 lands in the geo map and is not reported invalid), blocklist compilation, 15 IPv4 range-membership cases including /0, /32 and both boundaries, auto-block exemption, and the wiring assertions.

Run at image build time, so a regression fails docker build rather than surfacing hours later as a cache bypass that quietly doesn't happen. Gating on the build rather than a new workflow job was deliberate — CI already runs docker build.

Verified passing under BusyBox ash with a libm-less BusyBox awk, dash, bash in POSIX mode, and BusyBox ash with system awk. Also verified end-to-end against the real health-monitor.sh: appending the two ranges to a live whitelist now produces a whitelisted-cidrs.map containing both, with no "Ignoring invalid" warning.

README

Documents that the whitelist accepts ranges and why that matters (a VPN or pod network reassigned per session can be whitelisted once), that the blocklist deliberately does not, that rejected lines are reported on the container log, and — for the first time — the X-Force-Refresh header, which previously existed only as a code comment. Includes the x-cache-status: BYPASS vs HIT check for confirming a bypass actually happened.