首页 > 其他分享 >因为一台NUC怒学两天网络排查问题

因为一台NUC怒学两天网络排查问题

时间：2023-08-27 22:23:27浏览次数：36  
标签：MAC 怒学 192.168 1.103 排查 地址 ff arch NUC

起源

鄙人曾经认为自己不会乱花钱，第一个月工资发下来就上海鲜市场整了一台NUC，真香~

img

我给它装了个archlinux，由于太菜，直接用了开源的GUI Installer，我每天把它带到公司，带回家，贼喜欢。

但是我发现，在公司的时候，无论如何也没法让我的macbook ssh到arch上，它们连接了同一个wifi网络，在同一个子网下，没有ap隔离，其它的设备都能正常互相通信，只有macbook没法连上arch！但在家里一切都是好的！

而且更魔幻的是，一般在arch开机几十分钟后，macbook就可以正常连接arch！

问题到这已经有点玄了，实际上从效率角度考虑直接重装一个ubuntu就完事了，但是想到arch社区里的那些geek们怼天怼地的样子，这样就退出arch阵营岂不是显得自己很垃圾！所以我就开始找一些网络书看，试图找出原因。就是以下两本：

  • 计算机网络：自顶向下方法
  • TCP/IP卷一：协议

今天终于发现点眉目，记录一下

工作了是真没精力更新博客，哎哎哎~

局域网互联过程简述

在我早先的视角里，一个局域网之间的两台设备，通过一个ip就能直接互相访问，这对我来说非常自然，我也从来不知道这里面的细节，甚至之前读计算机网络自顶向下方法的时候也就读到网络层就完事了，再下面我是完全没了解过。

下面我会尝试先阐述一些网络知识，我的措辞不一定准确毕竟我是个网络菜鸡，哦不，全方面菜鸡。

广播式网络的链路层通信

TCP/IP的链路层使用硬件地址通信，我们熟知的MAC地址就是硬件地址的一种形式。后面我们直接用MAC地址来阐述。

我所在的WIFI网络就是一种广播式网络，之前的那种用一条线把很多设备连在一起的也叫广播式网络，这种网络的特性是你发送一条数据，网络中的其它设备不可避免地也会接收到，尽管你不是发给它的，而发给谁就用链路层头中的目标地址标识，硬件或驱动程序发现该数据包不是发给自己的就会主动丢弃该数据包，如果发现是发给自己的就会拆解，向上递交给IP层。

ARP

我们假设archlinux的IP地址是192.168.1.103，并且下文中我们会一直使用该IP，我们的目的是用一台处在同一局域网（192.168.1.0/24）的其它设备ssh连接它

考虑我们常见的场景，archlinux刚刚接入到网络中，我们知道它的ip地址是192.168.1.103，然后我打算通过我的另一台电脑ssh到它：

~# ssh [email protected]

传输层会把端口号22封装到传输层头，IP层会把192.168.1.103封装到IP层头中，但这俩东西对于链路层来说狗屁不是，按照分层原则，链路层甚至不应该知道它们的存在（但这只是理想情况下）。链路层通信需要的是MAC地址，而我们根本不知道archlinux的链路层地址！链路层根本没办法指定archlinux接收这个消息啊！

但是刚刚说过，对于广播式局域网，你发一个数据包，无论目的MAC是啥，网络中的所有设备都能接到，所以我们好像是可以实现发一个数据包问问网络中哪一个设备拥有192.168.1.103这个IP地址，如果它有，就返回自己的MAC地址，这样我们就知道192.168.1.103对应的MAC地址是啥了。这东西就叫ARP（地址解析协议）。

通过WireShark抓包，在SSH时确实抓到了几个ARP协议的数据包，第一个数据包在问，谁有192.168.1.103这个IP地址，如果有的话，告诉我。下面两个数据包是两个回复，返回了两个MAC地址

img

这里先不考虑为啥返回两个的问题

可以看到，ARP协议发送的目的MAC地址是ff:ff:ff:ff:ff:ff，这是一个链路层的广播地址，广播式局域网中，设备不会过滤掉该消息，虽然这个MAC地址不等于自己的MAC地址

img

解决问题

为什么有两个MAC地址宣称它们has对应的IP

从上面抓到的数据包中可以看到有两个MAC地址都说自己拥有192.168.1.103这个IP，我们知道一个计算机可能有多个网络接口，每一个网络接口有一个MAC地址并连接到一个网络，而且至少一般来说，每一个网络接口都拥有一个独立的IP地址，所以按理说不应该存在像上面这种有两个MAC地址说它拥有192.168.1.103的情况。

根据ifconfig的返回，我知道了这个9c什么的MAC地址来自于wlan0这张网卡，它的IP也不是103啊，1c开头的这个有线连接的MAC地址才是对应的103：

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.103  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 1c:69:7a:a2:cd:b6  txqueuelen 1000  (Ethernet)
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.85  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 96:b1:6a:23:0e:99  txqueuelen 1000  (Ethernet)

而且操蛋的是，在我使用的电脑（要连接到arch的那台电脑）上，9c这个wlan0网卡的mac地址已经被绑定到了192.168.1.103这个有线连接的IP上：

C:\Users\15941>arp -a

Interface: 192.168.1.125 --- 0x5
  Internet Address      Physical Address      Type
  192.168.1.1           18-7c-aa-f1-d1-01     dynamic
  192.168.1.103         96-b1-6a-23-0e-99     dynamic

卧槽！！！这不是瞎几把弄吗？

就在我刚被这个问题攻击尚处于眩晕状态的时候，我又发现了更操蛋的事，我在家里也连不上192.168.1.103这个IP了！症状和在公司一样，我一直以为这个病只会在公司出现呢。

不过操蛋归操蛋，我还是很兴奋的，因为我感觉我快接近正确答案了！

wlan0的MAC地址居然会变！？

分析一下，无法给192.168.1.103发消息，问题不可能在IP层，只可能出现在arp缓存表里的mac地址有问题，我到arch里看了一眼，果然，吐血了！

4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 12:db:7f:b1:c3:19 brd ff:ff:ff:ff:ff:ff permaddr 2c:db:07:28:58:8e
    ...

网卡wlan0的MAC地址已经变成了12:db:7f:b1:c3:19，而我的另一台电脑的arp缓存表里还用的96开头的老MAC地址发送数据，自然，网络中所有设备都接到该数据，但没人会接，因为没人的MAC地址是96那一串。

这已经打破我的认知了，MAC地址竟然会变化！直觉告诉我wlan0这张网卡是虚拟的，所以它才可能MAC地址变化。

所以archlinux无法访问的问题原因到这里应该就找到了，不是只有在公司才会发生，而是纯纯的偶然，上面这种情况在公司每次都发生了。

  1. 当我发出ARP，寻找192.168.1.103的MAC地址时，wlan0欠儿欠儿的告诉我，它拥有这个地址
  2. 我误打误撞的在wlan0和eno1的返回中，选择了wlan0的MAC地址
  3. wlan0的MAC地址动态变更，被我记录在arp缓存表里的MAC地址无效了
  4. 几十分钟后，我的arp缓存表失效，重新发送arp，这次有可能误打误撞我选择了eno1的MAC，或者wlan0尚未动态更换MAC

iwd快滚！！

我不断地尝试在Google上构造关键词，interface、wlan0、MAC address、dynamically change...终于找到了几篇文章：

原来是iwd在默认情况下（一个命令行控制wifi连接的程序）给我虚拟了一张wlan网卡，并定时的动态更换我的MAC地址。而且我发现我arch里本来有一个nmcli就可以控制wifi连接，根本没必要用iwd。

我大概知道了，我用的第三方archlinux图形界面安装程序给我装了些自动的网络管理工具，但我是个newbie，我根本不懂，自己又装了一些，后面还有网络管理工具之间的冲突造成的问题。

所以我卸载了iwd并重启，wlan0网卡已经变回了我原先的无线网卡wlp0s20f3，MAC地址也正常了，不会随机改变了。

2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 2c:db:07:28:58:8e brd ff:ff:ff:ff:ff:ff

现在再看ARP，虽然2c这个MAC地址也会回复它拥有192.168.1.103，但是MAC地址失效的问题不会出现了

img

当我想要用主机名连接的时候，又有骚问题...

我肯定不想每次都用IP地址连接啊，而且IP地址是DHCP的，下次就变动了，我肯定想用我arch的主机名——yudoge-arch来连接！

在没有DNS服务器的局域网中，mDNS协议可以利用组播来交换主机名

我用主机名顺利的连接到arch上，但我感觉这个延迟...不像有线连接，而是像WIFI连接，即使我确定使用的MAC地址是有线连接的。

抓包看下mDNS协议相关的数据包：

img

192.168.1.103和192.168.1.104都说它们是yudoge-arch，可是我的印象里根本没有104这个IP啊...

而且ping的结果显示，103的延迟基本只有1到2ms，是正常的有线连接延迟，而104的延迟飙到了100ms左右：

C:\Users\15941>ping 192.168.1.103

Pinging 192.168.1.103 with 32 bytes of data:
Reply from 192.168.1.103: bytes=32 time=1ms TTL=64
Reply from 192.168.1.103: bytes=32 time=2ms TTL=64

C:\Users\15941>ping 192.168.1.104

Pinging 192.168.1.104 with 32 bytes of data:
Reply from 192.168.1.104: bytes=32 time=94ms TTL=64
Reply from 192.168.1.104: bytes=32 time=106ms TTL=64

我进到arch里，用ip addr看了一眼，我靠，确实，每一个网卡都有两个IP：

img

有了之前的经验，我大概猜到了是我自己装了什么网络管理服务和自带的冲突了，我目前用的是NetworkManager，好在Arch的wiki中有提到可以用systemctl --type=service查看一下现在运行的服务

img

img

果然除了NetworkManager还有另外一个systemd-networkd服务，我把它disable了

➜  ~ sudo systemctl disable systemd-networkd
Removed "/etc/systemd/system/sockets.target.wants/systemd-networkd.socket".
Removed "/etc/systemd/system/dbus-org.freedesktop.network1.service".
Removed "/etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service".
Removed "/etc/systemd/system/sysinit.target.wants/systemd-network-generator.service".
Removed "/etc/systemd/system/multi-user.target.wants/systemd-networkd.service".

重启！！

现在只有103会回复自己是yudoge-arch，并且它会在数据包里携带自己的MAC地址，这就避免了我arp之后两张网卡都回复，然后绑错网卡的情况：

img

img

ip addr显示只有一个IP地址了：

img

总结

本篇文章解决了两个奇怪的网络问题：

  1. 绑定好的MAC地址无效了导致局域网内无法通信
  2. 一个网络接口有多个IP地址，导致mDNS时把主机名解析成了预期之外的IP

这两个问题的成因都是因为对archlinux甚至对整个linux体系的不了解，瞎装了其它的网络管理工具造成的，所幸这两个问题大概是把我引入了使用archlinux的门槛，我已经懂得利用archlinux最成熟最牛逼的wiki体系了。

网络是一个很复杂的东西，概念很多，而且偏向实践和工程，我仍有很多细节不了解，所以本文中的很多用词可能不准确，欢迎批评指正。

标签：MAC,怒学,192.168,1.103,排查,地址,ff,arch,NUC
From： https://www.cnblogs.com/lilpig/p/17660996.html

相关文章

  • WinDbg排查.net性能或内存问题步骤简述
    目录一、安装WinDbg二、诊断数据获取三、加载分析四、举例分析以下步骤是分析高CPU占用的命令本文摘自一、安装WinDbg第一步当然是安装了，需要注意的是，千万不要搜索windbg然后下载，搜索到的windbg安装文件，都不是我们想要的，真正的windbg，实际上是在微软的SDK里，下载链接在这里：ht......
  • 一次Java内存占用高的排查案例，解释了我对内存问题的所有疑问
    原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。问题现象7月25号，我们一服务的内存占用较高，约13G，容器总内存16G，占用约85%，触发了内存报警(阈值85%)，而我们是按容器内存60%(9.6G)的比例配置的JVM堆内存。看了下其它服务，同样的堆内存配置，它们内存占用约70%~79%，......
  • 【保护你的上线】风险治理的防范与排查之路 | 京东云技术团队
    前言项目研发的过程中经历了需求评审、开发评审、代码编写、测试用例评审、项目测试、产品和UI验收等一系列流程，其中投入了大量的人力和精力。然而最后的上线阶段，总是存在诸多不确定性和可变性，往往在测试阶段测N次都没有丝毫问题，一上线就会出现Bug（简直是墨菲定律的诅咒）。经过多年的......
  • 表格选中当前行数据，固定高亮显示当前行（防止数据是否选错和更好的排查）
    只需要在表格增加highlight-current-row属性就可以了  ......
  • 排查海康EHOME5.0协议无法注册监控汇聚平台EasyCVR的原因
    EasyCVR平台支持多种协议和设备类型的接入与分发，包括GB28181、RTMP、RTSP/Onvif等安防标准协议，以及海康EHOME、海康SDK、大华SDK等厂家私有协议。同时，它还可以进行RTSP、FLV、HLS、WebRTC等格式视频流的输出和分发。近日，某项目现场使用海康摄像头Ehome5.0接入EasyCVR平台时遇到问题......
  • Centos排查流量异常进程
    简介有时候当服务器出现流量出入过高的时候，需要去如何排查是哪些进程在使用，本文主要记录如何通过相关命令来进行排查。1、基本知识1.1、iftop介绍一般涉及到流量的监控，经常会使用iftop，首先安装iftop：yuminstalliftop-y 使用iftop命令，界面如下： 界面上面显示的是类似......
  • 排查Python卡慢神器
    如果遇到Python正在运行中的进程卡住，找不到原因。可以试试以下工具方法,对于python就像jstack对于java一样。法一使用pystack-debugger安装方式如下：yuminstallgdbpipinstallpystack-debugger1.查看线程IDpsajx|grepgunicorn2.查看堆栈信息,确认有问题代码pystac......
  • Vue3 toRef响应式失效问题排查
    父组件conststuRecordInfo=ref<any>({stuNum:11111})//接口请求返回stuRecordInfo.value.stuNum=22222<StuRecord:info="stuRecordInfo":pictureInfo="pictureInfo"/>子组件constinfo=toRef(props,'info')consts......
  • 视频直播点播平台EasyDSS排查WebRTC搭建TURN服务时openssl路径问题。
    我们曾经介绍了WebRTC所必需的STUN/TURN服务，并尝试了在Windows上搭建TURN服务的过程。为了在Windows上编译并使用TURN服务，我们需要安装Cygwin64环境，并进行相应的配置和编译工作。然而，在我们下载、编译和安装coturn时，遇到了一个报错：“ERROR:OpenSSLCrypto开发库未在所需位置正确安......
  • 记一次CMS GC耗时46.6秒的排查过程与解决方法
    「早上7.16分左右」 ，有个服务发生了紧急告警，很多接口超时，出于 「客户的投诉」 和老板的给出的压力，我开始了排查之旅~~~❝【排查到最后发现，并不是这些超时的接口都有问题，而是 「其中某一个接口影响了整个服务」，只要是这个服务上的接口，都有可能超时、异常、等不正常现象】❞看下......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99