Linux ip netns exec 找不到接口时先检查哪个命名空间

在 ip netns exec 里找不到接口时，第一件事不是重复创建网卡，而是确认你查看的是哪个网络命名空间。网络设备、路由表和端口都属于各自的 network namespace；宿主机能看到的接口，进入 blue 后未必还在同一个视图里。

先确认 ip netns exec 进入的是哪个命名空间

ip netns exec NAME command 的 NAME 是命名的网络命名空间，不是接口名。命名空间通常通过 /run/netns/NAME（有些系统显示为 /var/run/netns/NAME）被打开，因此名称拼错、命名空间尚未创建，都会让后面的接口排查失去意义。

# 先列出系统当前登记的命名空间，确认目标名称
ip netns list

# 在 blue 命名空间中列出简洁接口清单
ip netns exec blue ip -br link

如果第二条命令只显示 lo，这只能说明 blue 的接口视图里目前只有回环设备；不能据此断定宿主机没有 eth0。如果出现 Cannot open network namespace，先修正名称或创建/挂载对应的命名空间。

用 netns inode 排除“看似切换、实际看错”的情况

网络命名空间的名字只是入口，进程实际绑定的是内核 namespace 对象。排查时可以读取当前 shell 的网络命名空间 inode，再读取 ip netns exec 内部 shell 的 inode。两个数字不同是正常的；关键是目标命令是否稳定落在你预期的那个对象上。

# 查看当前 shell 所在的网络命名空间身份
readlink /proc/$$/ns/net

# 在目标命名空间中读取另一个 shell 的身份，避免混淆当前目录或接口名
ip netns exec blue sh -c 'readlink /proc/$$/ns/net'

输出通常形如 net:[4026531993]。不要只盯着数字大小，应该把它当作对象标识：如果每次执行 blue 都得到同一个 inode，说明入口稳定；如果脚本里混用了容器 PID、nsenter 和命名 namespace，则要回到创建和挂载过程检查对象是否一致。

接口归属、接口名称和链路状态要分开查

确认 namespace 后，再检查接口本身。接口名称只在所属 namespace 内有意义；一个常见场景是 veth 一端被移动到了 blue，另一端仍留在 default namespace。此时宿主机看到 veth-host，目标命名空间看到 veth-blue，两边不会各自显示完整的同名设备。

# 在目标 namespace 内按设备名查找，找不到时不会误看宿主视图
ip netns exec blue ip link show dev eth0

# 回到当前 namespace 查看另一侧，帮助判断 veth 是否被移动
ip -br link

如果目标侧确实有 eth0，但它是 DOWN，问题就从“接口在哪里”变成“链路是否配置完成”。反过来，如果目标侧没有 eth0，不要先执行启用命令；先确认创建 veth 时使用的名称和移动动作，避免在错误的 namespace 中再造一套设备。

一个可复用的最小检查顺序

实际排障可以固定成四个判断：名称是否存在，exec 是否进入目标对象，接口是否属于目标 namespace，接口是否只是处于 DOWN。前两项回答“我在哪里”，第三项回答“设备在哪里”，最后一项才回答“设备能不能工作”。顺序反过来，很容易在错误的视图里反复执行 ip link set。

对 veth 场景，再补看两端名称和对端关系；对容器场景，还要确认容器运行时是否在脚本之后重新创建了 namespace。命名空间被删除后，原来的名字和 inode 也不能继续当作永久标识。

相关问题

为什么宿主机能看到接口，ip netns exec 里却没有？

因为接口属于某一个 network namespace。它可能仍在 default namespace，也可能已经被移动到另一个命名空间；分别运行 ip -br link 对比即可。

ip -n blue 和 ip netns exec blue 有什么区别？

对直接调用 ip 子命令的场景，ip -n blue 是切换到指定 namespace 的简写；复杂命令或需要让普通程序继承该网络视图时，使用 ip netns exec blue command 更直观。

接口显示 DOWN 就代表它不存在吗？

不是。DOWN 表示接口对象已经找到但链路状态未启用；先确认地址、路由和 veth 对端，再按场景启用它。