【IT168 专稿】很多时候，我们会看到工作站的系统托盘区域处，弹出“本地连接受到限制或无连接”的故障提示，此时尝试进行网络访问时，我们会发现网络连接失败。遇到类似“无连接”的故障提示时，相信许多网络管理员都会下意识地认为本地网络连接出现了线路短接或接触不良的问题。

    不过，当我们将各种可能因素仔细排查之后，发现“无连接”故障仍然无法被成功解决。此时，我们应该从一些细小因素出发，着眼“无连接”故障现象，进行仔细筛选排查，相信一定能够找到故障原因，并顺利能够将故障现象排除掉的！

    故障现象

    今天，笔者一到办公室，就接到隔壁处室同事小孟打来的电话，说今天他的工作站无法登录进单位的电子政务系统了。接到电话后，笔者立即风风火火地来到同事小孟的办公室，对故障现场进行仔细勘察。登录进小孟的工作站系统后，笔者看到该系统托盘区域处出现有“无连接”的故障提示，而且本地连接图标上还显示有黄色感叹号标志！

    故障分析

    见到这种故障现象，笔者立即尝试着将连接故障工作站的线缆从RJ45接口中拔出来，然后重新用力插入到网卡设备的连接端口中，可是在确保网络连接接口接触可靠的情况下，系统托盘区域处的“无连接”故障提示还没有消除。有没有可能是网络线缆出现了短路，或者其他不畅通的故障呢？

    考虑到这一点，笔者立即从朋友那里借来了专业的网络线缆测试仪器，经过仔细测试连接故障工作站的那条线缆，笔者发现该线缆处于正常的连通状态，这说明“无连接”故障现象与网络线缆也没有关系。

    笔者还是有点不放心，特意跑到交换机那里，将连接故障工作站的网络连接线缆换插到交换机其他的工作端口中，可是接连换插了几个连接端口，故障工作站中出现的“无连接”故障提示还是没有消除，很明显该网络故障与线路连接无关。

    在排除了线路连接因素后，笔者开始将目光“瞄”向故障工作站本身。会不会是故障工作站系统突然遭遇到了网络病毒袭击，从而导致了网络访问突然不正常呢？由于网络病毒什么事情都能做得出来，不将网络病毒因素排除掉，那么“无连接”故障将很难被排除掉。

    想到这一点，笔者又辛辛苦苦地跑到自己办公室中，找出单位新买的瑞星正版杀毒软件，之后又开始安装软件、在线升级病毒库、查杀病毒，在经过了很长时间后，终于将故障工作站中的所有网络病毒以及潜藏的木马程序全部清除干净了，原以为这样的努力会将问题解决掉，可现实却很让笔者失望不已，本地连接图标上的那个黄色感叹号标志竟然还没有消失。

    既然故障工作站系统中的病毒全部被清除干净了，网络故障还没有被解决，那问题很可能是本地工作站的上网参数被改动过了。考虑到单位的所有工作站都是通过局域网中的DHCP服务器来自动得到合法IP地址的，既然系统提示出现“无连接”现象，那会不会是本地工作站没有从DHCP服务器那里获得有效的IP地址呢？

    为了检验小孟的工作站是否得到了合法的IP地址，笔者在该系统桌面中用鼠标逐一展开“开始”、“运行”命令，在弹出的系统运行对话框执行“cmd”字符串命令，将系统屏幕切换到MS-DOS窗口。

    在该窗口的DOS命令行中，输入字符串命令“ipconfig /all”，单击回车键后，笔者竟然从其后出现的结果界面中看到本地工作站的IP地址为“169.254.0.37”，而事实上单位局域网的网络地址应该为“10.176.163.0”，那么故障工作站的IP地址为什么会变成“169.254.0.37”呢？

    到网上搜索相关信息后，笔者发现以“169.254”开头的IP地址其实是微软公司的保留地址，当本地工作站系统启用了DHCP服务方式而又无法从局域网的DHCP服务器中获得有效IP地址的时候，Windows系统就会自动临时分配一个169.254.x.x的B类地址给本地工作站，这样一来本地工作站就不处于单位局域网中了。那么究竟是什么因素导致了故障工作站无法从局域网的DHCP服务器中获得有效IP地址的呢？

    考虑到之前笔者已经测试过网络线缆的连通性，而且排除掉了系统自身病毒因素，为此笔者估计很可能是单位局域网的DHCP服务器出现了什么问题。

    于是，笔者又迅速来到单位机房的DHCP服务器旁，以超级管理员权限登录进该服务器系统中后，依次单击“开始”/“设置”/“控制面板”命令，在弹出的系统控制面板窗口中，双击“管理工具”图标，再在其后界面中双击“DHCP”图标，进入到DHCP服务器控制台界面；在该界面中，笔者仔细检查了DHCP服务器的各项设置，都没有找到可疑的问题；后来，笔者打开如下图所示的界面。

    又查看了DHCP服务器的地址池参数以及作用域参数，都没有找到任何问题，但笔者还是不放心，特地将故障工作站在DHCP服务器中留下来的相关记录信息全部删除，同时刷新了一下DHCP服务器系统。

    紧接着，笔者重新来到了故障工作站现场，并在该系统中执行字符串命令“inconfig /release”，这样故障工作站先前从DHCP服务器中获得的IP地址就被成功释放了出来。

    之后，笔者在DOS命令行中再次执行了字符串命令“inconfig /renew”，以便让该故障工作站能够从DHCP服务器中重新获得有效的IP地址，可是在执行该命令时，笔者看到系统竟然出现了无法调用RPC系统服务的错误提示，会不会是该系统服务的意外关闭导致了“无连接”网络故障呢？

    笔者立即用鼠标右键单击系统桌面中的“我的电脑”图标，从弹出的快捷菜单中执行“管理”命令，打开本地系统的计算机管理窗口；在该管理窗口的左侧显示区域，笔者依次展开“服务和应用程序”/“服务”分支选项，在对应“服务”分支选项的右侧显示区域中，用鼠标双击Remote Procedure Call (RPC) Locator服务选项，在其后出现的服务属性界面中（如下图所示）。

    笔者看到该服务的确已经处于停止使用状态，于是笔者毫不犹豫地单击“启动”按钮将该服务重新启动了起来；为了防止该服务下次又会自动停止运行，笔者还特意将它的启动类型设置为“自动”，最后又重新启动了一下故障工作站系统。然而，让笔者感到非常遗憾的是，当再次在故障工作站系统中执行“inconfig /renew”字符串命令时，故障工作站仍然无法获得有效的IP地址。

    笔者不甘心，又打开了Remote Procedure Call服务的属性设置界面，从该界面的“常规”标签页面中，笔者看到该系统服务运行正常。

    后来，在该属性界面的“依存关系”标签页面中，笔者还看到许多系统服务都与RPC系统服务有关，特别是DHCP Server服务和DHCP Client服务也与RPC系统服务有关，而DHCP Client服务不正是决定工作站能否从DHCP服务器中获得IP地址的关键因素吗？看到DHCP Client服务的“身影”后，笔者一下子兴奋了起来，会不会是故障工作站中的DHCP Client服务被停止使用了呢？

    想到这里，笔者用鼠标双击DHCP Client服务选项，在其后出现的服务属性界面中，笔者果然看到该系统服务已经处于停止运行状态，很明显该服务被停用后，本地工作站自然无法从局域网的DHCP服务器中得到合法的IP地址。

    找到了故障原因后，笔者迅速将该服务重新启用起来，之后再次执行“inconfig /renew”字符串命令，确保故障工作站能够重新从DHCP服务器那里申请得到有效的IP地址。在执行完上述命令后，笔者又在故障工作站中进行了网络访问，结果Windows系统已经能够访问到本单位的电子政务系统了。到了这里，“无连接”的网络故障就被顺利解决了。

    故障深究

    虽然同事小孟的工作站已经能够正常访问单位的电子政务系统了，可是笔者到此时还没有搞清楚为什么RPC系统服务以及DHCP Client服务会被停止运行，因为在默认状态下普通工作站是启用这两个服务的，为什么它们会被突然关闭运行呢？

    就在笔者一筹莫展之时，同事小孟突然发话说“今天出现的网络故障，会不会与我使用系统优化工具有关呀”？

    听到此话，笔者心理顿时豁然开朗，认为RPC系统服务以及DHCP Client服务的运行状态肯定是系统优化工具关闭的，毕竟在没有使用优化工具之前，同事小孟的工作站一直能够正常访问单位的电子政务系统。很明显，本文中提到的“无连接”网络故障，其实是由系统优化不当引起的；所以，日后遇到无法解释的网络故障现象时，我们应该多留心系统优化之类的小细节。