使用 tc over GRE Tunnel 的流量镜像只获取入口流量
Traffic mirroring with tc over GRE Tunnel only gets ingress Traffic
我正在尝试借助 tc
通过 GRE 隧道 tun0
从一个接口镜像 "all" 网络流量。 GRE-Tunnel 工作正常,我可以 ping 并通过它发送数据包,没有任何问题。我使用以下命令添加了 tc-qdisc
和 tc-filter
:
tc qdisc add dev ens5 ingress
tc filter add dev ens5 parent ffff: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0
和
tc qdisc add dev ens5 handle 1: root prio
tc filter add dev ens5 parent 1: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0
喜欢这个Tutorial
问题
问题是只有入口流量通过 GRE 隧道。当我通过接口 ens5
ping 另一台计算机时,我只能通过 tun0
接口获得 icmp echo replies
。
我做错了什么?
调试
ubuntu@switch:~$ tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:23:28.952197 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 1, length 64
10:23:29.954454 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 2, length 64
10:23:30.952864 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 3, length 64
10:23:31.953207 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 4, length 64
10:23:32.955350 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 5, length 64
10:23:33.957000 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 6, length 64
10:23:34.956313 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 7, length 64
我从未使用过 GRE-Tunnels,但根据您发布的教程 link,它与网桥接口有关?我目前还在网桥接口上使用 Linux 流量控制 (tc) - 在我的例子中,它是由 Docker 创建的网桥,我必须操纵流量(不仅仅是重定向它)。
根据我的经验,我可以告诉您,当您将 tc classes/filters 添加到网桥接口时,tc 没有按预期工作。它主要基于桥上入口和出口流量的定义,这(对我来说)非常混乱。我还使用 ICMP-Ping 功能测试了我的 tc 配置,和你一样,我也只能操纵 ICMP 回复。
我的假设是 tc 没有对 ICMP 请求做出反应,就像我的情况一样,它只是在桥接端口之间切换而没有路由。我能够通过用 ebtables (http://ebtables.netfilter.org) 删除它来处理 tc 的 ICMP 请求,因此强制它被路由而不是在桥接端口之间切换。
我仍然不确定这是否能解决您的问题,因为我不确定 GRE-Tunnels 的工作方式或实施方式。
我自己解决了这个问题。
tc 镜像出口流量 with Ethernet-Header 和入口流量 without Ethernet-Header
GRE-Tunnel 只需要 IP-Packets,所以有一个 header-mismatch。
如果我使用 VXLAN 而不是 GRE,它工作正常。
我正在尝试借助 tc
通过 GRE 隧道 tun0
从一个接口镜像 "all" 网络流量。 GRE-Tunnel 工作正常,我可以 ping 并通过它发送数据包,没有任何问题。我使用以下命令添加了 tc-qdisc
和 tc-filter
:
tc qdisc add dev ens5 ingress
tc filter add dev ens5 parent ffff: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0
和
tc qdisc add dev ens5 handle 1: root prio
tc filter add dev ens5 parent 1: \
protocol all \
u32 match u8 0 0 \
action mirred egress mirror dev tun0
喜欢这个Tutorial
问题
问题是只有入口流量通过 GRE 隧道。当我通过接口 ens5
ping 另一台计算机时,我只能通过 tun0
接口获得 icmp echo replies
。
我做错了什么?
调试
ubuntu@switch:~$ tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
10:23:28.952197 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 1, length 64
10:23:29.954454 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 2, length 64
10:23:30.952864 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 3, length 64
10:23:31.953207 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 4, length 64
10:23:32.955350 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 5, length 64
10:23:33.957000 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 6, length 64
10:23:34.956313 IP 192.168.20.12 > 192.168.20.15: ICMP echo reply, id 3453, seq 7, length 64
我从未使用过 GRE-Tunnels,但根据您发布的教程 link,它与网桥接口有关?我目前还在网桥接口上使用 Linux 流量控制 (tc) - 在我的例子中,它是由 Docker 创建的网桥,我必须操纵流量(不仅仅是重定向它)。
根据我的经验,我可以告诉您,当您将 tc classes/filters 添加到网桥接口时,tc 没有按预期工作。它主要基于桥上入口和出口流量的定义,这(对我来说)非常混乱。我还使用 ICMP-Ping 功能测试了我的 tc 配置,和你一样,我也只能操纵 ICMP 回复。
我的假设是 tc 没有对 ICMP 请求做出反应,就像我的情况一样,它只是在桥接端口之间切换而没有路由。我能够通过用 ebtables (http://ebtables.netfilter.org) 删除它来处理 tc 的 ICMP 请求,因此强制它被路由而不是在桥接端口之间切换。
我仍然不确定这是否能解决您的问题,因为我不确定 GRE-Tunnels 的工作方式或实施方式。
我自己解决了这个问题。
tc 镜像出口流量 with Ethernet-Header 和入口流量 without Ethernet-Header GRE-Tunnel 只需要 IP-Packets,所以有一个 header-mismatch。 如果我使用 VXLAN 而不是 GRE,它工作正常。