非常有意思的策略地址转换故障排查

某客户要求本地主机A(10.1.1.1)新增访问需求,原主机A在边界路由器将地址转换为A1(23.1.1.30)后访问外联单位的主机B(1.1.1.1),现新增加一个系统C(3.3.3.3),需要将地址转换为A2(23.1.1.31)去访问。如下图所示网络结构,R3模拟外联单位路由器,R4模拟互联网;

简单来说就是一个策略NAT:

A(10.1.1.1)-》B(1.1.1.1)将A地址转换为23.1.1.30

A(10.1.1.1)-》B(3.3.3.3)将A地址转换为23.1.1.31

首先定义匹配策略,需要定义源和目的,使用扩展访问控制列表:

ip access-listextended nat30

permit ip host 10.1.1.1 host 1.1.1.1

ip access-listextended nat31

permit ip host 10.1.1.1 host 3.3.3.3

然后定义route-map:

route-map nat30permit 10

match ip address nat30

route-map nat31permit 10

match ip address nat31

最后定义nat:

ip nat insidesource static 10.1.1.1 23.1.1.30 route-map nat30

ip nat insidesource static 10.1.1.1 23.1.1.31 route-map nat31

然后进行测试,竟然不通!!!

然后进行测试,竟然不通!!!

然后进行测试,竟然不通!!!

由于是生产环境,无法抓包,无法debug….

自己检查了几遍IP地址、调用的策略名等没有任何问题,命令放入IOS同版本的模拟器去执行,测试无问题!

Show ip access 检查匹配项,竟然无匹配,说明问题出在匹配上,继续检查acl、IP地址等等等等……

开始怀疑其它nat转换影响了该策略转换,发现现网配置里有这么一条:

ip nat pool nat100 23.1.1.100 23.1.1.100 netmask255.255.255.255

access-list 110permit ip host 10.1.1.1 any

ip nat insidesource list 110 pool nat100 overload

也就是说本网段访问其它地址时会被转换成23.1.1.100的PAT,在直觉中,策略的静态一对一转换转换应该会优于PAT吧。。。

但是在access-list 110中插入deny iphost 10.1.1.1 host 1.1.1.1和deny ip host 10.1.1.1 host 3.3.3.3后测试,没有任何问题!

难道是PAT优先静态转换?

找到问题所在就好,测试了另外一种转换方式也可以实现:

ip nat pool nat3023.1.1.30 23.1.1.30 netmask 255.255.255.0

ip nat pool nat3123.1.1.31 23.1.1.31 netmask 255.255.255.0

access-list 130permit ip host 10.1.1.1 host 23.1.1.30

access-list 131permit ip host 10.1.1.1 host 23.1.1.31

ip nat insidesource list 130 pool nat30 overload

ip nat insidesource list 131 pool nat31 overload

看来都是pat,大家级别一样了,就最小匹配啦!

那么留给大家的问题是,这两种实现方式在实际应用中有什么区别呢?

使用静态route-map的转换方式,可以用于对端需要主动发起访问的情况,这样当对端1.1.1.1或3.3.3.3可以主动访问23.1.1.30或23.1.1.31。

时间: 2024-10-19 04:12:49

非常有意思的策略地址转换故障排查的相关文章

JVM 线上故障排查基本操作

# 前言 对于后端程序员,特别是 Java 程序员来讲,排查线上问题是不可避免的.各种 CPU 飚高,内存溢出,频繁 GC 等等,这些都是令人头疼的问题.楼主同样也遇到过这些问题,那么,遇到这些问题该如何解决呢? 首先,出现问题,肯定要先定位问题所在,然后分析问题原因,再然后解决问题,最后进行总结,防止下次再次出现. 今天的文章,就如我们的题目一样,讲的是基本操作,也就是一些排查线上问题的基本方法.为什么这么说呢?因为线上问题千奇百怪,就算是身经百战的专家也会遇到棘手的问题,因此不可能在一篇文章

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程(高俊峰)

51CTO学习笔记--Linux运维故障排查思路与系统调优技巧视频课程 第一课 Linux运维经验分享与思路 1.一般把主机名,写到hosts下    127.0.0.1    hostname,因为很多应用要解析到本地.oracle没有这个解析可能启动不了. 2.注释掉UUID以及MAC地址,需要绑定网卡的时候,这个可能会有影响. 3.磁盘满了无法启动,  var下木有空间,无法创创建PID等文件,导致文件无法启动,按e   进入single  然后b  重启进入单用户模式. 4.ssh登陆系

MPLS VPN 故障排查详解—Yeslab 彭Sir笔记

Technorati 标签: CCIE,MPLS VPN,故障排查,troubleshooting,MPLS Troubleshooting主要从两个层面来进行: 1, 控制层面---路由(和LDP,CEF没有关系) 控制平面主要管的事情是CE之间能通过MPLS VPN相互能学习到路由. No.1 : CE和CE之间,检查路由相互之间是否学习到. 在图中是R10和R2. 如果R10上面没有通过R8学习到对端R2的CE路由. No.2 : 这个时候需要到R1的vrf路由表查询是否有学习到R2的路由

Atitit.播放系统的选片服务器,包厢记时系统 的说明,教程,维护,故障排查手册p825

Atitit.播放系统的选片服务器,包厢记时系统 的说明,教程,维护,故障排查手册p825 1. 播放系统服务器方面的维护2 1.1. 默认情况下,已经在系统的启动目录下增加了俩个启动项目2 1.2. 后台服务.保持mysql数据库服务启动状态2 1.3. 影片图片与简介映射z盘需要有效可用2 1.4. 服务器如无必要无需关闭,保持一直开启状态...3 1.5. Loading时间的配置3 1.6. 其他3 1.6.1. 影片图片与简介缓存3 1.7. 包厢里面播放系统htpc的维护4 1.8.

cisco-router-nat/pat网络/端口地址转换

(以下所有内容为本手纯手打,有纰漏的地方,也请大家多多包含可发小猪消息赐教交流!) (本文所有内容及批注呈内收递归的架构显示,因格式显示不懂之处望谅解!) (本文手打之,命令关键字大多使用简写,如有不明最好是键入命令时惯用tab补全!) 网络地址转转nat(static静态转换/dynamic动态转换).端口多路复用pat: 1.静态nat的配置: router(config)#int f0/0 router(config-if)#ip add 10.0.0.1 255.255.255.0 (设

AD常见故障排查思路

AD常见故障 活动目录在域环境中起着非常关键的作用,它与各种应用联系紧密,如域用户登录.访问域内共享资源.部署组策略等都需要通过活动目录.活动目录不仅内部的众多功能模块联系密切,而且网络的连通性,网络协议和安全策略等有关,所以处理活动目录时必须综合考虑. 在实际应用中,可能会遇到以下几种AD故障类型. 域连接失败:将计算机加入到域的时候,提示找不到域. 域无法登录:客户端登录域的时候始终提示用户名或密码不正确,或登录域后,无法正常访问网络共享. 域登录缓慢:客户端在登录域的时候非常缓慢,严重影响

AD常见故障排查---运维笔记

在维护AD的时候会经常出现一些故障,良好的问题解决方法,可以在尽可能短时间内解决问题. 一·常见故障类型 (1)域连接失败:加入域时,提示找不到域. (2)域无法登陆:登录时密码不正确或登录后访问不了共享资源. (3)域登录缓慢:登录时非常缓慢 . (4)组策略部署失败:组策略未生效,或只对部分部分用户账户生效. (5)域控制器之间复制失效:AD数据或DNS记录不能同步更新. 二·AD常见故障排查思路 (1)确认单一用户账户的的故障:在于控制器中查找用户账户的所有信息点去判断故障点及其原因. (

Linux运维常见故障排查和处理的33个技巧汇总

作为linux运维,多多少少会碰见这样那样的问题或故障,从中总结经验,查找问题,汇总并分析故障的原因,这是一个Linux运维工程师良好的习惯.每一次技术的突破,都经历着苦闷,伴随着快乐,可我们还是执着的继续努力,从中也积累了更多的经验,这就是实践给予我们的丰厚回报. 下面汇总了我做项目过程可能出现的故障及解决方法,看看是否与你有共鸣,并对你有帮助? 第一:常见问题解决集锦   1.shell脚本不执行    问题:某天研发某同事找我说帮他看看他写的shell脚本,死活不执行,报错.我看了下,脚本

S7700交换机组网部分终端上不了网故障排查

本案例是多年之前遇到的一个真实故障处理过程,之后回想整个过程觉得比较有意思,因此将故障排查记录下来,现在将其分享出来,在其中隐藏了部分敏感信息.由于当时主要是做华为的服务,客户报的故障为S7700交换机的问题,因此本故障排查之初即在于S7700交换机.往往客户报的故障只是一个现象,而该现象又往往具有不确定性,因此我们需要认真的去分析网络环境,以及数据流走向,抓往一个故障点,突破一个故障面的问题.一.问题描述 两台S7700交换机配置VRRP,所有的流量主要走S3700.主S7700交换机.主H3