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:
1 parent
8f747a2104
commit
f73fd43027
9 files changed
+52
-33
No files matched your search
@@ -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.
|
||||
|
||||
Reference in new issue
Block a user