现有一台服务器, 内网 IP 为 11.1.2.3, 上联一个三层交换机
其余内网的 udp 通讯 10.1.2.3 -> 10.1.2.4 被该交换机转发到 11.1.2.3 上
由于 11.1.2.3 内 forward 链上的 nft 规则计算为 reject, 组合 10.1.2.4 -> 10.1.2.3 icmp admin-prohibited 包发回到该三层交换机
请问此时交换机会根据该 icmp 包学习到服务器具有该 IP 的 arp 表项不
即:
IP ADDRESS | MAC ADDRESS
11.1.2.3 | abcd-ef01-0203
10.1.2.4 | abcd-ef01-0203
- 换行被吃掉了, 加上换行
 |
1
FabricPath 6 天前
没看懂你的问题
不过无所谓， 交换机的 1 号口，收到过 SrcMac 为 A 的报文，它就会记录下来 A -> 1 号口；下次从其他口收到 DestMac 为 A 的报文，就会转发到 1 号口 |
 |
2
Executor OP @FabricPath 谢谢, 简单一点来说就是, 该服务器报文内使用的 IP 和 MAC 经过该三层交换转发出去后, 交换机是否会学习到其中的 IP/MAC 信息
|
|
3
Executor OP @FabricPath 需要补充一下, 报文类型是 ICMP, 不是 ARP
|
 |
4
lurenjiaMAX 6 天前 via Android
你的问题应该是 三层交换机会不会只根据一个 IP 数据报更新他的 arp table
简单来说 不会 因为这个表是通过 arp 协议维护的 https://networkengineering.stackexchange.com/questions/59507/arp-table-updated-when-receive-message |
|
5
lurenjiaMAX 6 天前 via Android
当然 不排除可以在软件或硬件上做一些修改 让他支持这个功能的情况
不过支持这个功能有什么用呢.. |
 |
6
hwdq0012 6 天前
好像 arp ，如果没有建立过连接，不会被维护在表里
arp -a 看不到， 你既然已经用 udp ，如果 client 和 server 都是自己写的程序，可以用 udp 广播，组播 |
 |
7
huaxie1988 6 天前
三层交换机不能做 nat 吧？然后你怎么把包转过去？用流策略重定向？就算你重定向了发给 11.1.2.3 ，一般服务器没开路由功能直接就丢包了，不会回 icmp ，服务器开了路由就回又把包发给交换机
|
 |
8
gefranks 6 天前 via iPhone
我觉得会 交换机都能转发包到服务器上 交换机上应该知道服务器的 mac 了 以我的理解要能过来包 得 2 层通才行
|
 |
9
Int100 5 天前 via iPhone
不会.
交换机不会根据 icmp 报文去更新 mac table. |
 |
10
leonshaw 5 天前 via Android
只会根据 ARP 包更新 ARP 表，而且 ICMP 的外层源应该是 11
|
 |
11
LinusJian 5 天前
不会.
这怎么看都不对啊, 11.1.2.3 发给 10.1.2.3 和 10.1.2.4 的 icmp admin-prohibited 包, 源 MAC 和源 IP 对应该是 11.1.2.3 | abcd-ef01-0203, 目的 IP 是 10.1.2.3 和 10.1.2.4, 目的 MAC 是 11.1.2.3 的网关 MAC. 没道理会学到 10.1.2.4 | abcd-ef01-0203 的 ARP 表项 还是说你的服务器发的是 10.1.2.4 -> 10.1.2.3 的 icmp admin-prohibited 包? 源 IP 和源 MAC 是 10.1.2.4 和 abcd-ef01-0203? 这样的话, 可能会学到 ARP, 看策略 |
 |
12
newborn 5 天前
友情提醒 11.0.0.0/8 不适合用作内网地址。
然后作为专业运维表示你的问题很难看懂，交换机通常只维护 mac-address table ，arp 表一般是主机和本机有三层通信的场景，比如作为 vlan 网关用于 vlan 间通信。 |
|
13
Executor OP @lurenjiaMAX 不是的, 是我在 A 内网收到了 B 内网内部的 udp 报文
该三层交换直接把别人通讯的报文原样转发到我这边, 然后 nft 根据 reject 动作回了 icmp admin-prohibited |
|
15
Executor OP @newborn 并非我组建的内网, 我把服务器托管在机房, 机房是这么配的
我把遇到的情况简化成了主楼 机房在交换上使用 dis arp | in abcd-ef01-0203 查到了大量有关于我服务器 mac 的表项 所以我想是不是因为 nf 回的 icmp admin-prohibited 导致交换学习到了这些表项 收到 saddr 10.1.2.3 daddr 10.1.2.4 的 udp 报文 回复 mac abcd-ef01-0203 icmp admin-prohibited saddr 10.1.2.4 daddr 10.1.2.3 |
|
16
Executor OP @huaxie1988 我开了 net.ipv4.ip_forward, 所以主楼中 forward 链的动作是 reject 。如果没开的话, 到不了 forward 链上就会被 kernel 丢弃
现状是我从网关收到了别的内网的原样 udp 报文, reject 动作回了 icmp admin-prohibited 给网关。与网关通信的过程中就会接触到主楼中的三层交换 |
|
17
LinusJian 5 天前
@Executor 大多数交换机只会通过 ARP 报文学习 ARP (ethtype == 0x0806). 但不排除有的交换会把所有进 CPU 的报文的 IP-MAC 都学到 ARP 里面
ARP 攻击也得是发非法 ARP 才算吧, 这种情况就算 DAI 都挡不住 还有就是为什么会把别的网段的包转到这个口, 这就很不合理 建议机房严查, 感觉是交换的 BUG |
|
18
Executor OP @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 动作, 所以才想是不是因为这个改动导致的 |
|
19
newborn 5 天前  1
@Executor 我梳理下你的问题
udp 通讯 10.1.2.3 -> 10.1.2.4 被该交换机转发到 11.1.2.3 上 解读、正常网络上不会发生这种事情，10.1.2.3 -> 10.1.2.4 是单播通信，也就是会发给 10.1.2.4 而不是 11.1.2.3 这里的通信过程是 10.1.2.3 发起 arp 广播，10.1.2.4 设备响应，然后两者可以通信，广播过程中，交换机只在二层工作，也就是对于 10.1.2.3 发起的广播收束定向发给 10.1.2.4 所在的接口。 现在要考虑的就是为什么 11.1.2.3 会收到数据，可以认为交换机实际上并没有通过 vlan 之类的技术将广播隔离，然后这台 11.1.2.3 设备的 mac 地址与 10.1.2.4 相同，也就是你后面补充的机房认为你的机器在搞 arp 欺骗，这里交换机仅参与二层工作。 然后你提到 11.1.2.3 主机转发链上有拒绝策略，这种是会返回一个包给请求源的 所以数据流程可以梳理成这样，10.1.2.3 上发起对 10.1.2.4 的 ping ，该主机通过 arp 广播学到的 10.1.2.4 的 mac 为 abcd-ef01-0203 ， 交换机视角：mac 表上在两个不同的接口上记录了 abcd-ef01-0203 ，将数据包随机均衡发到这两端口 你的主机 11.1.2.3 收到了来自 10.1.2.3 至 10.1.2.4 的包，因为目标不是本机，所以执行转发动作，然后根据本机防火墙的策略，返回相应的禁止报文。 |
|
21
Executor OP @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 |
|
22
Executor OP @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 报文导致交换机学习了 |
|
23
Int100 5 天前 via iPhone
这机房怎么会用 11.0.0.0/8 这种作为内网地址呢？
|
|
24
Int100 5 天前
让我捋捋
- 这机房给你配的地址是 11.0.0.0/8 这种地址. - 机房没做隔离, 10.0.0.0/8 的数据包也转发到你这来了. - 机房内部内部的 syslog 通信报文你也收到了. - 机房认为你的的服务器在进行 ARP 欺骗攻击, 执意要清退. --- 你是单独托管一台服务器在机房里的吗? |
|
26
huaxie1988 4 天前 via Android
感觉你把因果搞错了，单播包在交换机没做策略情况下不可能发给你，所以会不会是先交换机上 arp 指向你了才导致把包发给你，和你后面的 icmp 没关系。
|
|
28
Executor OP @huaxie1988 所以我也很好奇这些包是怎么给我转来的
别的网段的 arp 请求一般来讲我不可能能原样收到, 中间都要过网关, 我很显然和其它网段的主机不是"网络邻居", 但交换机就是学到了我的 mac 挂着多个/24 段的 IP 但有一个有趣的现象, 我的网卡挂的实际上直接是公网 IP 地址, 网关也是该 IP /24 段下的地址, 是不是这中间他们有什么策略转换成他们自己内网的 11.0.0.0/8 这个地址后搞出来的一系列问题 |
 |
31
nkloveni 1 天前
你看看你 ICMP reject ，回包的 IP ，应该就是你那个 nft 的 reject 导致的。交换机的 mac 表只是看了一眼报文里的 mac 地址和 ip 地址，就把对应关系记录下来了。而你的机器开了 ip_forward ，回个别的 IP 给网关很正常啊
|
|
32
Executor OP @nkloveni 没错的, 我也估计是这样的情况, 只是机房给我的回复非常肯定我在搞 arp 欺骗把我整的不自信了, 再加上从 kernel 的源码 /net/ipv4/netfilter/nf_reject_ipv4.c#L183-L184 可以看出确实是按你说的这样回
|
|
33
nkloveni 15 小时 41 分钟前
@huaxie1988 你猜当交换机在 mac 表里找不到数据包的 mac 地址，不知道该向哪个口转发的时候，交换机会怎么办？
|
Select Language