获取MAC地址失败,是什么原因

获取MAC地址失败,是什么原因,第1张

这种情况可能由以下几种原因造成:1、移动设备与WIFI热点间障碍过多,WIFI信号时断时续不稳定,导致连接请求频繁失败;2、无线路由器DHCP服务器自动分配IP地址的IP段过窄,比如将DHCP自动分配的IP段设置成192.168.1.100-192.168.1.101,那么无线路由器就只有两个IP地址可以自动分配,一旦需要自动分配IP地址的接入设备超过2个,第三个接入设备就会获取IP地址失败;3、无线路由器开启了无线设置下的MAC地址过滤,当前设备的MAC地址处在禁止接入WIFI的列表中,所以无法获取有效IP地址接入WIFI;4、无线路由器本身出现系统故障,无法为接入设备分配IP地址。出现这种现象时,可以先将移动设备换个位置或房间试试,要是没有改善就把无线路由器重新启动一遍,试试能否解决问题,若是还无法解决,就需要登录路由器的设置页面检查路由器的内部设置了。

解决方法:

1.打开网络偏好设置,点击“高级…”按钮,进入下面页面,再选择代理选项,如下图

2.取消网页代理、安全网页代理的勾选,如果有其它代理也取消勾选

3.接下来确定应用,再重启 Safari 就可以正常上网啦

起因是某个同事接到了领导安排下来的一个需求,要在一个Web应用(Java+Tomcat)中,记录用户登录时的IP地址和MAC地址,用于安全审计,于是咨询我如何实现。

第一反应是,这个需求本身是不成立的,根据以往的了解,MAC地址应该是过不了路由器的才对。

以往做开发,都是用engineer的思维:先动手做,遇到问题再解决问题。但这个需求,应当用scientist的思维去思考:首先确定能不能做,然后才是怎么做。

翻查了一些资料,想来证实" 为什么WEB服务器,可以获取到客户端的IP地址,但获取不到MAC地址 ",看着看着才发现,这是个挺大的命题,够写一篇BLOG了。

PS:由于个人对这块内容了解的不够彻底, 本文很可能会有谬误 ,请读者先不要太当真,另外希望平台组的同事给予指证。

我所认为的结论应该是这样的:

下面一步步解释一下。

先从HTTP说起。

HTTP是一个应用层的协议,它建立在TCP协议之上。

HTTP请求就是用来发送一段文本。关于这段文本如何组织,第一行写什么,第二行写什么,哪里加一个空行,就是HTTP协议所要规范的内容。

举个直接的例子,下面是一个简单的HTTP GET请求,有兴趣可以用telnet模拟一下。

我们可以看到,HTTP的这段请求中,完全找不到客户端的MAC地址,甚至连IP地址都没有描述。

那IP地址是从哪里取到的呢?接下来我们再深入一点,看下一个内容:Socket

HTTP的客户端和服务端,是通过Socket进行连接的。

Socket是什么呢? Socket是对OSI模型第4层-传输层中的TCP/IP协议的封装 。Socket本身并不是协议,而 是一个调用接口 (API)。Socket和TCP/IP协议没有必然的联系。但通过Socket,我们才能使用TCP/IP协议。应用层不必了解TCP/IP协议细节,直接通过对Socket接口函数的调用完成数据在IP网络的传输。

Socket包含了网络通信必须的五种信息: 连接使用的协议,本地主机的IP地址,本地进程的协议端口,远地主机的IP地址,远地进程的协议端口

所以,因为有了Socket,客户端和服务端完全不需要了解底层细节,直接通过调用Socket来实现就可以了。

这也就是为什么服务器端 可以获取到客户端的IP地址 的原因,因为Socket中包含了远地主机的IP地址。(当然,通过代理服务器进行访问的除外,这种要依靠HTTP协议的X-Forwarded-For头来确认IP,不在本次的讨论范围中)

那为什么 无法获取到客户端的MAC地址 呢?很简单,同理,因为Socket中无法取到MAC地址。。。

如果继续发问,为什么Socket中都既然都包含IP地址了,为什么偏偏不包含MAC地址信息呢?看来我们还要更深入一点,看一下OSI模型吧。

首先祭出这张经典的OSI七层模型图,计算机网络的基石,请先盯着看一会儿,认真复习一下

这里还有一张OSI七层模型与TCP/IP四层模型的对照图

为了方便理解,再放上一张更直观的,每一层对应的数据型式和主要协议的示意图

通过上图大体可以知道:

下面举个栗子,当我们在浏览器中打开一个链接后,看看OSI各层倒底发生了什么:

这里撇开DNS解析之类东西,只说一下HTTP报文的发送

首先来看一下发送端(浏览器所在的主机)。参照第一张OSI模型图,按照从上向下的顺序来看。应用层数据其实只有那么几行文本,然后往下,每过一层,都要被加上首部/尾部。 这个过程就像是一层一层的穿衣服

HTTP请求文本:

数据发出去后,再看一下数据在网络上的流转。

数据一般要经过交换机、路由器等网络设备,层层转发,这些设备所做的事情就像是: 脱掉一件或几件衣服,做一些修修补补,然后再重新穿回去

通过上面这张图,我们就可以理解,MAC地址在本地网络下的重要作用了。也理解了,本地网络下,是可以查出每个节点的MAC地址的。

经过路由器后,为了能到达下一跳,数据链路层中的MAC地址就被篡改了,下面这张图很能说明问题:

最后看一下接收端(WEB服务器所在的主机)。参照第一张OSI模型图,按照从下至上的顺序来看,它要做的事情是: 将衣服一件一件全部脱掉 ,最后WEB服务器就取到了最初的应用层数据。

所以,当一个以太网帧到达目的主机后,其中的MAC地址早已经不是原来客户端的MAC了,操作系统的Socket自然也无法获取原始的MAC地址了。

上面已经证明了,WEB服务端,是无法获取客户端的MAC地址的。

那么,能不能通过一些trick来绕道实现呢?

想了想,大概可以有如下的思路:

那么这个思路可不可行呢?

最后的最后,不禁思考,获取MAC的意义在哪里呢?

如果单纯是为了取证和审计,我想意义是不大的,甚至不如直接记录IP地址。

因为:

所以,一般的安全管控要求下,还是只记录IP吧。


欢迎分享,转载请注明来源:夏雨云

原文地址:https://www.xiayuyun.com/zonghe/764772.html

(0)
打赏 微信扫一扫微信扫一扫 支付宝扫一扫支付宝扫一扫
上一篇 2023-08-19
下一篇2023-08-19

发表评论

登录后才能评论

评论列表(0条)

    保存