地点:某某科技公司
时间:2005年4月10日
故障现象:起初是用户反应无法连上因特网,我用PING命令一查看
C:\Documents and Settings\Sunny>ping 192.168.255.1

Pinging 192.168.255.1 with 32 bytes of data:

Reply from 192.168.255.1: bytes=32 time<1ms TTL=254
Reply from 192.168.255.1: bytes=32 time<1ms TTL=254
Reply from 192.168.255.1: bytes=32 time<1ms TTL=254
Reply from 192.168.255.1: bytes=32 time<1ms TTL=254

Ping statistics for 192.168.255.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
好的啊,到路由器的路径很畅通,然后我PING新浪网,也是通的,可是用户就是没法上网......
不知是何缘故,只好用Sniffer抓包看,发现其中一台机器流量很大
拔掉故障机器的网线,网络就可以正常使用,一接上就不行了
????????
到底是什么原因呢,故障机器上用NETSTAT -AN命令一看,连接了N多台外网IP地址,都是4000以后的断口,看了一下计算机的服务,晕倒.....
几乎所有远程控制的服务都开启了,象终端服务,远程注册表,TELNET等等
一看系统安全日志,几乎是清一色的匿名网络登陆,最后判断已经变成肉鸡了
关掉服务,并杀除了N个木马,总算搞定


但还有个问题没搞清楚,就是为什么能PING通外网和路由器,但却解析不了域名?希望V老大能给个答案

原文中提到“PING新浪网”可以

那么这个动作是不是意味着域名解析已经成功?

与最后的问题有点矛盾...

你ping 新浪,是ping 新浪的ip地址还是ping  www.sina.com.cn

如果是前者当然不能说域名已经解析

其实在dos下可以使用nslookup命令看看网站名是否能解析,这是最简单的

改了你的DNS也说不定，呵呵

ping用的是很小的包（32字节的内容，加上ICMP头、IP头、帧头共74字节），在网络拥塞时或可正常，但上网可能就困难了。由于DNS解析通常也和PING一样用UDP协议，所以我猜测你PING得是新浪的域名，而且确实也通的。另nslookup在WIN98下没有

引用:

Originally posted by wawahaha at 2005-4-21 21:02:
ping用的是很小的包（32字节的内容，加上ICMP头、IP头、帧头共74字节），在网络拥塞时或可正常，但上网可能就困难了。由于DNS解析通常也和PING一样用UDP协议，所以我猜测你PING得是新浪的域名，而且确实也通的。 ...

PING is ICMP, DNS is UDP

谢谢vader的提醒，是我错了，ping确实是icmp。我还写着“32字节的内容，加上ICMP头、IP头、帧头共74字节”，还说PING用的是udp,不好意思

有些病毒或木马不停占用http转换，并且会把NAT地址端口占用完，这样也会造成无法上网
但是同时可以ping通的话就不是很明白了，倒也遇见过，还没做出最终合理解释

通常我遇到的关于可以ping通但是不能上网的个案都是由于安装了个人版防火墙设置不当造成的。
如果是局域网内大部分用户出现这种情况，我都是去查网关设备的日志，看看nat状态表，来定位故障点。但是有时候发现很多源地址是伪装的，查来源很麻烦（开始我们只是把ip和人对应起来了），后来干脆把ip-mac-人都对应起来。

呵呵，漏掉了，我PING的是IP地址，新浪和上海热线都是通的，我的DNS是对的，是上海的DNS，IP是202.96.209.5

恩，我遇到过一次，最过分的是一个客户把自己的计算机ip改成了dns服务器，结果所有人都不能上网

那你可以用sniffer在这台机器上看一下你ping新浪域名的时候这台机器有没有向DNS发出有效的数据包，DNS有没有回应等呀。

边界路由上是个纯路由器吗？  路由器做的NAT?
DNS失败也许，也许是因为NAT条目满了(因为那台主机建立了过多连接)，因此开不出更多的NAT connection 给DNS 的UDP会话。
而ICMP该路由器可能保留了buffer空间，或者采用了不同的机制处理，因此能够正常使用。

因为看到ping响应时间很快，所以排除了路由器cpu load高的猜测，只能猜测NAT的问题。比较好的方式是在路由器两端捕获一下数据，当然，现在已经没机会了

同意V大的说法，我也遇见过类似问题，但是将NAT沾满不是太容易把，因为源地址的端口号是0-65535阿，全沾满需要并发非常多的session的。
但是这个问题现在还没有更好的解释

引用:

Originally posted by Vader at 2005-4-22 12:15 PM:
边界路由上是个纯路由器吗？  路由器做的NAT?
DNS失败也许，也许是因为NAT条目满了(因为那台主机建立了过多连接)，因此开不出更多的NAT connection 给DNS 的UDP会话。
而ICMP该路由器可能保留了buffer空间，或 ...

NAT会话条目跟路由器的CPU没有关系吗？

那么CPU的负载跟哪些东东有关？
吞吐量？会话数？策略数？。。。。。。。

自己写防火墙或者其他东东的时候就会经常
写一个比如说， MAX_CONNECTION  100000，

这样到了极限情况其实是预留内存用完了， 内存余量也可能很多，CPU可能也空闲着

只是就事论事，猜一猜可能性

这样一直讨论下去也没用，可能的原因V大也列举了，究竟是不是这个原因呀，楼主不要光看帖，要做一点事情了。我不说用sniffer看一下了吗。
图1是我打开Baidu网页时与DNS有关的数据包，从这你最起码可以看出来，我的机器确实发送的数据包。至于V大的忧虑，我给个建议吧（哈哈，我只考了CCNA，不要说我喔，要是过了英语四级的话再考CCNP。）要是边缘路由器为cisco的话，通过下面的命令把 NAT Debug功能打开：debug ip nat.看一下路由器有没有给你做NAT，也可以从返回信息上看到DNS有没有回数据包以及路由器有没有给你做反向NAT。如果你发现发送一切正常，接收一切错误的话，强烈建议楼主换DNS地址！换我们长春(现在在长春读书呢，支持一个我喔）的吧：202.96.0.68；202.96.64.68。

[ Last edited by Tinnal on 2005-4-23 at 08:18 ]

我也遇到这个问题啊

呵呵,周末一直有事情,所以没来得及回帖,跟大家说声SORRY
路由器是NAT的,可是当时CPU和内存使用率很小的啊!!!有可能是V老大说的NAT条目已满,可现在用SNIFFER抓包已经不大可能了,环境也被破坏了.
那就等下次吧,谁有机会碰上同样的问题,用SINFFER把包文抓下来分析