windows的双网卡问题


################################################################################
张贺,一只IT小小鸟,目前在一家科技公司做运维,和大多数一样,一个普普通通的人。
个人网站:https://www.zhanghehe.cn
个人博客:https://www.cnblogs.com/yizhangheka
################################################################################

双网卡问题

问题

环境介绍:

如上图所示,PC-A有两卡网卡,注意,网卡一设置有默认网关,网卡的默认网关位于路由器的某个接口上,而网卡二并没有网关,网卡二只有IP和掩码,;PC-B的默认网关也在路由器某个接口上;

问题一

我当前在PC-A上运行ping命令,如下所示:

ping -n 1 192.168.1.30
  • PC-A所ping的192.168.1.30是面板?还是PC-B?

这种问题不能在模拟器上做实验,模拟器虽然仿真程度高,但还没做到可以媲美真实环境;这种问题还是得正儿八经的用真实的环境,真实的windows电脑,真实交换机和路由器。为了保证实验的真实性,每一步操作之后都会通过arp -d 清空一下arp缓存。

PC-A的操作:
# arp -d 清空arp缓存
PS C:\Windows\system32> arp -d

# ping -n 1 是指定ping 的次数为1次
PS C:\Windows\system32> ping -n 1 192.168.1.30
正在 Ping 192.168.1.30 具有 32 字节的数据:
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128

192.168.1.30 的 Ping 统计信息:
    数据包: 已发送 = 1,已接收 = 1,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms,最长 = 0ms,平均 = 0ms

PS C:\Windows\system32> arp -a | findstr "192.168.1.30"
  192.168.1.30          00-08-0a-0d-0d-b8     ??   # 注意这这里,此MAC就是面板机网卡的MAC地址;

通过上述操作,我们发现当我们ping 192.168.1.30的时候,响应的是面板机,这与我们所理解的情况是一样的,我们可以再进一步操作,在ping的同时加上-t,如下所示,我们得到的结果与上述是一样的;

PC-A的操作:
PS C:\Windows\system32> arp -d
PS C:\Windows\system32> ping 192.168.1.30 -t

正在 Ping 192.168.1.30 具有 32 字节的数据:
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128
来自 192.168.1.30 的回复: 字节=32 时间=1ms TTL=128
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=128

PS C:\Windows\system32> arp -a | findstr "192.168.1.30"
  192.168.1.30          00-08-0a-0d-0d-b8     ??

我们可以再进一步验证,在pc-a在ping的时候,我们在它的网卡二上进行抓包,如下所示:

通过上述几步操作,充分说明了,当我们在PC-A上ping 192.168.1.30,参与应答的就是面板机。

问题二

PC-A网卡二所在网络内部只有两台主机,一台是PC-A本身,另一个就是面板机,如果现在面板机的IP地址被改成了192.168.1.31,那pc-a再ping 192.168.1.30的时候会发现什么情况?

PS C:\Windows\system32> arp -d
PS C:\Windows\system32> ping -n 1 192.168.1.30

正在 Ping 192.168.1.30 具有 32 字节的数据:
来自 192.168.1.2 的回复: 无法访问目标主机。

192.168.1.30 的 Ping 统计信息:
    数据包: 已发送 = 1,已接收 = 1,丢失 = 0 (0% 丢失),

我们在PC-A的网卡二上抓包会发现,网卡二向其所在的网络发现了三次arp广播,没有回应,于是判断无法访问目标主机。

那如果我们将ping -n 改成2呢?

PS C:\Windows\system32> arp -d
PS C:\Windows\system32> ping -n 2 192.168.1.30

正在 Ping 192.168.1.30 具有 32 字节的数据:
来自 192.168.1.2 的回复: 无法访问目标主机。
来自 192.168.1.30 的回复: 字节=32 时间<1ms TTL=63

192.168.1.30 的 Ping 统计信息:
    数据包: 已发送 = 2,已接收 = 2,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms,最长 = 0ms,平均 = 0ms

PS C:\Windows\system32> arp -a | findstr "192.168.1.30"
PS C:\Windows\system32> arp -a | findstr "10.100.12.1"
??: 10.100.12.11 --- 0x3
  10.100.12.1           80-e4-55-f5-d8-68     ??

注意,问题出现了,我们发现第二个包竟然是通了,但我们通过arp表项查看192.168.1.30,发现是空的,这说明什么?这说明此时的192.168.1.30与自己不是同一个网段,而是跨网段通信的,PC-A将请求将给了网关,arp表项里面只有网关的mac,没有192.168.1.30的具体mac;

上面的抓包是在PC-A的网卡二上进行抓的,说明电脑第一反应还是正常的,还是从自己网卡二的网络当中去找192.168.1.30,当电脑发现通过网卡二无法找到192.168.1.30的时候,转而向网卡一进行“求助”,根据通信原则,网卡一介入处理PC-A通往192.168.1.30的报文,于是网卡一将其交给网关处理,我们可以在运行ping -n 2 192.168.1.30网卡一上也抓包验证一下,如下所示:

总结

当我们在PC-A上运行ping -n 1 192.168.1.30的时候,PC-A确实会遵循通信原则,判断192.168.1.30与自己的网卡二处于一个网段,所以会从网卡二向192.168.1.30发出三次arp请求,如果这三次arp有任意一次应答,那就是通的,如果三次没有一次应答,那就是不通的。

当拓扑变成了这样:

我们再在PC-A运行ping -n 1 192.168.1.30,这时候PC-A还是会通过网卡二做三次的arp广播,有回答则通,反之刚不通;但是如果我们ping 192.168.1.30 -t的话,我们会发现在第二个包的时候会通,为什么?这是因为windows系统运行机制所决定的,windows这种成熟的操作系统还是恪守了通信的基本原则,但没有死守,当windows通过网卡二发送了三次arp请求之后,发现没有回答,立马将任务交于另一个网卡,而另一个网卡也会根据通信原则重新做判断,网卡一根据通信原则发现192.168.1.30与自己的网卡不是一个网段,但网卡一有网关,于是将数据包交给网关,网关再交给PC-B,PC-B成功应答;

问题三

当我在PC-A通过nmap的ping scan方法扫描192.168.1.0/24整个网网段的时候结果相当之”单纯“,就只有网卡二所接入网络内的所有的主机,就仅仅发了一次arp广播,比windows系统本身还要少两次,windows默认是三次,但这并不能说明nmap不好用,只能说nmap为了实现高速扫描目的在一定程度上牺牲了准确性,但nmap扫描的也挺准的,好像准确性也没有收到什么影响,如下图抓包所示:

我同事使用另一种扫描工具,不仅会把网卡二所接的网络内的主机列出来,还会将路由器另一侧同样的是192.168.1.0/24网段内主机给列出来,是因为我同事使用的那个工具是调用的windows自带的ping,而且起码ping的次数是二次,每一次是三次arp广播,前三个arp广播会发到网卡二所在的网段,而后三个就会交给网卡一处理,自然就会把路由器另一侧属于192.168.1.0/24网段的主机给列出来。

我们会发现windows是很灵活的,如果有多个网卡,此路不通,会另走他路。那还有没有类似的机制?我们在通过ssh登录linux的时候,ssh的服务器会向DNS发起一个PTR反向地址解析请求,如果第一个没有请求到结果,会再发一次,如果第二次还没请求到,就不再使用DNS解析了,ssh服务端就选择别的路径,允许使用客户端使用IP地址直接进行登录,这是我通过windows这种灵活的机制联想到的,当然这也是ssh登录linux初始时会卡顿几秒的原因,关于ssh卡顿的问题后续会专门写在wireshark抓包的专题当中。

原文地址:https://www.cnblogs.com/yizhangheka/p/15613040.html