主页 / user-288012

TheDiveO's questions

Martin Hope
TheDiveO
Asked: 2022-06-04 05:54:31 +0800 CST
  • 1

我只想将发往单个 IP 和 UDP 端口的非常有限的数据包流量镜像到同一个 IP 但第二个端口。我已经锁定在https://superuser.com/questions/1593995/iptables-nftables-forward-udp-data-to-multiple-targets但似乎 nftable 的 dup 语句只允许复制到另一个 IP 但不一样IP和不同的端口。

例如，到 127.0.0.1 端口 123 的流量应该复制到 127.0.0.1 端口 456。由于这是唯一的单一复制，因此原始端口号丢失没有任何问题。现在我想知道这种复制是否可能，因为 127.0.0.1 不是“排水”/传出接口，而是复制的最终目的地。有没有办法将它与 DNAT 结合起来？

除了将 eBPF 探测附加到带有传入 UDP 流量的 netdev 之外，还有其他可用的机制吗？

nftables
Martin Hope
TheDiveO
Asked: 2018-11-28 06:17:05 +0800 CST
  • 1

当使用 RTLINK 从（网络命名空间的）Linux 内核查询可用的 IP 路由时，我注意到在一个测试系统上 RTLINK 返回一个没有RTA_OIF属性的路由，也就是说，没有指定传出网络接口。

不幸的是，我不知道如何使用该ip route add命令重现这种情况（用于测试），并且到目前为止，我所接触的任何人都无法解释最初创建此路由的“什么”，而没有任何传出网络接口的指示。通过查看 Linux 内核源代码，我注意到传出网络接口属性实际上是可选的。但是，我的尝试ip route add总是以内核自动添加的传出网络接口或无法访问而告终：

ip route add 1.1.1.1/32 via 1.1.1.2给RTNETLINK answers: Network is unreachable.

下一次（失败）尝试：

ip addr add 1.1.1.2/32 dev ens33
ip route add 1.1.1.1/32 via 1.1.1.2
ip route show

...然后给出1.1.1.1 via 1.1.1.2 dev ens33，内核自动插入了一个合适的传出网络接口（因此RTA_OIF存在，即使我一开始没有指定它）。

搜索“没有传出接口的 linux ip route”或类似的东西不会给我任何可用的结果——除非我在这里忽略了一些重要的东西。

那么，如何创建一个（测试）案例，其中我有一个没有传出网络接口的 IP 路由？我在这里俯瞰什么？

linux routing
Martin Hope
TheDiveO
Asked: 2018-07-19 06:59:31 +0800 CST
  • 7

网络命名空间 (7)的 Linux 手册页说：

网络命名空间提供与网络相关的系统资源的隔离：[...]、/sys/class/net 目录、[...]。

然而，简单地切换到不同的网络命名空间似乎并没有改变/sys/class/net（见下文如何重现）的内容。我只是误以为setns()进入网络名称空间已经足够了吗？是否总是需要重新挂载/sys才能正确/sys/class/net匹配当前加入的网络命名空间？还是我在这里错过了其他东西？

重现的例子

拿一个 *ubuntu 系统，找到 rtkit-daemon 的 PID，进入 daemon 的网络命名空间，显示它的网络接口，然后检查/sys/class/net：

$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# ls /sys/class/net
docker0  enp3s0  lo  lxcbr0  ...

请注意，虽然ip link show正确只显示lo,/sys/class/net显示在“根”网络命名空间（和“根”挂载命名空间）中可见的所有网络接口。

在rtkit-daemon也进入它的挂载命名空间的情况下没有区别：sudo nsenter -t $PID -n -m然后ls /sys/class/net仍然显示网络命名空间中不存在的网络接口。

“使固定”

感谢@Danila Kiver解释了 Linux 内核幕后的真实情况。sysfs 在加入正确的网络命名空间时重新安装将显示正确的条目/sys/class/net：

$ PID=`sudo lsns -t net -n -o PID,COMMAND | grep rtkit-daemon | cut -d ' ' -f 2`
$ sudo nsenter -t $PID -n
# MNT=`mktemp -d`
# mount -t sysfs none $MNT
# ls $MNT/class/net/
lo
# umount $MNT
# rmdir $MNT
# exit

所以这现在产生了正确的结果/sys/class/net。

linux namespace
Martin Hope
TheDiveO
Asked: 2018-06-27 21:47:23 +0800 CST
  • 2

我想检测网络接口是“物理”还是“虚拟”，其中“物理”表示接口连接了硬件，即使该“硬件”是由管理程序虚拟化的。“虚拟”则意味着它是 Linux 内核元素之一，例如网桥、veth、macvlan 等。

我知道，通过使用/sys/class/net/[nif]/...我可以跟踪设备链接，从而根据是否包含“虚拟”子目录的设备路径区分（虚拟）物理和“真实”（原文如此！）虚拟网络接口。但是，在处理网络名称空间时，这需要正确重新安装sysfs才能看到正确的/sys/class/net/...条目。因此，仅依靠 RTNETLINK 数据的更简单的方法可能更合适。

当使用 RTNETLINK 发现可用的网络接口时，是否有一些属性/属性可以让我区分而无需检查/sys/class/net/[nif]？

linux networking
Martin Hope
TheDiveO
Asked: 2018-05-13 02:00:57 +0800 CST
  • 3

在一个程序中，我通过扫描（符号）链接/proc/pid/来枚举网络名称空间。ns/net该程序在主机本身的“根”命名空间（原始 init）内运行。通常，我需要以 root 身份运行扫描仪部分，否则我只能有限地访问其他进程的/proc/pid/信息。如果可能，我想避免以 root 身份运行扫描程序，并且我想避免放弃特权的麻烦。

我需要为我的扫描程序设置哪个 Linux 功能，以便它可以由非 root 用户运行，并且仍然可以看到完整的/proc/pid/树并读取网络命名空间链接？

linux proc
Martin Hope
TheDiveO
Asked: 2018-05-05 13:26:32 +0800 CST
  • 2

是否可以明确地识别给定的网络接口，例如eth1，实际上是一个类型的veth网络接口？请注意，在容器中，它们的网络接口名称通常以eth*代替开头，veth*并且无法确定eth集合中没有实数。这可以通过 检测/sys/class/net吗？

我的印象是iflinkin 元素/sys/class/net/...并没有明确地标识veth网络接口，而是在其他情况下也使用。如果无法使用/sys/class/net/...文件系统解决我的问题，是否有一个套接字调用可以为我提供此信息，最好在 Python 中使用？

networking veth
Martin Hope
TheDiveO
Asked: 2018-05-05 12:41:43 +0800 CST
  • 14

任务

我需要明确且没有“整体”猜测的情况下在另一个网络命名空间中找到veth 端的对等网络接口。

理论 。/。现实

尽管有很多文档和关于 SO 的答案都假设网络接口的 ifindex 索引在网络名称空间中每个主机都是全局唯一的，但这在许多情况下并不成立：ifindex/iflink 是模棱两可的。甚至环回也已经表明相反的情况，在任何网络命名空间中的 ifindex 都是 1。此外，根据容器环境，ifindex数字会在不同的命名空间中重用。这使得跟踪 veth 布线成为一场噩梦，尤其是有很多容器和一个带有 veth 对等点的主机桥都以 @if3 左右结尾......

示例：link-netnsid是0

启动一个 Docker 容器实例，只是为了获得一个veth从主机网络命名空间连接到新容器网络命名空间的新对......

$ sudo docker run -it debian /bin/bash

现在，在主机网络命名空间列表中的网络接口（我忽略了那些对这个问题不感兴趣的接口）：

$ ip链接显示
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    链接/环回 00:00:00:00:00:00 brd 00:00:00:00:00:00
...
4：docker0:mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    链接/以太 02:42:34:23:81:f0 brd ff:ff:ff:ff:ff:ff
...
16: vethfc8d91e@if15: mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    链接/以太 da:4c:f7:50:09:e2 brd ff:ff:ff:ff:ff:ff 链接-netnsid 0

如您所见，虽然iflink是明确的，但link-netnsid是 0，尽管对等端位于不同的网络命名空间中。

作为参考，请检查容器的未命名网络命名空间中的 netnsid：

$ sudo lsns -t 网络
        NS 类型 NPROCS PID 用户命令
...
...
4026532469 网络 1 29616 根 /bin/bash

$ sudo nsenter -t 29616 -n ip 链接显示
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    链接/环回 00:00:00:00:00:00 brd 00:00:00:00:00:00
15: eth0@if16: mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    链接/以太 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff 链接-netnsid 0

因此，对于两个 veth 端ip link show（和 RTNETLINK fwif）都告诉我们它们与 netnsid 0 在同一个网络命名空间中。在 link-netnsids 是本地而不是全局的假设下，这是错误的或正确的。我找不到任何文档来明确说明 link-netnsids 应该具有的范围。

/sys/class/net/...不去救援？

我查看了 /sys/class/net/ if /... 但只能找到 ifindex 和 iflink 元素；这些都有据可查。“ip link show”似乎也只以（in）著名的“@if#”符号的形式显示对等 ifindex。还是我错过了一些额外的网络命名空间元素？

底线/问题

是否有任何系统调用允许检索 veth 对的对等端丢失的网络命名空间信息？

networking network-namespaces