各人好，，，，，我是 “老狼”，，，，，已经也算文艺青年一枚。。。。。。无奈，，，，，一入IT深似海，，，，，只是一个转身，，，，，就实现了从文艺青年到IT狗的豪华变身。。。。。。

言归正传，，，，，今天要和各人分享的内容是关于一个端口映射问题真实案例，，，，，我们知路端口映射不成功问题时时遇到，，，，，这次为了正经且系统带引各人进建映射问题排查，，，，，我将通过引入身边一个真实案例对话，，，，，层层深刻分解映射问题症结，，，，，但愿能给各人提供一些启迪及援手。。。。。。

Ok，，，，，话不多说，，，，，我们起头吧。。。。。。

一、什么场景会用到端口映射——情景

为了讲清问题，，，，，我们有必要提前相识一下什么场景会用到端口映射及几个基础概想。。。。。。

首先是NAT（Network Address Translation）全称网络地址转换。。。。。。具体概想介绍建议百度。。。。。。单一来讲就是在持有私网地址的主机想和公网的地址通讯的时辰必要使用到的公网和私网的地址互换的技术。。。。。。我们都知路IPv4路由是分辨公网地址和私网地址的，，，，，私网地址在公网是没有路由的，，，，，那这个时辰占有私网地址的主机想要和公网的主机通讯，，，，，这个技术是必不成少的。。。。。。

其次是端口映射

图(1)

如上图所示，，，，，PC位于表网，，，，，某服务器(如web服务器)位于内网。。。。。。但由于IP地址已经耗尽的问题，，，，，整个网络只分配了一个表网IP地址。。。。。。出口路由器属于内网，，，，，用于衔接表网。。。。。。PC要接见到内网的服务器，，，，，必要在出口路由器上开启NAPT（端口映射）职能，，，，，即针对web服务提供的端口进行端口映射。。。。。。

端口映射其实就是一种内网服务器对表盛开的一种网络地址转换，，，，，其实转换的道理就是当接见公网某个地址的某个端口的时辰由NAT设备将主张地址转换为要接见的内网服务器的地址，，，，，并转发给内网服务器，，，，，期待内网服务器报文返回到对应的接口的时辰再凭据之前的会话转换回之前的报文。。。。。。

二、迷失的映射报文

话说前些天五一幼假期，，，，，幼王好容易借着疫情常态化的契机出去踏个青，，，，，晚上回来累的不能，，，，，早早的洗洗就睡了。。。。。。了局半夜一点多睡的正香的时辰就被好机油（幼李）的电话吵醒了，，，，，因而有了下面对话……

 图(2)

此时的幼王睡意齐全没了，，，，，你割接苦逼也就而已，，，，，拉着我一路苦逼你就是犯罪了。。。。。。我这幼暴脾性啊。。。。。。其时我就开喷了：咱俩谁跟谁。。。。。。，，，别客套。。。。。。用的什么设备。。。。。。？？？？？具体情况和我说下。。。。。。

三、迷失的映射报文——还原现场

原来现场用一台EG做出口，，，，，对内就是主题互换—汇聚—接入—服务器啦，，，，，中央还串了一台防火墙！不外安全战术全放通，，，，，直接用接口地址映射内网的服务器。。。。。。

图（3）

好机油说这个映射配置注定是没问题，，，，，这种配置他配过好多遍，，，，，并且在内网测试过服务器业务，，，，，是正常的啊。。。。。。内部的服务器也能够直接上公网，，，，，但是就是无法成功通过公网地址接见到内部服务器。。。。。。

就这。。。。。。，，，机油别怕，，，，，so  easy ，，，，，来吧，，，，，让我们一步一步work it out！

“从公网ping映射的公网地址通吗”

“能够通啊”

 “Ok，，，，，连通性排除，，，，，服务器也没问题”

“批改映射的表网端口测试是否正常？？？？？？”

“不成以!还是没法接见”

“Ok，，，，，运营商封端口问题能够排除！”

“主题互换机方便流量统计或者镜像

抓包吗，，，，，看下有没有转换报文从防火

墙上主题，，，，，看下问题到底和防火墙有

没有关系？？？？？？”

“抓过了，，，，，有报文！”

“OK，，，，，根基能够排除防火墙问题。。。。。。”

“现场有没有多出口环境？？？？？？”

“有啊。。。。。。联通一个，，，，，电信一个，，，，，两个出口。。。。。。”

哈哈，，，，，听到这里，，，，，幼王狂妄的笑了

“问题应该找到了，，，，，是不是来回蹊径不一致导致的？？？？？？

有没有保障映射的回程数据流还从对应的接口回去。。。。。。？？？？？”

“你欣喜的太早了老铁，，，，，接口下开启了reverse-path(源进源出)这个情况应该会来回一致吧？？？？？？！”

哎呦我去，，，，，这自负的，，，，，忽然闪了老子的腰。。。。。。险些装逼失败，，，，，不要紧，，，，，next，，，，，老纸要放大招了。。。。。。

“来，，，，，助我收个NAT 转换的流信息

瞅瞅吧。。。。。。先来看看NAT这步到底有没

有什么问题。。。。。。

先开启下登录软件的纪录会话，，，，，而后cli敲：

1. show ip fpm modules | i FLOW-AUDIT

2.show ip fpm pri filter x（x为第一步骤网络索引号）0 x.x.x.x（接见表网ip） 32 0.0.0.0 32

2.show ip fpm flow filter 0 x.x.x.x（接见表网ip） 32 0.0.0.0 32

3.同时在EG端和服务器别离抓包

“好的，，，，，顿时收好发给你。。。。。。”

四、迷失的映射报文——破迷

下面我们对网络这几个信息具体解读下，，，，，看看他们作用是什么：

首先先稍微诠释下，，，，，网络两个号令作用：

1.先show ip fpm modules | i FLOW-AUDIT—用来查看流量审计的业务号（左侧第一列，，，，，如本案例为10）

2.show ip fpm pri filter 10 0 x.x.x.x（接见表网ip） 32 0.0.0.0 32—用来网络数据包选路蹊径是否正确（如从WAN口接口到数据包后是否从正确LAN口转发，，，，，来回转发蹊径是否正确）

3.show ip fpm flow filter 0 x.x.x.x（接见表网ip） 32 0.0.0.0 32—用来网络数据包流表信息是否正常做了端口转换及转换后数据收发是否正常（通常若是正确转换的话在流信息会有转换纪录）

Ok，，，，，那么我们接下来看看现场网络回来信息：

1. 首先我们能够看到：表网接见的终端ip（即218.106.154.158）接见映射接口ip（58.x.x.59）时辰，，，，，数据包转发来回蹊径的确没问题，，，，，从WAN3口进，，，，，LAN-Te0/0出，，，，，回程数据流也没问题，，，，，如下图：

图（5）

2. 表网触发接见时辰，，，，，接见的主张地址（即WAN3口的ip），，，，，设备的确正确做了转换（看括号里面地址是内部服务器要映射地址），，，，，但这里数据收发的确也有点问题（看send和rec列，，，，，屡次show了局数据未有显著上涨），，，，，如下：

图（6）

       以上两点测试能够得出：EG的端口映射配置没有问题，，，，，服务器页面没有问题，，，，，EG上数据转发没有问题，，，，，景象是有点奇怪，，，，，持续看看报文：

1、在服务器端抓包，，，，，能看到正常的http GET报文达到到服务器：

图（7）

不外服务器端收到get报文之后，，，，，有收到一个rst的沉置衔接报文，，，，，导致http衔接终止。。。。。。

2、在EG端抓包，，，，，也能看到报文正常达到EG，，，，，并且正常转换之后转发给内网服务器：

图（8）

从这里看RST报文都是接见服务器的终端提议来的，，，，，若是是正常的交互过程不会有rst的报文。。。。。。

从抓包了局：疑惑是中央运营商设备抑造行为导致回应RST异常报文。。。。。。

五、迷失的映射报文——解密

为了证明的确是运营商所为，，，，，给幼李一个交代，，，，，幼王连忙从打开电脑在本地电脑终端接见抓了个包，，，，，了局发现电脑提议GET报文之后，，，，，又收到一个由映射的表网服务器发来的一个RST报文！哈哈，，，，，居然问题出在这里，，，，，连忙给幼李诠氏缢整个过程，，，，，建议联系运营商协助排查！

幼李持着疑惑的态度，，，，，又做了一个操作：将电脑仿照运营商环境，，，，，配置成表网网关地址，，，，，充任表网线路进行接见，，，，，是能够正常接见，，，，，至此根基确认是运营商抑造行为所致。。。。。。幼李连忙联系运营商更换了个表网地址后，，，，，一试居然好了，，，，，连连和幼王路谢，，，，，说这次不只问题解决了，，，，，还理清了映射问题的排查思路，，，，，最后还非要请幼王吃烧烤呢。。。。。。

六、案例经验总结

       对此类故障的排查除了关注配置，，，，，更换端口及确认现场网络环境以表，，，，，很沉要是要先弄明显数据转发蹊径，，，，，多思虑数据的走向，，，，，可能遇到的问题，，，，，必要时辰结合抓包定位分析，，，，，一步步排查，，，，，从根基的起头，，，，，不放过一个可能的原因。。。。。。

       通用排查思路如下：

七、背后技术道理

1、流表：

-  EG/NPE设备底层的一张表，，，，，存储设备接管以及转发的数据流信息。。。。。。流表能够纪录数据流的源主张地址、源主张端口、发送和接管的字节数、是否做了NAT、NAT前后IP、端口的变动等信息。。。。。。

-  流表是EG/NPE设备中极度沉要的一张表，，，，，数据处置时优先使用到这张表中已有的数据流信息，，，，，同时所有的数据转发的根基信息城市存储到这张表中。。。。。。

号令：

show ip fpm flow filter 0(和谈，，，，，0暗示肆意) SrcAddr(源ip) 掩码 DstAddr (主张ip) 掩码（推荐用此种方式查看）

show ip fpm flow | include x.x.x.x（过滤的ip地址） -- 10.x/11.x通用（不推荐，，，，，流表太大可能会导致CPU高）

举例注明各个字段寓意:

• • • • Pr(和谈):如6是TCP，，，，，17是UDP；；；；；
      • SrcAddr(源地址):提议数据包的地址，，，，，括号内的地址为NAT后的地址；；；；；
      • DstAddr(主张地址)：数据包的主张地址，，，，，括号内的地址为nat后的地址
      • SrcPort(源端口）：提议数据包的源端口信息，，，，，括号内为nat后的端口
      • DstPort(主张端口)：提议数据包的主张端口信息，，，，，括号内为nat后的端口
      • Vrf:EG只有一个VRF数据都是在VRF0，，，，，能够不看；；；；；
      • SendBytes(发送)：以内网用户来看就是内网用户从内网发送到EG设备的数据包总的大。。。。。。，，，字节为单元；；；；；
      • RecvBytes(接管)：以内网用户来看就是EG设备上收到表网发到这个内网IP的数据包的总的大。。。。。。，，，字节为单元；；；；；
      • St(流当前状态)：流的状态要对应于当前的和谈。。。。。。分歧和谈寓意不一样，，，，，举例注明如下:

如和谈号：17   udp流

CLOSED                  0               衔接处于关关状态

STARTED                 1               衔接提议状态

CONNECTED               2               对方响应之后的状态

ESTABLISHED             3               在对方响应之后衔接提议方又有发送报文

如和谈号：1    icmp流

CLOSED                 0                衔接处于关关状态

STARTED                1                衔接提议状态

CONNECTED              2                对方响应之后的状态

• • • • srcif(源接标语)：代表数据从那个接口收到，，，，，show interface能够看到接口的编号对应那个接口如下，，，，，举例：

流表中srcif对应9，，，，，如show interface能够看到9代表TenGigabitEthernet 0/0,10.x无此职能, 接口显示“fff”代表设备自己发送的数据，，，，，或者是设备接管并处置的数据或者是某个方向上面未收到报文的初始值；；；；；

• • • • ================= TenGigabitEthernet 0/0 ========================
      •   Index(dec):9 (hex):9
      • dstif(主张接标语)：代表数据从那个接口转发；；；；；
      • ctrl_flag(流节造字段)：无现实意思研发调试使用
      • 注明：接口显示“fff”代表设备自己发送的数据，，，，，或者是设备接管并处置的数据，，，，，举例注明：

上面红色方框内的流设为流1和流2：

 流1：设备自己发送给114.114.114.114的DNS解析报文，，，，，因设备自己自动发送这个报文，，，，，设备以为源端口是自己，，，，，显示为“fff”

流2：10.112（尝试室APM设备）向EG发送SNMP报文，，，，，因设备接管此报文并直接处置，，，，，设备直接就处置这个数据，，，，，不必要再通过任何接口转发，，，，，主张端口显示为“fff” 

对于流表上最前面两条流，，，，，属于组播数据，，，，，接口显示为“fff”也是暗示本接管或发送，，，，，如源接口是6、指标接口是fff,暗示是数据从编号6接口收到，，，，，设备本地接管；；；；；

2. 私有空间：

- 除流表之表，，，，，EG/NPE底层还启发了部门空间，，，，，用于存储数据流处置过程中除流表表更具体的一些信息，，，，，如利用鉴别情况、流控匹配情况等。。。。。。这部门空间现实上存在，，，，，但对于用户而言是通明的，，，，，因而被称为设备的私有空间。。。。。。私有空间在设备中被分成若干块，，，，，每块纪录分歧的数据处置内容，，，，，并通过私有空间ID进行分辨；；；；；

- 在EG/NPE 10.x平台上，，，，，因产品限度，，，，，私有空间ID和现实存储的数据内容不是逐一对应，，，，，必要凭据版本进行分辨；；；；；在EG 11.x平台上，，，，，所有私有空间ID是固定的。。。。。。

号令：

• Show ip fpm mudule(确定选路了局对应的私有空间ID,分歧型号可能不一样，，，，，以具体show了局为准)
• show ip fp pri filter x（私有空间ID，，，，，可通过show ip fpm module查看，，，，，如1暗示查看数据流选路方式，，，，，10暗示数据转发蹊径，，，，，13暗示流控匹配等等） 0(和谈，，，，，0暗示肆意) SrcAddr(源ip) 掩码 DstAddr (主张ip) 掩码

示例1：查看数据选路方式

• • • 号令：
      • show ip fp pri 1  | include x.x.x.x（过滤的ip地址）或show ip fpm pri filter 1 0（0代表肆意和谈） x.x.x.x(x.x.x.x这里代表源ip) 32(掩码32代表主机ip) y.y.y.y(y.y.y.y这里代表主张ip) 32(掩码32代表主机ip)   -- 10.x/11.x通用，，，，，查看选路方式
    • 必要关注的字段寓意如下：

• • • • Ref_ip/rpl暗示数据通过什么选路方式走的，，，，，如ref_ip代表通常路由选路，，，，，rpl代表源进源出，，，，， pbr代表战术路由，，，，，mllb暗示多链路负载平衡，，，，，dns_proxy代表正向dns代理，，，，，app_route代表利用路由等，，，，，unknown注明未匹配选路，，，，，通常到本地或被抛弃；；；；；
      • ref_ip(7)/rpl(1) ：前面是正向流代表出方向，，，，，后面是反向流代表入方向 ，，，，， 括号里面数字暗示对应代码，，，，，只是暗示挨次而已，，，，，这里7暗示选路出去的蹊径,1则暗示到内网的蹊径，，，，，如1:ref/4:rpl/5:dns/6:app_route
      • 25/3747,前面是数据流出方向接口索引id（出接口），，，，，后面是数据流入方向接口索引id（入接口），，，，，可通过号令show ip ref adj或show ip ref route确定现实流出入接口，，，，，如上图所示，，，，，该流出接口为Te0/1，，，，，入接口为Gi0/0。。。。。。

示例2：确定选路转发蹊径匹配情况（11.x）

• • • 号令：
• show ip fpm module找到对应的索引id和name（左边前两列，，，，，如本例10为数据转发蹊径），，，，，而后通过号令show ip fpm priv xx（module id）| include x.x.x.x(过滤具体ip)或show ip fpm pri filter 10 0（0代表肆意和谈） x.x.x.x(x.x.x.x这里代表源ip) 32(掩码32代表主机ip) y.y.y.y(y.y.y.y这里代表主张ip) 32(掩码32代表主机ip)

注明：必要把稳的是这里的module id是动态的，，，，，以现实show了局为准。。。。。。

• • • 各必要关注的字段寓意如下：

• • • • Ori:srcif-dif(源-主张接标语)：代表原始数据流从源接口（Gi0/3）收到，，，，，往主张接口（Gi0/4）转发出去；；；；；
      • Rep:srcif-dif(源-主张接标语)：代表回程数据流从源接口（Gi0/4）收到，，，，，往主张接口（Gi0/3）转发出去；；；；；
      • Up_if:出接口

写在最后

目前遇到的表网无法接见映射服务器的故障，，，，，根基上这一套“组合拳”下来，，，，，大部门的映射问题都能够解决啦。。。。。。伴着好机油的路谢和烧烤得手，，，，，正本这一波分享就实现了，，，，，但是最后还是交谊馈送下史上故障排查“杀手锏”：