跳转至

NAS 无法扫描到涉及的网络知识

背景

tsj 的 NAS 插墙上网口,笔记本同样插墙上网口,然后使用 NAS 官方工具扫描不到设备。由于扫描不到设备所以不知道设备 ip,也就无法进一步配置。

那么是什么原因导致扫描不到呢,照理来说,NAS 和笔记本应该接在同一个交换机下,理应是互通的。在研究该问题过程中,查缺补漏了很多网络知识,特记录。

疑问一:学校为何插在相邻墙上的网口的机器分配到不同网段的 ip?比如 114.xxx 和 210.xxx 疑问二:宿舍路由器查看 wan 口邻居表,为何不同 ip 的 mac 地址是相同的?

疑问一:学校为何插在相邻墙上的网口的机器分配到不同网段的 ip?比如 114.xxx 和 210.xxx

首先思考不同网段和位于同一个交换机下冲突吗?

其实不冲突,原因是 ip 是三层的概念,只要 ip 包能够正确送到目的地址即可,并不关心底层是直接发送的,还是经过路由的(经过路由时每一跳 mac 地址都会变化)

设备访问相同网段和不同网段地址时的行为是不同的

  • 相同网段时,系统通常已经有该网段的路由了,因此会尝试往对应接口发送 arp 请求,请求目的地址的 mac 地址。arp 请求成功后,则往对应接口发送报文,如果 arp 失败(比如端口隔离时),则会 icmp 报错。
  • 如果位于不同网段,则会匹配默认路由。此时设备需要将包发送给网关转发,因此实际会发送 arp 请求网关的 mac 地址

虽然网段不同,导致默认情况下无法直接相互访问。但是我们可以手动设置路由表,使得它们直接相互访问。

首先可以测试两个设备确实属于一个广播域,如发送 arp 请求是可以得到响应的。

root@op1 ➜  ~ arping -I br-wan  202.38.78.82
ARPING 202.38.78.82 from 114.214.236.72 br-wan
Unicast reply from 202.38.78.82 [00:11:32:B2:3F:D9]  0.897ms
Unicast reply from 202.38.78.82 [00:11:32:B2:3F:D9]  0.827ms

但是由于不位于相同网段,所以默认情况下访问需要经过三层转发。

root@op1 ➜  ~ traceroute 202.38.78.82
traceroute to 202.38.78.82 (202.38.78.82), 30 hops max, 46 byte packets
 1  114.214.236.254 (114.214.236.254)  0.427 ms  0.361 ms  0.354 ms
 2  202.38.78.82 (202.38.78.82)  0.353 ms  0.253 ms  0.235 ms

接着我们可以手动添加路由表,这里不指定 via 表示位于同一个广播域

root@op1 ➜  ~ ip ro add 202.38.78.82 dev br-wan

然后再尝试 ping 202.38.78.82。可以抓取到设备首先尝试获得 202.38.78.82 的 mac 地址,发出 arp 请求

root@op1 ➜  ~ tcpdump -e -ni br-wan arp and ether host 00:16:3e:e2:4e:72
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:53:21.197964 00:16:3e:e2:4e:72 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 202.38.78.82 tell 114.214.236.72, length 28
17:53:21.198395 00:11:32:b2:3f:d9 > 00:16:3e:e2:4e:72, ethertype ARP (0x0806), length 60: Reply 202.38.78.82 is-at 00:11:32:b2:3f:d9, length 46

获得 mac 地址后,设备直接直接发送给对应设备(目的 mac 是设备,而不是网关)

  • 这里有意思的是 reply 的 src mac 地址其实是学校网关的地址。这是因为对面机器收到 ip 包后,并不会在意二层是怎么传过来的,产生响应 ip 包后,还是按照原本流程发送。
root@op1 ➜  ~ tcpdump -e -ni br-wan icmp and host 202.38.78.82
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:53:47.761041 00:16:3e:e2:4e:72 > 00:11:32:b2:3f:d9, ethertype IPv4 (0x0800), length 98: 114.214.236.72 > 202.38.78.82: ICMP echo request, id 53752, seq 0, length 64
17:53:47.761502 e8:78:ee:13:cc:01 > 00:16:3e:e2:4e:72, ethertype IPv4 (0x0800), length 98: 202.38.78.82 > 114.214.236.72: ICMP echo reply, id 53752, seq 0, length 64
17:53:48.761083 00:16:3e:e2:4e:72 > 00:11:32:b2:3f:d9, ethertype IPv4 (0x0800), length 98: 114.214.236.72 > 202.38.78.82: ICMP echo request, id 53752, seq 1, length 64
17:53:48.761326 e8:78:ee:13:cc:01 > 00:16:3e:e2:4e:72, ethertype IPv4 (0x0800), length 98: 202.38.78.82 > 114.214.236.72: ICMP echo reply, id 53752, seq 1, length 64

至于学校是如何 dhcp 分配地址的,通常是根据该栋楼的设备数目,配置好地址池,然后随机从地址池中分配 ip。

疑问二:宿舍路由器 ip neigh wan 口,为何不同 ip 的 mac 地址是相同的?

可以发现宿舍路由器 neigh 的 mac 地址都是相同的

root@op2 ➜  ~ ip neigh |grep eth0
114.214.175.254 dev eth0 lladdr 5c:dd:70:91:72:e2 DELAY
114.214.173.13 dev eth0 lladdr 5c:dd:70:91:72:e2 STALE
114.214.172.86 dev eth0 lladdr 5c:dd:70:91:72:e2 STALE
114.214.172.87 dev eth0 lladdr 5c:dd:70:91:72:e2 STALE

实际上宿舍的网络结构是比较复杂的

  • 可能每一层有一个交换机,连接到整栋楼的交换机。
  • 宿舍的每个墙上的端口都是 vlan 隔离的
    • 也就是二层上设备间是无法接收到对方的网络包的,而不像一个广播域中,广播包所有设备都能收到
    • vlan id 12bit 的限制可能不够用,因此这里还涉及到 q in q 的技术
    • 隔离的目的主要是为了降低广播风暴
  • 还有 BRAS 设备负责鉴权以及路由

那么你可能好奇,如果宿舍楼有两台设备位于同一个网段,它们相互访问会发生什么?(不同网段其实和上节的情况一样,都需要通过网关转发) 当设备 A 访问设备 B 时,由于同一个网段,所以会尝试 ARP 获得设备 B 的 mac 地址。但是由于 A,B 二层隔离,B 收不到 arp 请求。也就是 A 无法获得 B 的 mac 地址。

但是神奇的是,学校的交换机设备 C 开启了代理 ARP,此时学校设备会“欺骗”A,说地址 B 的 mac 地址是 C。于是 A 就会把包发给 C 了,C 再根据目的 ip 发送给 B。 上述过程和 A 将包发给网关,网关在转发给 B 基本是一样的。只不过在 A 看来以为是直接发送给了 B。这里也再次验证了那句话,三层并不在意二层是怎么发的,只要包最终能到正确的地方即可。

了解代理地址解析协议 (ARP) - Cisco

  • 设备配置了 172.16.10.100/16,掩码相当于告诉设备能够访问 172.16.0.0/16 整个网段。访问该网段时会直接发送 arp 请求。

NAS 无法扫描原因

扫描软件的原理(猜测)

  • 设备的 MAC 地址是已知的,并且每个厂商都有单独的 vendor id。因此只要获得子网所有设备的 mac,然后匹配到设备即可
  • 为了探测子网内所有设备 MAC,可以先向子网发送一个广播消息,比如 192.168.1.255/24
  • 广播后 ARP 表便包含了所有的邻居

而我们遇到扫描不到的原因在于笔记本和 NAS 通过学校 dhcp 获得的 ip 地址不是同一个网段,而操作系统检测到的 ARP 消息如果地址不在一个网段,那么是不会更新 arp 表的。

通过 tcpdump 可以抓到很多不在同一网段的 ARP 请求,但是可以发现 ip neigh 只包含同一网段的设备

root@op1 ➜  ~ tcpdump -e -ni br-wan arp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-wan, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:22:00.638083 58:11:22:a4:37:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 210.45.76.56 tell 210.45.76.239, length 46
19:22:01.623857 58:11:22:a4:37:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 210.45.76.56 tell 210.45.76.239, length 46
19:22:02.084291 24:69:68:a6:27:05 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 202.38.78.179 tell 202.38.78.138, length 46
19:22:02.217667 f0:2f:74:dc:8a:df > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 202.38.78.116 tell 202.38.78.208, length 46
19:22:02.622637 58:11:22:a4:37:23 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 210.45.76.56 tell 210.45.76.239, length 46

ipv6 广播并结合 MAC OUI 查询设备

由于 ipv6 有专门用于表示 link scope 的地址fe80,不存在像 ipv4 不处于同一个网段的情况。因此 ipv6 的广播能够探测广播域上的所有设备(自己的理解,不严谨还请指正) 我们只需要 ping 下 ipv6 的广播地址

root@op1 ➜  ~ ping ff02::1%br-wan

然后就会发现 ipv6 的 neighbor 数量一下子变得很大(尝试在两台不同设备上,都得到了非常接近的数字),并且也瞬间探测出了实验室的两台群晖

root@op1 ➜  ~ ip -6 n |grep br-wan |wc -l
247
root@op1 ➜  ~ ip -6 n |grep br-wan |grep 3f:d9
fe80::211:32ff:feb2:3fd9 dev br-wan lladdr 00:11:32:b2:3f:d9 DELAY
root@op1 ➜  ~ ip -6 n |grep br-wan |grep b3e9
fe80::9209:d0ff:fe00:b3e9 dev br-wan lladdr 90:09:d0:00:b3:e9 PROBE

有了 mac 地址后,我们能不能自动解析设备型号呢

The first half of the six octets represent the Organizational Unique Identifier (OUI) and the other half is the Network Interface Controller (NIC) which is unique for every device in the world.

可以使用 OUI 数据库查询 Command-line tool to obtain OUI vendor info from MAC address? - Unix & Linux Stack Exchange

wget "http://standards-oui.ieee.org/oui.txt"

ping ff02::1%vmbr0
ip -6 n |grep vmbr0 | awk '{print $5}' | tee ip6-neigh.log  #获得所有邻居的mac地址

for m in $(tr -d ':' < ip6-neigh.log | grep -o '^......'); do grep -iF "$m" oui.txt; done |tee mac_vendor.log  # 对每个mac查询数据库

netdiscover 自动探测设备

netdiscover | Kali Linux Tools netdiscover 也是针对上述需求,可以探测局域网内设备。

netdiscover 基于 ARP,能够捕捉 ARP 请求(主动扫描发起或者被动探测),并且解析 mac 地址设备信息

netdiscover -p -i vmbr0  # -p 表示被动模式
  • 但是不知道为何群晖的 IP 是 0.0.0.0
    • 手动 ping 下群晖 ip 后,netdiscover 又可以抓到地址

参考

Find Device or IP Address with MAC Address - Command-line & Tools! (pcwdld.com)

  • arp
  • dhcp