路由器做NAT,一段时间后某一客户端无法上网问题解决方法。-阿里云开发者社区

开发者社区> 安全> 正文
登录阅读全文

路由器做NAT,一段时间后某一客户端无法上网问题解决方法。

简介:

症状:
1、路由器能ping通外网,客户端能ping通路由器但无法ping通外网
2、客户端随便更换一个IP后能够上网,但是改回以前的IP就又不能上网
3、在路由器上使用clear ip nat translation * 命令后,客户端立刻能够上网

分析:
路由器能ping通外网,证明路由器上的设置都没错,能够正常和外网连接
客户机换IP能够上网证明客户机自身也没有问题
路由器上清空NAT条目之后,客户机立即恢复正常
由此分析可能是由于时间一长NAT条目过多,造成路由器的故障,可以通过以下命令减少NAT条目数和TCP连接超时等命令:

ip kerberos source-interface any
ip nat translation timeout 3000
ip nat translation tcp-timeout 500
ip nat translation udp-timeout 30
ip nat translation finrst-timeout 30
ip nat translation syn-timeout 30
ip nat translation dns-timeout 30
ip nat translation icmp-timeout 30
ip nat translation max-entries 24000

==========================================================
以上思路参考以下文章:

由于在CATALYST6509上配置了基于端口的NAT功能,一旦校园网内某台感染“红色代码”病毒的IIS服务器向外发起攻击,或某人使用端口扫描工具不断地发起针对各个TCP和UDP端口的试探连接,6509都会为每个TCP或UDP连接在它的地址翻译表中建立一条基于端口复用的连接,这样一来,随着攻击的进行,NAT表里维持的连接数会越来越多,直到耗尽CPU利用率。这时,让我们看一下CATLYST6509的情况: 
CAT6509#sh ip nat statistics 
Total active translations: 18404 (0 static, 18404 dynamic; 18372 extended) 
Outside interfaces: 
Vlan3, Vlan5 
Inside interfaces: 
Vlan10, Vlan12, Vlan103, Vlan108, Vlan109, Vlan165, Vlan166 
Hits: 979206714 Misses: 9323076
Expired translations: 10650887
Dynamic mappings:
-- Inside Source
access-list 1 pool teachers refcount 9269
pool teachers: netmask 255.255.255.224
start 210.83.X.X end 210.83.X.X
type generic, total addresses 28, allocated 28 (100%), misses 34659
access-list 2 pool students refcount 9135
pool students: netmask 255.255.255.240
start 210.83.X.X end 210.83.X.X
type generic, total addresses 13, allocated 13 (100%), misses 194892
NAT表里的连接数已经达到1万8千多条!这基本是CPU处理能力的极限(还要看数据包的流量)。
CAT6509#sh ip nat tr

tcp 210.83.X.X:1248 192.168.0.226:1039 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1274 192.168.0.226:1049 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1253 192.168.0.226:1040 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1255 192.168.0.226:1088 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1257 192.168.0.226:1089 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1258 192.168.0.226:1041 61.139.8.X:80 61.139.8.X:80
tcp 210.83.X.X:1264 192.168.0.226:1066 61.139.8.X:80 61.139.8.X:80

从输出里可见,大部分连接都是192.168.0.226这台机器发起的,使用下面的命令可以看得更清楚:
CAT6509#sh ip nat tr | include 192.168.0.226
(输出略)
那么如何解决这个问题? 
需要使用下面的一系列命令: 
CAT6509(conf)#ip nat translation max-entries 12000
   //把NAT表里的连接数限制到12000条,防止达到处理能力的极限,造成全瘫。

CAT6509(conf)#ip nat translation icmp-timeout 10 
   //ICMP连接的空闲时限是60秒,现在把它设为10秒,这样可以使空闲10秒的ICMP连接被及时清除出NAT表,防止NAT表里的连接数被“虚占其位”的ICMP空闲连接搞得迅速增长,耗尽CPU资源。

CAT6509(conf)#ip nat translation udp-timeout 20 
   //UDP连接的空闲时限是300秒,现在把它设为20秒,原因同前面一样。

CAT6509(conf)#ip nat translation syn-timeout 15 
   //设置发出TCP连接请求数据包后,等待握手应答的空闲时间,缺省是60秒,现在设为15秒。由于“红色代码”病毒是以一种漫无目的方式发起TCP连接,许多目的地址是不存在的,或是没有运行IIS系统,所以根本没有应答。设置发出TCP连接请求数据包后,等待握手应答的空闲时间为15秒,可以使空闲15秒的TCP发起连接被及时清除出NAT表。

CAT6509(conf)#ip nat translation tcp-timeout 300 
   //设置当TCP连接经过三次握手建立起来后,连接没有数据流的空闲时限,缺省为24小时,现在设为5分钟,这样可以使空闲300秒的TCP连接被及时清除出NAT表,同样防止NAT表里的连接数被“虚占其位”的TCP空闲连接搞得迅速增长,耗尽CPU资源。 
应用上述配置后, 从实际效果上看,确实起了作用,6509抗攻击能力显著提高。 
--------------------------------------------------------------------------------
看看一个在cisco4000上的配置
ip kerberos source-interface any
ip nat translation timeout 3000
ip nat translation tcp-timeout 500
ip nat translation udp-timeout 30
ip nat translation finrst-timeout 30
ip nat translation syn-timeout 30
ip nat translation dns-timeout 30
ip nat translation icmp-timeout 30
ip nat translation max-entries 24000
ip nat inside source list 1 interface Ethernet0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 221.237.163.1
ip route 210.6.0.0 255.255.0.0 10.1.1.3
no ip http server
!
access-list 1 permit 10.1.0.0 0.0.255.255
access-list 1 permit 211.83.0.0 0.0.255.255
access-list 1 permit 192.168.0.0 0.0.255.255
access-list 1 permit 210.6.0.0 0.0.255.255










本文转自 qq8658868 51CTO博客,原文链接:http://blog.51cto.com/hujizhou/1186355,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章
最新文章
相关文章