Dockerized Zabbix：服务器无法通过 IP 连接到代理
Dockerized Zabbix: Server Can't Connect to the Agents by IP
问题：
我正在尝试使用 Zabbix 的 Docker-Compose 存储库 HERE.
在 Ubuntu 20.04 LTS 上配置完全容器化的 Zabbix 6.0 版监控系统
我用来启动 Zabbix 服务器和 Zabbix 代理的命令是：
docker-compose -f docker-compose_v3_ubuntu_pgsql_latest.yaml --profile all up -d
虽然Agent在故障状态下启动并显示“红色”状态，但当我更改其IP地址时FROM 127.0.0.1 TO 172.16.239.6（默认 IP Docker-Compose 分配给它）Zabbix 服务器现在可以成功连接并建立监控。 HOWEVER：Zabbix 服务器无法连接到 REMOTE 主机上的任何其他 Dockerized Zabbix 代理，这些主机由 docker run 命令：
docker run --add-host=zabbix-server:172.16.238.3 -p 10050:10050 -d --privileged --name DockerHost3-zabbix-agent -e ZBX_SERVER_HOST="zabbix-server" -e ZBX_PASSIVE_ALLOW="true" zabbix/zabbix-agent:ubuntu-6.0-latest
注意：我查看了其他 Stack 组 post 这个问题，但是 Whosebug 似乎是 -对这些 Docker/Zabbix 个问题进行分组，此类问题超过 30 个。
疑难解答：
对比分析：
代理配置：
与 Zabbix 服务器在同一主机上的工作（“绿色”）代理与不同主机上的代理显示“红色”状态（不是 contactable 通过 Zabbix 服务器）的比较分析使用以下命令显示配置具有奇偶校验。
docker exec -u root -it (ID of agent container returned from "docker ps") bash
然后执行：
grep -Ev ^'(#|$)' /etc/zabbix/zabbix_agentd.conf
端口：
正确的端口在“红色”代理上显示为打开，在“绿色”代理上显示为打开 运行 在与命令输出的 Zabbix 服务器相同的主机上：
ss -luntu
注意：此命令是从主机发出的，而不是代理的 Docker 容器。
防火墙：
使用以下命令从主机（非容器）查看 iptables 规则没有发现任何问题：
iptables -nvx -L --line-numbers
但是为了排除防火墙，我仍然在 Zabbix 服务器和用于测试的“红色”状态的代理上允许 FORWARD table 中 iptables 中的所有内容。
我还允许 MikroTik GW 路由器上的所有内容将 Zabbix 服务器连接到不同的物理主机 运行 Zabbix 代理。
路由：
Zabbix 服务器可以 ping 远程代理接口，证明存在到代理的路由。
AppArmor:
我还停止了 AppArmor 以将其排除在外：
sudo systemctl stop apparmor
sudo systemctl status apparmor
总结：
所以一切都是开放的，Zabbix 服务器可以路由到代理，并且“红色”代理的配置与位于 Zabbix 服务器本身的同一主机上的“绿色”代理的配置相同.
我已经在生产环境中成功安装了非容器化的 Zabbix，所以我对 Zabbix 很熟悉。
为什么容器化的Zabbix Server无法连接到不同主机上的容器化Zabbix Agent？
简答：
Zabbix 配置没有任何问题；这是一个 Docker-induced 问题。
docker logs <hostname of Zabbix server> 显示 Zabbix SERVER 上似乎发生了 NAT，而且确实发生了。
Docker 正在修改主机 运行 上的 iptables NAT table 宁 Zabbix Server 容器导致 Zabbix Server 的源地址呈现为物理主机本身的 IP，而不是 Docker-Compose 分配的 IP 地址 172.16.238.3.
因此，代理不期望此地址并拒绝了连接。我对 Docker 化应用程序的体验是，它们 大部分 擅长修改 IP tables 以创建正确的连接，但在这种特殊情况下不是这样 ;-) .
我现在通过在主机（不是容器）上执行以下命令来查看 NAT table：
iptables -t nat -nvx -L --line-numbers
这表明 Docker 正在，呃，“ 有帮助” 和 NAT'ing Zabbix 服务器的流量
我按规则编号删除了违规规则：
iptables -t nat -D <chain> <rule #>
之后，Zabbix 服务器的 IP 地址现在已正确呈现给现在接受连接的代理，并且它们的状态变为“绿色”。
如果您执行：
，问题会重现
docker-compose -f docker-compose -f docker-compose_v3_ubuntu_pgsql_latest.yaml down
然后 运行 up 命令再次启动容器你会看到有问题的 iptables 规则它恢复到主机的 NAT table 运行使 Zabbix 服务器的容器中断与代理的连接。
更长的答案：
以下是识别和解决 Zabbix 服务器将其流量从主机 IP 转移到 NAT 问题所需的步骤：
确定 Zabbix Server 容器的主机是否为 NAT：
我们需要查看 Zabbix 服务器容器的 IP 如何呈现给代理，因此我们必须获取 Zabbix AGENT 的容器 ID 以查看其日志:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b2fcf38d601f zabbix/zabbix-agent:ubuntu-6.0-latest "/usr/bin/tini -- /u…" 5 hours ago Up 5 hours 0.0.0.0:10050->10050/tcp, :::10050->10050/tcp DockerHost3-zabbix-agent
接下来，将代理的容器 ID 提供给 docker logs 命令：
docker logs b2fcf38d601f
然后查看日志输出中被拒绝的 IP 地址以确定它是否不是 Zabbix 服务器的 IP：
81:20220328:000320.589 failed to accept an incoming connection: connection from "NAT'ed IP" rejected, allowed hosts: "zabbix-server"
您可以看到此错误这一事实证明没有路由或连接问题：连接正在通过，只是被应用程序拒绝，而不是防火墙。
如果 NAT'ing 成功，继续下一步
在 Zabbix SERVER 的主机上：
补救发生在 Zabbix 服务器的主机本身，而不是代理。这很好，因为我们可以在一个地方解决问题而不是很多地方。
在 Host 运行ning Zabbix Server 的容器上执行以下命令：
iptables -t nat -nvx -L --line-numbers
命令输出：
Chain POSTROUTING (policy ACCEPT 88551 packets, 6025269 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE all -- * !br-abeaa5aad213 192.168.24.128/28 0.0.0.0/0
2 73786 4427208 MASQUERADE all -- * !br-05094e8a67c0 172.16.238.0/24 0.0.0.0/0
Chain DOCKER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- br-abeaa5aad213 * 0.0.0.0/0 0.0.0.0/0
2 95 5700 RETURN all -- br-05094e8a67c0 * 0.0.0.0/0 0.0.0.0/0
我们可以看到“POSTROUTING”和“[的计数器正在递增=113=]" 链 - 都在各自的链中规则 #2。
这些规则明确匹配并生效。
删除 Zabbix 服务器容器 HOST 上的违规规则，该容器正在将其流量 NAT 到代理：
sudo iptables -t nat -D POSTROUTING 2
sudo iptables -t nat -D DOCKER 2
稍等片刻，代理现在应该变为“绿色”- 假设没有其他配置或防火墙问题。如果在应用修复后代理仍然是“红色”，那么请完成我在问题部分记录的故障排除步骤。
结论：
我已经测试并重新启动 Zabbix-server 容器不会重新创建已删除的规则。但再次请注意，docker-compose down 后跟 docker-compose up 将 重新创建已删除的规则并中断代理连接。
希望这可以节省其他人浪费的周期。我既是 Linux 又是网络工程师，这让我很头疼，所以如果您不是网络专家，这几乎不可能解决。
问题：
我正在尝试使用 Zabbix 的 Docker-Compose 存储库 HERE.
在 Ubuntu 20.04 LTS 上配置完全容器化的 Zabbix 6.0 版监控系统我用来启动 Zabbix 服务器和 Zabbix 代理的命令是：
docker-compose -f docker-compose_v3_ubuntu_pgsql_latest.yaml --profile all up -d
虽然Agent在故障状态下启动并显示“红色”状态，但当我更改其IP地址时FROM 127.0.0.1 TO 172.16.239.6（默认 IP Docker-Compose 分配给它）Zabbix 服务器现在可以成功连接并建立监控。 HOWEVER：Zabbix 服务器无法连接到 REMOTE 主机上的任何其他 Dockerized Zabbix 代理，这些主机由 docker run 命令：
docker run --add-host=zabbix-server:172.16.238.3 -p 10050:10050 -d --privileged --name DockerHost3-zabbix-agent -e ZBX_SERVER_HOST="zabbix-server" -e ZBX_PASSIVE_ALLOW="true" zabbix/zabbix-agent:ubuntu-6.0-latest
注意：我查看了其他 Stack 组 post 这个问题，但是 Whosebug 似乎是 -对这些 Docker/Zabbix 个问题进行分组，此类问题超过 30 个。
疑难解答：
对比分析：
代理配置：
与 Zabbix 服务器在同一主机上的工作（“绿色”）代理与不同主机上的代理显示“红色”状态（不是 contactable 通过 Zabbix 服务器）的比较分析使用以下命令显示配置具有奇偶校验。
docker exec -u root -it (ID of agent container returned from "docker ps") bash
然后执行：
grep -Ev ^'(#|$)' /etc/zabbix/zabbix_agentd.conf
端口：
正确的端口在“红色”代理上显示为打开，在“绿色”代理上显示为打开 运行 在与命令输出的 Zabbix 服务器相同的主机上：
ss -luntu
注意：此命令是从主机发出的，而不是代理的 Docker 容器。
防火墙：
使用以下命令从主机（非容器）查看 iptables 规则没有发现任何问题：
iptables -nvx -L --line-numbers
但是为了排除防火墙，我仍然在 Zabbix 服务器和用于测试的“红色”状态的代理上允许 FORWARD table 中 iptables 中的所有内容。
我还允许 MikroTik GW 路由器上的所有内容将 Zabbix 服务器连接到不同的物理主机 运行 Zabbix 代理。
路由：
Zabbix 服务器可以 ping 远程代理接口，证明存在到代理的路由。
AppArmor:
我还停止了 AppArmor 以将其排除在外：
sudo systemctl stop apparmor
sudo systemctl status apparmor
总结：
所以一切都是开放的，Zabbix 服务器可以路由到代理，并且“红色”代理的配置与位于 Zabbix 服务器本身的同一主机上的“绿色”代理的配置相同.
我已经在生产环境中成功安装了非容器化的 Zabbix，所以我对 Zabbix 很熟悉。
为什么容器化的Zabbix Server无法连接到不同主机上的容器化Zabbix Agent？
简答：
Zabbix 配置没有任何问题；这是一个 Docker-induced 问题。
docker logs <hostname of Zabbix server> 显示 Zabbix SERVER 上似乎发生了 NAT，而且确实发生了。
Docker 正在修改主机 运行 上的 iptables NAT table 宁 Zabbix Server 容器导致 Zabbix Server 的源地址呈现为物理主机本身的 IP，而不是 Docker-Compose 分配的 IP 地址 172.16.238.3.
因此，代理不期望此地址并拒绝了连接。我对 Docker 化应用程序的体验是，它们 大部分 擅长修改 IP tables 以创建正确的连接，但在这种特殊情况下不是这样 ;-) .
我现在通过在主机（不是容器）上执行以下命令来查看 NAT table：
iptables -t nat -nvx -L --line-numbers
这表明 Docker 正在，呃，“ 有帮助” 和 NAT'ing Zabbix 服务器的流量
我按规则编号删除了违规规则：
iptables -t nat -D <chain> <rule #>
之后，Zabbix 服务器的 IP 地址现在已正确呈现给现在接受连接的代理，并且它们的状态变为“绿色”。
如果您执行：
，问题会重现docker-compose -f docker-compose -f docker-compose_v3_ubuntu_pgsql_latest.yaml down
然后 运行 up 命令再次启动容器你会看到有问题的 iptables 规则它恢复到主机的 NAT table 运行使 Zabbix 服务器的容器中断与代理的连接。
更长的答案：
以下是识别和解决 Zabbix 服务器将其流量从主机 IP 转移到 NAT 问题所需的步骤：
确定 Zabbix Server 容器的主机是否为 NAT：
我们需要查看 Zabbix 服务器容器的 IP 如何呈现给代理，因此我们必须获取 Zabbix AGENT 的容器 ID 以查看其日志:
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b2fcf38d601f zabbix/zabbix-agent:ubuntu-6.0-latest "/usr/bin/tini -- /u…" 5 hours ago Up 5 hours 0.0.0.0:10050->10050/tcp, :::10050->10050/tcp DockerHost3-zabbix-agent
接下来，将代理的容器 ID 提供给 docker logs 命令：
docker logs b2fcf38d601f
然后查看日志输出中被拒绝的 IP 地址以确定它是否不是 Zabbix 服务器的 IP：
81:20220328:000320.589 failed to accept an incoming connection: connection from "NAT'ed IP" rejected, allowed hosts: "zabbix-server"
您可以看到此错误这一事实证明没有路由或连接问题：连接正在通过，只是被应用程序拒绝，而不是防火墙。
如果 NAT'ing 成功，继续下一步
在 Zabbix SERVER 的主机上：
补救发生在 Zabbix 服务器的主机本身，而不是代理。这很好，因为我们可以在一个地方解决问题而不是很多地方。
在 Host 运行ning Zabbix Server 的容器上执行以下命令：
iptables -t nat -nvx -L --line-numbers
命令输出：
Chain POSTROUTING (policy ACCEPT 88551 packets, 6025269 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 MASQUERADE all -- * !br-abeaa5aad213 192.168.24.128/28 0.0.0.0/0
2 73786 4427208 MASQUERADE all -- * !br-05094e8a67c0 172.16.238.0/24 0.0.0.0/0
Chain DOCKER (2 references)
num pkts bytes target prot opt in out source destination
1 0 0 RETURN all -- br-abeaa5aad213 * 0.0.0.0/0 0.0.0.0/0
2 95 5700 RETURN all -- br-05094e8a67c0 * 0.0.0.0/0 0.0.0.0/0
我们可以看到“POSTROUTING”和“[的计数器正在递增=113=]" 链 - 都在各自的链中规则 #2。 这些规则明确匹配并生效。
删除 Zabbix 服务器容器 HOST 上的违规规则，该容器正在将其流量 NAT 到代理：
sudo iptables -t nat -D POSTROUTING 2
sudo iptables -t nat -D DOCKER 2
稍等片刻，代理现在应该变为“绿色”- 假设没有其他配置或防火墙问题。如果在应用修复后代理仍然是“红色”，那么请完成我在问题部分记录的故障排除步骤。
结论：
我已经测试并重新启动 Zabbix-server 容器不会重新创建已删除的规则。但再次请注意，docker-compose down 后跟 docker-compose up 将 重新创建已删除的规则并中断代理连接。
希望这可以节省其他人浪费的周期。我既是 Linux 又是网络工程师，这让我很头疼，所以如果您不是网络专家，这几乎不可能解决。