登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

Linux namespace 怎样查看进程所在网络空间

来源:17golang原创

时间:2026-10-23 10:16:42 240浏览 收藏

排查容器或隔离服务的网络问题时,先别急着看宿主机的网卡。一个进程真正使用哪套路由、端口和网络设备,取决于它所在的 network namespace。最稳妥的入口是读取 /proc/PID/ns/net:它会给出类似 net:[4026531993] 的命名空间标识;再根据需要用 lsns 展开清单,或用 nsenter 临时切换到目标进程的网络视角。

这套检查应当分成两层:先做无副作用的身份判断,再做只读的网卡和路由观察。只有确实需要时才进入目标命名空间,避免把排障权限扩大成网络配置权限。

先界定要保护的网络资产

Linux 的 network namespace 会隔离网络设备、IPv4/IPv6 协议栈、路由表、防火墙规则、端口以及 /proc/net 等网络视图。也就是说,同一台机器上的两个进程,即使 PID 都能在宿主机看到,它们看到的 ip addr 和 ip route 也可能完全不同。

这也是排障时最容易出现的误判:在宿主机执行 ip route 只能回答“当前 shell 所在空间有什么路由”,不能直接回答“目标进程使用什么路由”。先确认 namespace,再决定从哪个视角取证。

进程 PID、proc namespace 链接和 network namespace 网络资产之间的静态关系说明图
图1:进程身份、/proc/PID/ns/net 标识与网络资产边界的静态说明图;这是结构图,不是终端截图或运行证据。

用 /proc/PID/ns/net 判断进程属于哪个空间

每个进程都有自己的 namespace 链接目录。读取其中的 net 项,可以得到内核为该网络空间展示的标识。两个进程的 readlink 结果相同,通常说明它们位于同一个 network namespace;结果不同,则说明它们的网络视角已经隔离。

#!/usr/bin/env bash
# 只读取 namespace 链接,不修改目标进程或网络配置
pid="${1:?请传入要检查的 PID}"
ns_path="/proc/${pid}/ns/net"

# 进程退出或权限不足时,先给出明确错误
if [[ ! -r "$ns_path" ]]; then
  printf '无法读取 %s,请确认 PID 存在且当前用户可见\n' "$ns_path" >&2
  exit 1
fi

# 输出形如 net:[4026531993] 的网络空间标识
readlink "$ns_path"

# 比较两个进程时,比较它们各自的 readlink 结果
# readlink "/proc/${pid_a}/ns/net"
# readlink "/proc/${pid_b}/ns/net"

这里的数字不是容器名,也不是网卡名,而是 namespace 链接显示的标识。它适合做第一层判断:例如先记录服务 PID 的标识,再与宿主机 shell 的 /proc/$$/ns/net 比较。不要把固定数字写进监控规则;进程和命名空间生命周期变化后,下一次创建的标识可能不同。

用 lsns 和 ip netns 解释清单与名称

readlink 解决“是不是同一个空间”,但不一定告诉你这个空间是否由 ip netns 注册了名称。安装了 util-linux 时,lsns 可以从 namespace 清单角度查看目标 PID;而 ip netns identify 只适合查找 iproute2 管理的命名空间名称,两者用途不要混为一谈。

# 只列出与目标 PID 相关的 network namespace 记录
lsns -t net -p "$pid"

# 只查询 iproute2 已注册的命名空间名称;没有名称不等于没有 namespace
ip netns identify "$pid"

# 查看当前主机上可见的命名空间和关联进程摘要
lsns -t net
命令回答的问题边界
readlink /proc/PID/ns/net目标进程的网络空间标识是什么信息简洁,依赖 /proc 可见性
lsns -t net -p PID该 PID 对应哪条 network namespace 记录依赖 util-linux,展示的是系统清单
ip netns identify PID是否存在 iproute2 注册的名称未命名空间可能返回空

对于安全审计,建议把 PID、采集时间、readlink 结果和命令执行身份一起记录。PID 可能被复用,单独保存一个旧 PID 不能证明它仍然指向原来的进程。

用 nsenter 读取进程实际看到的网络状态

确认标识后,如果问题是“进程为什么连不上”,才需要从目标空间读取地址和路由。nsenter -t PID -n 会让后续命令使用目标进程的 network namespace;下面的例子只调用 ip -br addr 和 ip route 做只读观察。

# 目标 PID 只作为 namespace 入口,不在目标空间写入网络配置
target_pid="${1:?请传入要观察的 PID}"

# 从目标进程的网络视角查看接口和地址
sudo nsenter -t "$target_pid" -n -- ip -br addr

# 从同一个网络视角查看 IPv4 路由
sudo nsenter -t "$target_pid" -n -- ip route

# 需要 IPv6 时单独查看,避免把两类路由混在判断里
sudo nsenter -t "$target_pid" -n -- ip -6 route

这一步通常需要足够的权限;如果目标进程不可见、已经退出,或者当前账号没有进入该 namespace 的能力,nsenter 会失败。此时先回到 readlink 和 lsns 的只读检查,不要为了“看一眼路由”直接修改目标空间的权限或网络配置。

readlink、lsns、nsenter 与目标网络空间内网卡和路由视角之间的静态关系说明图
图2:只读身份判断、命名空间清单与 nsenter 网络视角的边界说明图;这是静态说明图,不是实际命令输出。

按风险分级保留排查证据

可以把检查分成三个等级。第一层是 readlink:只读链接,适合快速确认和比较。第二层是 lsns、ip netns identify:补充系统清单和名称,适合把标识翻译成运维记录。第三层是 nsenter 加只读 ip:得到进程真实网络视角,但权限要求更高,也更接近敏感排障动作。

最终记录至少包含目标 PID、进程启动时间或其他稳定身份线索、namespace 标识、采集命令和权限上下文。若 PID 已经退出,旧的 /proc/PID 路径不能继续当作证据;若两个进程的 namespace 标识相同,也只能说明它们共享网络空间,不能据此推断应用一定能互相连接,端口监听、路由和防火墙仍需在该空间内分别观察。

相关问题

为什么宿主机能看到网卡,进程却看不到?最常见原因是进程位于不同的 network namespace;先比较两个进程的 /proc/PID/ns/net 标识。

ip netns identify 没有输出,是不是没有网络空间?不是。它只查 iproute2 注册的名称;未命名的网络空间仍然可以通过 /proc/PID/ns/net 和 lsns 判断。

nsenter 进入后为什么还看不到预期路由?先确认目标 PID 没有退出或被复用,再确认使用了 -n 网络选项,并分别查看 IPv4、IPv6、接口地址和防火墙规则。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>