Executor

@nkloveni 没错的, 我也估计是这样的情况, 只是机房给我的回复非常肯定我在搞 arp 欺骗把我整的不自信了, 再加上从 kernel 的源码 /net/ipv4/netfilter/nf_reject_ipv4.c#L183-L184 可以看出确实是按你说的这样回

@newborn 输出全 0, 确实没开这东西

@newborn 今晚我的机器才送到家里, 到时候上电了我看看, 感谢

@huaxie1988 所以我也很好奇这些包是怎么给我转来的
别的网段的 arp 请求一般来讲我不可能能原样收到, 中间都要过网关, 我很显然和其它网段的主机不是"网络邻居", 但交换机就是学到了我的 mac 挂着多个/24 段的 IP
但有一个有趣的现象, 我的网卡挂的实际上直接是公网 IP 地址, 网关也是该 IP /24 段下的地址, 是不是这中间他们有什么策略转换成他们自己内网的 11.0.0.0/8 这个地址后搞出来的一系列问题

@Int100 差不多就是这样子; 是的, 我单独托管了一台

@newborn 另附当时在 vpn xfrm 网口上抓到的回包脱敏图片: https://sm.ms/image/UFRiNvxGPaTlc3o
这个包从网口收到, 但 reject 报文从 xfrm 网口传出, 因为当时偷懒直接定了 10.0.0.0/8 dev ipsec0 的路由规则, 所以 reject 报文从 xfrm 网口发出去前被我抓到了
看内容是机房内部的 syslog 通信报文被转到我机器 (11.x.y.z) 上来了, 后来我严格了路由规则后, reject 报文就会从网口发回, 交换机应该就会看到了
有些怀疑是因为这个 syslog 的报文被交换机广播到我机器上, 然后机器回了 reject 报文导致交换机学习了

@newborn 谢谢, 实际情况中, 上层交换为我的 mac 地址记录了额外的 3 个/24 段, 每段至少 5 个 IP+的映射关系, 因此 "11.1.2.3 设备的 mac 地址与 10.1.2.4 相同" 这个说法应该不成立
所以我很疑惑这些记录是怎么创建出来的, 按理说其它内网的 arp 包到不了我这一边, 且就算到了我这边, 内核也不应回复
机房给我的 dis arp | in abcd-ef01-0203 截图大体如下
IP ADDRESS | MAC ADDRESS | EXP(M) | TYPE/VLAN | INTERFACE
10.1.2.4 | abcd-ef01-0203 | 110 | D/123 | Eth-Trunk2
...
10.2.5.6 | abcd-ef01-0203 | 112 | D/123 | Eth-Trunk2
...
10.3.6.7 | abcd-ef01-0203 | 113 | D/123 | Eth-Trunk2
...
11.1.2.3 | abcd-ef01-0203 | 111 | D/123 | Eth-Trunk2

@LinusJian 可以确信的是我的网卡只绑定了 11.1.2.3 这个 IP, 所以就算 kernel 收到了请求 10.1.2.3 / 10.1.2.4 的 arp 报文也不应回复
机房认为我的服务器在进行 arp 欺骗攻击, 执意要清退。我在排除了上述情况后, 想起以前曾在网口上抓到其余内网通信的 udp 报文, 并且最近我在 forward 链上从默认 drop 改为 reject with icmpx admin-prohibited 动作, 所以才想是不是因为这个改动导致的

@huaxie1988 我开了 net.ipv4.ip_forward, 所以主楼中 forward 链的动作是 reject 。如果没开的话, 到不了 forward 链上就会被 kernel 丢弃
现状是我从网关收到了别的内网的原样 udp 报文, reject 动作回了 icmp admin-prohibited 给网关。与网关通信的过程中就会接触到主楼中的三层交换