流量路径:macbook —-> 旁路由 —-> 主路由,去程包源 IP 是 macbook 源 mac 是旁路由的,抓包发现主路由侧主动丢包了。仅在 wifi 下存在这个行为,有线客户端没事,看起来很像一种 wifi 的一种安全策略,会拒掉 wifi 终端 ip 与 mac 不一致的包。
之前某讯主路由没事,现在换了小米和 tplink 的都存在这个行为,谁了解 wifi 这块行为,求指点。
1
AngryK 2021-01-09 10:35:45 +08:00 via iPhone
我不是开发,这个应该是 WiFi 的策略我转给技术同事看下吧
|
2
paradislover 2021-01-09 10:42:29 +08:00 via Android 1
WiFi 是 mac 层的,不 care ip
|
3
Donahue 2021-01-09 11:48:30 +08:00
会不会是因为小米跟 tp 防止 arp 攻击导致的?
|
6
futuregaget 2021-11-01 14:16:41 +08:00
卧槽卧槽,我遇到这个问题了
一个包先在主路由二层转发到旁路由,旁路由三层转发回来 导致一个包在主路由出现两次 client mac->旁路由 mac 变成了 旁路由 mac->主路由 mac 更牛逼的是,必须是无线进来的流量才有这个问题,有线进来的流量没这个坑,也就是说,如果一个流量从无线进来一次,在看到从其他地方过来的,就会扔掉。。。 |
7
futuregaget 2022-01-15 18:10:21 +08:00
这个问题我进一步研究了下,倒不是安全策略
ax3600 现在可以进 shell 。 以通过路由转发同子网流量为例,可以看到流量第一次进路由的时候,就有 conntrack 记录。虽然是二层转发(也确实是二层转发,不会给你解包到 3 层,对端看到的 srcmac 也是真实的 scrmac ),但是使用 iptables -i br-lan 能看见 wifi 进来的流量。这个是不正常的,可以试试,是看不见网线过来的二层转发流量的。 旁路由场景,等流量正式的以 3 层转发的形式从旁路由过来的时候,因为之前存在 conntrack ,流量无法进入 nat 表,nat 表只处理没有 conntrack 记录的包,有 conntrack 记录需要通过 cstate 模块进行转发,对于现在的流量来讲它是有 conntrack 记录的,但是没有回包,第二次进来的流量被认为是同一个 contrack 的同方向新包,直接丢弃 |
8
futuregaget 2022-01-15 18:11:22 +08:00
以为的 case 为例,我比较倾向于 wifi 的网卡桥接 br-lan 这个地方,linux 和高通有一方没搞对
|
9
futuregaget 2022-01-15 18:12:30 +08:00
@paradislover
是的,但是我验证出来,虽然确实不 careIP ,但是只要是 wifi 进来的流量,就算是二层 forward ,conntrack 表也有记录 |