relay: bind the host LAN IP, admit the podman bridge subnet only

169.254.1.2 is not a local address on this host (netavark runs its
bridges in aardvark-dns' netns), so the relay cannot bind it — and a
loopback bind refuses container traffic. Probe-socket proof: a host
socket on 192.168.0.143:18094 answers the container's 169.254.1.2:18094
dial while the LAN IP refuses from the container. The relay binds
192.168.0.143:18093 and the deployer installs an iptables INPUT pair
(ACCEPT 10.89.0.0/16, DROP rest) so the unauthenticated endpoint stays
off the LAN.
This commit is contained in:
Frank
2026-09-17 13:52:20 -07:00
parent 8f747a2104
commit f73fd43027
9 changed files with 52 additions and 33 deletions
+3 -2
View File
@@ -2,8 +2,9 @@
# Deployed to /opt/alertmanager/config/alertmanager.yml on Dankclaw.
#
# The one delivery path is Signal. The webhook lands on the host-side
# signal-relay (a systemd user unit listening on 169.254.1.2:18093, the
# host.containers.internal endpoint), which
# signal-relay (a systemd user unit listening on 192.168.0.143:18093, the
# host LAN IP — the address the container's host.containers.internal dial
# lands on), which
# formats the group and hands it to signal-cli under Frank's existing
# account. There is deliberately no second receiver: a duplicate channel is
# how an alert starts arriving twice and getting muted everywhere.
+2 -2
View File
@@ -14,8 +14,8 @@ rule_files:
# The delivery half. Alertmanager runs on the same dankclaw_default network,
# so it is addressed by container name, like grafana and loki below. Its
# single receiver webhooks the host-side signal-relay (169.254.1.2:18093,
# the host.containers.internal endpoint).
# single receiver webhooks the host-side signal-relay (192.168.0.143:18093,
# reached from the container as host.containers.internal).
alerting:
alertmanagers:
- static_configs: