在linux ubuntu 系统下，宿主机里看不到监听端口，但容器访问正常

现象：

root@bwoil:/data/redis# ls

conf data docker-compose.yaml redis.7.0.7.tgz

root@bwoil:/data/redis# nerdctl compose ps

NAME IMAGE COMMAND SERVICE STATUS PORTS

redis docker.io/library/redis:7.0.7 "redis-server /usr/l…" redis running 0.0.0.0:6379->6379/tcp

root@bwoil:/data/redis# more docker-compose.yaml

version: '3'

services:

redis:

hostname: redis

image: redis:7.0.7

container_name: redis

privileged: true

ports:

- 6379:6379

sysctls:

- net.core.somaxconn=1024

volumes:

- ./data:/data

- ./conf:/usr/local/etc/redis

- /etc/localtime:/etc/localtime:ro

entrypoint: redis-server /usr/local/etc/redis/redis.conf

restart: always

mem_limit: 4g

networks:

- meta

networks:

meta:

external: true

root@bwoil:/data/redis# netstat -ntpl |grep 6379

root@bwoil:/data/redis# ss |grep 6379

root@bwoil:/data/redis# sudo lsof -iTCP:6379 -sTCP:LISTEN

root@bwoil:/data/redis#

为什么呢？

查看防火墙规则：

root@bwoil:/data/redis# sudo iptables -L -n |grep 6379

root@bwoil:/data/redis# iptables -nvL|grep 6379

root@bwoil:/data/redis# sudo iptables -t nat -L -n |grep 6379

CNI-HOSTPORT-SETMARK tcp -- 10.4.2.0/24 0.0.0.0/0 tcp dpt:6379

CNI-HOSTPORT-SETMARK tcp -- 127.0.0.1 0.0.0.0/0 tcp dpt:6379

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6379 to:10.4.2.159:6379

CNI-DN-635091dd85894072ba7c2 tcp -- 0.0.0.0/0 0.0.0.0/0 /* dnat name: "meta" id: "k8s.io-5af4d10ddad658ac61103431f71ec0407007b4bac055902820f1ce940a3be89b" */ multiport dports 6379

CNI-HOSTPORT-SETMARK tcp -- 10.4.2.0/24 0.0.0.0/0 tcp dpt:6379

这条规则用于标记来自特定子网10.4.2.0/24的流量，以便后续的处理

CNI-HOSTPORT-SETMARK tcp -- 127.0.0.1 0.0.0.0/0 tcp dpt:6379

这条规则标记来自本机的6379端口的流量

DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6379 to:10.4.2.159:6379

这条规则将所有发往6379端口的流量转发到IP地址为10.4.2.159的主机的6379端口。这是典型的DNAT（目的地址转换）规则，常用于将外部流量转发到内部服务

CNI-DN-635091dd85894072ba7c2 tcp -- 0.0.0.0/0 0.0.0.0/0 /* dnat name: "meta" id: "k8s.io-5af4d10ddad658ac61103431f71ec0407007b4bac055902820f1ce940a3be89b" */ multiport dports 6379

这条规则是一个注释规则，表示它是由Kubernetes网络插件创建的，可能用于将流量转发到多个6379端口的服务。注释中包含了元数据，可能用于追踪或管理

如果iptables 中有DNAT 规则将数据量转发到容器，所以在宿主机里执行netstat /ss 才导致看不到对应的端口

在宿主机上执行 netstat 或 ss 命令时看不到容器端口的原因，确实与 iptables 中的 DNAT 规则有关

网络流量处理流程

1. 外部请求到达宿主机： 当外部请求（如访问6379端口）到达宿主机时，数据包首先到达网络接口。
2. 内核处理： 数据包进入Linux内核，经过网络协议栈的不同层次（链路层、网络层和传输层）。
3. iptables 规则匹配： 数据包在到达应用层之前，会经过 iptables 的规则匹配。iptables 是在内核空间中管理网络流量的工具，使用 netfilter 框架。 如果存在 DNAT 规则（如将6379端口的流量转发到容器的6379端口），内核会将流量的目标地址修改为容器的IP地址。
4. 数据包转发： 修改后的数据包被转发到目标容器的网络命名空间。容器内部的服务（如Redis）会接收这个流量。 容器内部处理： 容器内部的服务处理请求并生成响应。响应数据包会通过宿主机的网络栈返回。

为什么 netstat 或 ss 无法查看端口

• 网络命名空间隔离： 容器使用网络命名空间来隔离网络环境，因此在宿主机上执行 netstat 或 ss 命令时，无法看到容器内部的端口状态。容器的网络栈与宿主机的网络栈是分开的
• DNAT 规则的影响：由于有 DNAT 规则将流量转发到容器，宿主机的6379端口实际上并不直接监听来自外部的流量。即使在宿主机上有流量通过6379端口，netstat 和 ss 也不会显示这个端口，因为它的流量已经被重定向到容器。
• 流量处理顺序：iptables 规则在数据包到达应用层之前处理数据包，因此它们的匹配和处理优先于 netstat 和 ss 的查询。这意味着，如果数据包在 iptables 规则中被处理或修改，宿主机的网络状态将无法反映出容器的端口状态

在宿主机上执行 netstat 或 ss 时无法查看到容器的6379端口，是因为：

1. 容器和宿主机的网络命名空间隔离，导致宿主机无法直接查看容器内部的端口状态。
2. DNAT 规则的作用，使得流量在到达容器之前被修改和转发，宿主机上6379端口的流量并不直接与宿主机的网络状态相对应。

要查看容器内部的端口状态，您需要进入容器内部执行相应的命令