【问题标题】:Traffic mirroring with tc over GRE Tunnel only gets ingress Traffic通过 GRE 隧道使用 tc 进行流量镜像仅获取入口流量
【发布时间】:2017-04-23 14:00:10
【问题描述】:

我正在尝试借助tc 通过GRE 隧道tun0 从一个接口镜像“所有”网络流量。 GRE 隧道工作正常,我可以通过它 ping 并发送数据包,没有任何问题。我使用以下命令添加了tc-qdisctc-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

【问题讨论】:

    标签: linux mirroring network-monitoring trafficshaping


    【解决方案1】:

    自己解决了问题。

    tc 镜像出口流量with以太网头和入口流量不带以太网头 GRE 隧道只需要 IP 数据包,因此存在标头不匹配。 如果我使用 VXLAN 而不是 GRE,它可以正常工作。

    【讨论】:

    • 您是如何通过隧道发送镜像流量的?每次我将出口 sn-p 应用于 GRE 或 VXLAN 隧道时,Linux 主机都会锁定。内部 sn-p 工作正常。尝试了几种不同的发行版。
    • 我创建了一个 VXLAN,因此我添加了一个隧道接口 tun0。然后我使用了上面的确切命令。例如:ip link add vxlan0 type vxlan id 42 group 1.1.1.1 dev eth0
    • 奇怪,为设备名称指定 tun0 verse 之类的 vxlan42 导致崩溃。
    • 我认为 tunX 是为 tun/tap 设备保留的。也许问题是,Linux tun 设备在 OSI-Layer 3 上,而 VXLAN 在第 2 层上。但我不太确定。
    • 我相信你是对的。我再次尝试使用 vxlan42,它成功了。
    【解决方案2】:

    我从未使用过 GRE-Tunnels,但根据您发布的教程链接,它与桥接接口有关吗?我目前还在桥接口上使用 Linux 流量控制 (tc) - 在我的情况下,它是由 Docker 创建的桥,我必须操纵流量(不仅仅是重定向它)。

    根据我的经验,我可以告诉您,当您将 tc 类/过滤器添加到桥接接口时,tc 无法正常工作。它主要基于桥上入口和出口流量的定义,这(对我来说)非常令人困惑。我还用 ICMP-Ping 功能测试了我的 tc 配置,和你一样,我也只能操纵 ICMP 回复。

    我的假设是 tc 没有对 ICMP 请求做出反应,就像我的情况一样,它只是在网桥端口之间切换而不是路由。我能够使用 tc 处理 ICMP 请求,方法是使用 ebtables (http://ebtables.netfilter.org) 删除它,因此强制它被路由,而不是在网桥端口之间切换。

    我仍然不确定这是否能解决您的问题,因为我不确定 GRE 隧道是如何工作的,或者它们是如何实现的。

    【讨论】:

    • 感谢您的回复,我挖得更深了,问题是,tc 过滤器正在使用以太网标头镜像包。所以所有丢失的数据包都被破坏了,因为有一个以太网头而不是预期的 IP 头
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-07-11
    • 2022-06-11
    • 1970-01-01
    • 2019-11-15
    • 2022-08-17
    • 2012-01-06
    相关资源
    最近更新 更多