追根究底 破解网络访问谜局

网络
大小不一的网络访问谜局经常困扰着从事网络管理维护工作的网管员,本文就几则网络访问谜局的破解过程还原,希望能给各位网络管理员带来帮助。

在网络规模不断扩大的单位,从事网络管理维护工作,的确非常具有挑战性。局域网中千奇百怪、大小不一的网络访问谜局,已经已远远超出了网络管理员的想象。如果不有效采取破解各种网络访问谜局,那么局域网的运行效率势必将会受到严重的影响。为了提高局域网网络的运行效率,本文就为各位还原几则网络访问谜局的破解过程,希望这些内容能给各位网络管理员带来帮助。

谜局1:网络连接规律性掉线

前几天,笔者的一位朋友应聘成为一家广告公司的网络管理员,与前任网络管理员进行了一下简短地交接之后,朋友开始正式走马上任。这家单位的局域网规模适中,总共有50台左右的计算机,分布在单位的五个部门中,每一个部门中的所有计算机都连接到一台二层交换机,之后二层交换机通过光纤线缆级联到单位的核心交换机,再从核心交换机的Uplink端口中引出一条线缆连接到宽带路由器设备上,最后通过ADSL宽带线路连接Internet网络。刚工作没有几天,一则奇怪的网络故障现象就出现在朋友的面前了,具体现象为:单位局域网与Internet网络之间的连接基本隔三个小时左右就会发生一次掉线故障,不过要不了一分钟的时间又能自动连接上,而且这种现象发生时非常有规律。尽管掉线故障持续的时间不长,不过由于这家单位的许多工作都是许多员工通过在线协作方式完成的,局域网网络连接有规律的掉线现象还是对该单位的正常工作带来了不小的影响。

破解谜局

依照上面的故障现象,笔者的朋友认为引起网络连接有规律掉线的因素主要有两方面,一是本地网络的线路连接不稳定,另外一方面就是网络不小心感染了蠕虫病毒。想到这一点,朋友先是联系了本地ISP部门的技术人员,请求他们对本单位的ADSL宽带上网线路进行检查,经过专业技术的人员仔细检查,排除了ADSL宽带上网线路故障,于是朋友又将检查重点转移到网络蠕虫病毒上了。

朋友详细检查了单位局域网中的所有工作站,并没有找到任何病毒。同时经过一系列检测,朋友发现每次网络连接发生有规律的断线现象时,局域网计算机ARP缓存表中的网关MAC地址记录与网络连接没有掉线时相同,这就意味着网络连接有规律掉线现象与ARP欺骗无关。排除了网络连接线路以及网络病毒因素后,朋友一时想不出该从何处下手来解决该网络故障?为了快速、有效地找到故障原因,朋友决定采用区域隔离的方法来解决网络故障。首先,朋友先是关闭了局域网中所有工作站的电源,只让一台笔记本电脑接入到局域网中上网,可是网络掉线故障依旧有规律出现,看来网络有规律掉线故障不是由局域网工作站引起的。

会不会是局域网路由器或交换机设备发生了故障?想到这一点,朋友索性就将自己的笔记本电脑直接与路由器设备相连,结果网络故障依然有规律出现,这说明局域网交换机没有什么问题,问题很可能出现在物理连接线路或路由器身上。为了检验物理连接线路是否正常,笔者朋友又将笔记本电脑直接接入到ADSL设备中,并且在系统中创建了手工拨号连接,并通过该拨号连接尝试上网访问,结果朋友看到先前出现的网络掉线故障一直没有再出现,这就证明单位出口连接线路是通畅的,ADSL设备的工作状态也没有任何问题,故障肯定是由宽带路由器引起的。找到故障原因后,笔者朋友迅速以系统管理员权限登录进局域网路由器的后台管理界面,仔细检查了其中的各项设置参数后,朋友发现路由器的WAN端口参数被设置成了“按需连接,在有访问时自动连接,自动断线等待时间15分钟”,这么一来当局域网中有员工需要访问Internet网络时宽带路由器才会自动拨号上网,如果局域网在15分钟之内没有向外发送上网连接请求时,宽带路由器就会发生掉线现象;朋友立即将WAN端口参数修改成“自动连接,在开机和断线后自动连接”,再进行上网连接测试后,局域网网络连接一直很正常,再也没有出现过有规律掉线故障现象。#p#

谜局2:客户端无法享受DHCP服务

笔者单位的局域网网络规模相对适中,为了有效提高工作站管理效率,笔者特意在局域网中架设了一台DHCP服务器,并通过该DHCP服务器为局域网中的所有工作站自动分配IP地址。平时,局域网中的每一台工作站都能正常访问网络内容,并且网络访问速度也是很稳定的。然而好景不长,在昨天上班的路上,笔者连续接了好几个同事的“求援”电话,都说他们计算机无法上网访问内容了,有的计算机还在系统托盘区域处的“本地连接”图标上弹出了本地连接受限的提示信息。火速赶到故障现场后,笔者发现同事的工作站的确不能正常上网;对于这种故障现象,笔者先是认为故障计算机没有从局域网DHCP服务器那里获得有效的IP地址,从而造成故障计算机的“本地连接”图标上出现了上网连接受限的故障提示!于是,笔者在故障计算机系统中依次单击“开始”/“运行”命令,在弹出的系统运行对话框中执行“cmd”命令,将系统屏幕切换到MS-DOS工作窗口,在该窗口的命令行提示符下输入“ipconfig /all”字符串命令,从其后弹出的结果界面中笔者看到故障计算机的IP地址变成了“169.254.89.126”,而169.254.*.*格式的IP地址往往是Windows系统自动分配给计算机的,很显然“169.254.89.126”地址并不是局域网DHCP服务器分配的,看来客户端工作站没有正常享受到DHCP服务。

破解谜局

既然客户端工作站没有正常享受到DHCP服务,那会不会是局域网DHCP服务器遇到意外了呢?经过检查,笔者发现局域网中的其他部分计算机都能访问网络内容,这就意味着局域网DHCP服务器自身工作状态是正常的。排除了DHCP服务器自身因素后,笔者估计问题很可能出在故障计算机的物理连接上,例如物理连接线缆发生了断裂或短路现象;为了验证自己的猜测,笔者特地找来了专用线缆测试仪,对连接故障计算机的网络线缆进行了连通性测试。测试结果表明,连接故障计算机的网络线缆没有任何问题。之后,笔者使用该网络线缆将笔记本电脑连接到网络中,同时将笔记本电脑的IP地址设置为动态获取,结果笔者发现自己的笔记本电脑上网立即恢复了正常,这说明笔记本电脑已经成功从局域网DHCP服务器中获得了IP地址,并且这也说明故障计算机所连的局域网交换机端口工作状态也是正常的。

既然物理连接线缆没有问题,故障计算机所连交换机的对应端口工作状态正常,局域网DHCP服务器也能正常对外提供服务,那么问题很可能出现在故障计算机系统身上。于是笔者又打开故障计算机系统的运行对话框,并在其中执行“sfc /scannow”字符串命令,开始尝试对故障计算机系统进行文件修复操作,等到文件修复操作结束后,笔者又在故障计算机中尝试了网络访问操作,可是故障现象一切依旧。在万般无奈之下,笔者又一次怀疑到了DHCP服务器“头上”。由于局域网中的部分计算机能够正常享受DHCP服务,惟独少数计算机不能享受DHCP服务,难道是这些故障计算机之前从DHCP服务器那里申请得到的IP地址使用期限已经到期了?想到这一点,笔者立即登录进DHCP服务器所在的主机系统,进入DHCP控制台界面,打开特定作用域的属性设置窗口,经过仔细检查发现确实一部分计算机的租约期限已经到期,笔者迅速将那些已经到期并被锁定的计算机立即解除锁定,最后将局域网DHCP服务器系统重新启动了一下。原以为这样的努力肯定能够解决问题,可是再次上网进行测试时,笔者发现故障计算机还是不能上网,并且使用“ipconfig /all”命令查看故障计算机的IP地址时,发现地址仍然是169.254.*.*格式。这难道是故障计算机的IP地址没有被正确释放出来?不得已,笔者在故障计算机系统中尝试着执行了字符串命令“ipconfig /release”,准备手工释放故障计算机先前使用的IP地址,可是在执行该命令时,系统竟然出现了Remote Procedure Call系统服务调用出现错误的提示信息,难道是故障计算机的RPC系统服务被意外关闭运行了?笔者清楚,客户端系统的DHCP Client服务对RPC服务有依赖关系,要是RPC系统服被关闭,那么DHCP Client系统服务自然就不能正常启动,那么客户端系统也就没办法享受到DHCP服务了。于是,笔者立即依次单击“开始”/“运行”命令,在弹出的系统运行框中执行“sevices.msc”命令,打开故障计算机的系统服务列表窗口,从中找到系统服务“Remote Procedure Call(RPC)”并进入该服务的属性界面,结果果然发现RPC系统服务被关闭运行了,故障原因终于找到了。

笔者马上将关闭运行的RPC系统服务重新启动成功,之后又尝试着手工启动了DHCP Client系统服务,在确认上面的系统服务都启动成功后,笔者又使用“ipconfig /all”命令查看了故障计算机目前的IP地址,结果发现故障计算机已经从局域网DHCP服务器那里申请得到了有效的IP地址,联网进行测试后,笔者看到故障计算机终于能够成功上网了。按照相同的解决方法,笔者又将其他几位不能上网的计算机网络连接状态恢复正常了,至此客户端无法享受DHCP服务的故障现象就被全部解决了。但是到了这里,笔者还是有一点想不通:为什么位于不同办公室中的计算机会出现相同的网络故障呢?询问其中一位同事后得知,原来这位同事不知道从哪里弄来了一款系统优化工具,不但使用该工具优化了自己的计算机,而且还帮助其他几位同事进行了优化。结果可想而知,凡是受到过这位同事帮助的计算机,都不约而同地出现了客户端无法享受DHCP服务的故障现象。#p#

谜局3:共享访问出现参数错误

某单位所有计算机都处于一个没有域的工作组中,工作组中的计算机时常会受到来自局域网蠕虫病毒的偷袭。有部分员工将笔记本电脑从家庭网络带到单位局域网中后,没有多长时间,单位局域网中的所有计算机都感染了来自家庭网络中的病毒。出于保护自己计算机的需要,许多员工开始安装某个防火墙的破解版,以禁止网络病毒袭击自己的计算机。后来,大家发现这样的保护效果不错,纷纷开始仿效,都在自己的计算机中安装了防火墙程序,原本以为这样能够相安无事;可是,当用户尝试通过网络邻居窗口访问局域网中的其他计算机共享资源或共享打印机时,却遇到了大问题。局域网中的共享资源不但不能正常访问,有时还会出现类似参数错误这样的故障提示,在启用网络防火墙的情况下,局域网中的网络打印机也不能正常使用。

破解谜局

大家知道,Internet网络中的许多蠕虫病毒正是利用了网络邻居互相访问的共享端口实施破坏攻击的,一旦局域网计算机中启用了防火墙程序后,那么防火墙程序可能就会自动将蠕虫病毒使用的共享访问端口关闭掉了,那样一来用户通过网络邻居窗口访问局域网中的共享资源时自然就容易出错了。为了既能防范蠕虫病毒的袭击,又能保证正常进行共享资源的访问,我们应该正确安装最新版本的杀毒软件,及时更新安装Windows系统漏洞补丁程序,然后使用正版的防火墙程序,并对防火墙的参数进行针对性调整,相信这么一来就能达到目的了。

当然,有的时候我们即使进行了上述设置,在进行共享访问时仍然有可能出现参数错误的提示信息,此时多半是Windows系统中的TCP/IP协议发生了错误,或者是相关的系统文件被杀毒软件意外删除。要解决这种类型的故障现象,最简单、最直接的方法往往就是重新安装一遍TCP/IP通信协议,在重装TCP/IP通信协议时可以按照如下方法来进行:

对于Windows XP之前版本的系统来说,我们只要先打开网络连接属性设置窗口,找到TCP/IP通信协议,并单击“删除”按钮,就能将TCP/IP通信协议从系统中卸载掉了,之后再单击“安装”按钮进行重新安装就可以了。

对于Windows XP、Windows 2003系统来说,我们可以依次单击“开始”/“运行”命令,在弹出的系统运行对话框中执行“cmd”命令,将系统屏幕切换到MS-DOS工作窗口,并在该窗口的命令行状态下输入字符串命令“netsh int ip reset resetlog.txt”,单击回车键后,故障计算机系统的TCP/IP通信协议工作状态就能恢复正常了。#p#

谜局4:防火墙“启用”按钮失效

为了保护本地计算机的安全,许多人在Windows XP以上版本的系统中上网冲浪时,往往会启用系统内置的Windows防火墙,来阻止网络病毒的非法袭击。在许多人眼里,启用防火墙功能绝对是一件非常简单的事情,事实上有的时候,我们打开系统防火墙的参数配置界面时,会看到其中的“启用”按钮处于不可点击状态,这是什么回事呢,我们该如何才能让系统防火墙的参数设置状态恢复正常呢?

破解谜局

实际上,Windows XP以上版本系统在默认状态下会允许系统用户随意启用防火墙并对其参数进行任意调整的,要是我们发现系统自带防火墙的“启用”功能按钮失效时,那多半是本地计算机在长时间运行后,与系统防火墙有关的服务被意外关闭了。此时,我们不妨依照下面的步骤,来看看与系统防火墙有关的服务——“Windows Firewall/Internet Connection Sharing(ICS)”是否被正常启用了:

首先以系统管理员权限进入本地计算机系统,用鼠标右键单击系统桌面中的“我的电脑”图标,并执行右键菜单中的“管理”命令,在弹出的计算机管理窗口,选中左侧列表区域中的“计算机管理”节点选项,在对应该节点选项下面依次展开“服务和应用程序”/“服务”分支选项;

其次在“服务”分支选项下面,找到“Windows Firewall/Internet Connection Sharing(ICS)”目标系统服务,并用鼠标右键单击该服务选项,从弹出的右键菜单中执行“属性”命令,进入“Windows Firewall/Internet Connection Sharing(ICS)”服务的属性配置界面;

单击该配置界面中的“常规”选项卡,在对应的选项设置页面中,我们就能清楚地知道当前系统防火墙服务工作状态是否正常了,要是发现该系统服务工作状态不正常时,我们只要单击对应选项设置页面中的“启动”按钮,来将该系统服务先启动起来;为了保证“Windows Firewall/Internet Connection Sharing(ICS)”服务下次能够跟随Windows系统自行启动,我们还需要将该系统服务修改为“自动”启动类型,最后单击“确定”按钮退出“Windows Firewall/Internet Connection Sharing(ICS)”服务的属性配置界面,这样的话防火墙“启用”按钮失效故障就能被解决了。#p#

谜局5:数据掉包现象非常严重

最近,某公司中的一个部门员工向局域网管理员反映,他们部门中的一些计算机访问公司服务器的速度非常缓慢,向服务器上传文本信息或下载文本信息时的速度还可以,倘若向服务器上载或下载一些大容量的多媒体内容时,那传输速度就比较缓慢了,严重的时候干脆就连接不上。为此,公司网络管理员先在其中一台故障计算机中执行ping命令对局域网服务器的连通情况进行了测试,测试结果发现有时大容量的数据包存在比较严重的延时现象,而且大容量数据包在网络传输过程中存在比较严重的掉包现象。考虑到该部门的局域网组网结构是所有计算机全部通过普通双绞线缆连接到局域网10M集线器上,而10M集线器又通过级联方式连接到了局域网核心交换机上,核心交换机的每一个连接端口工作状态都处于10M/100M自适应状态,局域网服务器同时也连接到核心交换机上了。

破解谜局

根据上面的故障现象,公司的网络管理员先尝试着将故障计算机直接连接到单位的核心交换机上,而跳过了与局域网10M集线器的连接,连接好之后又在故障计算机系统中Ping了一下服务器系统的IP地址,测试结果表明大容量数据包延时现象已经消失了,并且在较长的一段时间内都没有再出现过数据掉包现象。接下来,网络管理员又到那些安装了10M旧网卡的计算机中ping了一下服务器,结果发现Ping命令成功被执行;经过仔细对比,网络管理员发现发生故障的计算机几乎都是使用了100M的新网卡,对于这点发现网络管理员进行了反复分析,有没有可能是故障计算机与局域网交换机的传输速度不匹配呢?想到这一点,网络管理员特地对故障计算机的100M网卡设备工作速度进行了调整,并将其强制修改为10M,修改完毕后再次进行上网测试,结果发现数据掉包现象已经消失了,很显然上面的故障现象确实是由于计算机与局域网交换机的传输速度不匹配引起的。

【编辑推荐】

  1. 如何利用静态路由实现网络访问控制
  2. 实现高效安全的网络访问控制的解决方案
责任编辑:许凤丽 来源: IT专家网
相关推荐

2024-01-05 13:20:25

2020-07-06 08:15:59

SQLSELECT优化

2024-01-10 18:49:47

2018-09-27 12:38:46

Python同步异步

2010-04-28 15:52:15

数据流负载均衡

2009-10-20 10:19:36

2012-03-22 17:07:03

阿里巴巴私有化

2010-05-12 10:19:14

英特尔安腾谜局

2009-02-27 09:44:00

2010-02-04 14:18:32

2010-02-03 10:44:47

2009-07-08 15:57:43

2010-09-28 09:40:17

IBMBlade

2020-04-17 14:19:11

人脸识别技术安全

2023-05-09 16:02:14

人工智能ChatGPT

2010-02-03 11:23:54

2009-05-18 09:31:00

2010-12-30 12:41:50

2011-06-02 16:53:22

2009-07-17 09:05:23

点赞
收藏

51CTO技术栈公众号