發(fā)布時間：2020-06-02
大家好，我是 “老狼”，曾經(jīng)也算文藝青年一枚。無奈，一入IT深似海，只是一個轉(zhuǎn)身，就完成了從文藝青年到IT狗的華麗變身。
言歸正傳，今天要和大家分享的內(nèi)容是關(guān)于一個端口映射問題真實案例，我們知道端口映射不成功問題經(jīng)常遇到，這次為了正經(jīng)且系統(tǒng)帶引大家學(xué)習(xí)映射問題排查，我將通過引入身邊一個真實案例對話，層層深入剖析映射問題癥結(jié)，希望能給大家提供一些啟示及幫助。
Ok，話不多說，我們開始吧。
一、什么場景會用到端口映射——情景
為了講清問題，我們有必要提前了解一下什么場景會用到端口映射及幾個基礎(chǔ)概念。
首先是NAT（Network Address Translation）全稱網(wǎng)絡(luò)地址轉(zhuǎn)換。詳細(xì)概念介紹建議百度。簡單來講就是在持有私網(wǎng)地址的主機(jī)想和公網(wǎng)的地址通信的時候需要使用到的公網(wǎng)和私網(wǎng)的地址互換的技術(shù)。我們都知道IPv4路由是區(qū)分公網(wǎng)地址和私網(wǎng)地址的，私網(wǎng)地址在公網(wǎng)是沒有路由的，那這個時候擁有私網(wǎng)地址的主機(jī)想要和公網(wǎng)的主機(jī)通信，這個技術(shù)是必不可少的。
其次是端口映射
圖(1)
如上圖所示，PC位于外網(wǎng)，某服務(wù)器(如web服務(wù)器)位于內(nèi)網(wǎng)。但由于IP地址已經(jīng)耗盡的問題，整個網(wǎng)絡(luò)只分配了一個外網(wǎng)IP地址。出口路由器屬于內(nèi)網(wǎng)，用于連接外網(wǎng)。PC要訪問到內(nèi)網(wǎng)的服務(wù)器，需要在出口路由器上開啟NAPT（端口映射）功能，即針對web服務(wù)提供的端口進(jìn)行端口映射。
端口映射其實就是一種內(nèi)網(wǎng)服務(wù)器對外開放的一種網(wǎng)絡(luò)地址轉(zhuǎn)換，其實轉(zhuǎn)換的原理就是當(dāng)訪問公網(wǎng)某個地址的某個端口的時候由NAT設(shè)備將目的地址轉(zhuǎn)換為要訪問的內(nèi)網(wǎng)服務(wù)器的地址，并轉(zhuǎn)發(fā)給內(nèi)網(wǎng)服務(wù)器，等待內(nèi)網(wǎng)服務(wù)器報文返回到對應(yīng)的接口的時候再根據(jù)之前的會話轉(zhuǎn)換回之前的報文。
二、迷失的映射報文
話說前些天五一小假期，小王好容易借著疫情常態(tài)化的契機(jī)出去踏個青，晚上回來累的不行，早早的洗洗就睡了。結(jié)果半夜一點多睡的正香的時候就被好機(jī)油（小李）的電話吵醒了，于是有了下面對話……
圖(2)
此時的小王睡意完全沒了，你割接苦逼也就罷了，拉著我一起苦逼你就是犯罪了。我這小暴脾氣啊。當(dāng)時我就開噴了：咱倆誰跟誰啊，別客氣。用的什么設(shè)備啊？具體情況和我說下。
三、迷失的映射報文——還原現(xiàn)場
原來現(xiàn)場用一臺EG做出口，對內(nèi)就是核心交換—匯聚—接入—服務(wù)器啦，中間還串了一臺防火墻！不過安全策略全放通，直接用接口地址映射內(nèi)網(wǎng)的服務(wù)器。
圖（3）
好機(jī)油說這個映射配置肯定是沒問題，這種配置他配過很多遍，而且在內(nèi)網(wǎng)測試過服務(wù)器業(yè)務(wù)，是正常的啊。內(nèi)部的服務(wù)器也可以直接上公網(wǎng)，但是就是無法成功通過公網(wǎng)地址訪問到內(nèi)部服務(wù)器。
就這啊，機(jī)油別怕，so easy ，來吧，讓我們一步一步work it out！
“從公網(wǎng)ping映射的公網(wǎng)地址通嗎”
“可以通啊”
“Ok，連通性排除，服務(wù)器也沒問題”
“修改映射的外網(wǎng)端口測試是否正常？”
“不可以!還是沒法訪問”
“Ok，運營商封端口問題可以排除！”
“核心交換機(jī)方便流量統(tǒng)計或者鏡像
抓包嗎，看下有沒有轉(zhuǎn)換報文從防火
墻上核心，看下問題到底和防火墻有
沒有關(guān)系？”
“抓過了，有報文！”
“OK，基本可以排除防火墻問題。”
“現(xiàn)場有沒有多出口環(huán)境？”
“有啊。聯(lián)通一個，電信一個，兩個出口。”
哈哈，聽到這里，小王放肆的笑了
“問題應(yīng)該找到了，是不是來回路徑不一致導(dǎo)致的？
有沒有保證映射的回程數(shù)據(jù)流還從對應(yīng)的接口回去啊？”
“你高興的太早了老鐵，接口下開啟了reverse-path(源進(jìn)源出)這個情況應(yīng)該會來回一致吧？！”
哎呦我去，這自信的，突然閃了老子的腰。險些裝逼失敗，沒關(guān)系，next，老紙要放大招了。
“來，幫我收個NAT 轉(zhuǎn)換的流信息
瞅瞅吧。先來看看NAT這步到底有沒
有什么問題。
先開啟下登錄軟件的記錄會話，然后cli敲：
1. show ip fpm modules | i FLOW-AUDIT
2.show ip fpm pri filter x（x為第一步驟收集索引號）0 x.x.x.x（訪問外網(wǎng)ip） 32 0.0.0.0 32
2.show ip fpm flow filter 0 x.x.x.x（訪問外網(wǎng)ip） 32 0.0.0.0 32
3.同時在EG端和服務(wù)器分別抓包
“好的，馬上收好發(fā)給你。”
四、迷失的映射報文——破迷
下面我們對收集這幾個信息詳細(xì)解讀下，看看他們作用是什么：
首先先稍微解釋下，收集兩個命令作用：
1.先show ip fpm modules | i FLOW-AUDIT—用來查看流量審計的業(yè)務(wù)號（左側(cè)第一列，如本案例為10）
2.show ip fpm pri filter 10 0 x.x.x.x（訪問外網(wǎng)ip） 32 0.0.0.0 32—用來收集數(shù)據(jù)包選路路徑是否正確（如從WAN口接口到數(shù)據(jù)包后是否從正確LAN口轉(zhuǎn)發(fā)，來回轉(zhuǎn)發(fā)路徑是否正確）
3.show ip fpm flow filter 0 x.x.x.x（訪問外網(wǎng)ip） 32 0.0.0.0 32—用來收集數(shù)據(jù)包流表信息是否正常做了端口轉(zhuǎn)換及轉(zhuǎn)換后數(shù)據(jù)收發(fā)是否正常（一般如果正確轉(zhuǎn)換的話在流信息會有轉(zhuǎn)換記錄）
Ok，那么我們接下來看看現(xiàn)場收集回來信息：
圖（5）
圖（6）
以上兩點測試可以得出：EG的端口映射配置沒有問題，服務(wù)器頁面沒有問題，EG上數(shù)據(jù)轉(zhuǎn)發(fā)沒有問題，現(xiàn)象是有點奇怪，繼續(xù)看看報文：
1、在服務(wù)器端抓包，能看到正常的http GET報文到達(dá)到服務(wù)器：
圖（7）
不過服務(wù)器端收到get報文之后，有收到一個rst的重置連接報文，導(dǎo)致http連接終止。
2、在EG端抓包，也能看到報文正常到達(dá)EG，并且正常轉(zhuǎn)換之后轉(zhuǎn)發(fā)給內(nèi)網(wǎng)服務(wù)器：
圖（8）
從這里看RST報文都是訪問服務(wù)器的終端發(fā)起來的，如果是正常的交互過程不會有rst的報文。
從抓包結(jié)果：懷疑是中間運營商設(shè)備抑制行為導(dǎo)致回應(yīng)RST異常報文。
五、迷失的映射報文——解密
為了證明確實是運營商所為，給小李一個交代，小王趕緊從打開電腦在本地電腦終端訪問抓了個包，結(jié)果發(fā)現(xiàn)電腦發(fā)起GET報文之后，又收到一個由映射的外網(wǎng)服務(wù)器發(fā)來的一個RST報文！哈哈，果然問題出在這里，趕緊給小李解釋了整個過程，建議聯(lián)系運營商協(xié)助排查！
小李持著懷疑的態(tài)度，又做了一個操作：將電腦模擬運營商環(huán)境，配置成外網(wǎng)網(wǎng)關(guān)地址，充當(dāng)外網(wǎng)線路進(jìn)行訪問，是可以正常訪問，至此基本確認(rèn)是運營商抑制行為所致。小李趕緊聯(lián)系運營商更換了個外網(wǎng)地址后，一試果然好了，連連和小王道謝，說這次不但問題解決了，還理清了映射問題的排查思路，最后還非要請小王吃燒烤呢。
六、案例經(jīng)驗總結(jié)
對此類故障的排查除了關(guān)注配置，更換端口及確認(rèn)現(xiàn)場網(wǎng)絡(luò)環(huán)境以外，很重要是要先弄清楚數(shù)據(jù)轉(zhuǎn)發(fā)路徑，多思考數(shù)據(jù)的走向，可能遇到的問題，必要時候結(jié)合抓包定位分析，一步步排查，從基本的開始，不放過一個可能的原因。
通用排查思路如下：
七、背后技術(shù)原理
1、流表：
- EG/NPE設(shè)備底層的一張表，存儲設(shè)備接收以及轉(zhuǎn)發(fā)的數(shù)據(jù)流信息。流表可以記錄數(shù)據(jù)流的源目的地址、源目的端口、發(fā)送和接收的字節(jié)數(shù)、是否做了NAT、NAT前后IP、端口的變化等信息。
- 流表是EG/NPE設(shè)備中非常重要的一張表，數(shù)據(jù)處理時優(yōu)先使用到這張表中已有的數(shù)據(jù)流信息，同時所有的數(shù)據(jù)轉(zhuǎn)發(fā)的基本信息都會存儲到這張表中。
命令：
show ip fpm flow filter 0(協(xié)議，0表示任意) SrcAddr(源ip) 掩碼 DstAddr (目的ip) 掩碼（推薦用此種方式查看）
show ip fpm flow | include x.x.x.x（過濾的ip地址） -- 10.x/11.x通用（不推薦，流表太大可能會導(dǎo)致CPU高）
舉例說明各個字段含義:
如協(xié)議號：17 udp流
CLOSED 0 連接處于關(guān)閉狀態(tài)
STARTED 1 連接發(fā)起狀態(tài)
CONNECTED 2 對方響應(yīng)之后的狀態(tài)
ESTABLISHED 3 在對方響應(yīng)之后連接發(fā)起方又有發(fā)送報文
如協(xié)議號：1 icmp流
CLOSED 0 連接處于關(guān)閉狀態(tài)
STARTED 1 連接發(fā)起狀態(tài)
CONNECTED 2 對方響應(yīng)之后的狀態(tài)
流表中srcif對應(yīng)9，如show interface可以看到9代表TenGigabitEthernet 0/0,10.x無此功能, 接口顯示“fff”代表設(shè)備自己發(fā)送的數(shù)據(jù)，或者是設(shè)備接收并處理的數(shù)據(jù)或者是某個方向上面未收到報文的初始值；
上面紅色方框內(nèi)的流設(shè)為流1和流2：
流1：設(shè)備自己發(fā)送給114.114.114.114的DNS解析報文，因設(shè)備自己主動發(fā)送這個報文，設(shè)備認(rèn)為源端口是自己，顯示為“fff”
流2：10.112（實驗室APM設(shè)備）向EG發(fā)送SNMP報文，因設(shè)備接收此報文并直接處理，設(shè)備直接就處理這個數(shù)據(jù)，不需要再通過任何接口轉(zhuǎn)發(fā)，目的端口顯示為“fff”
對于流表上最前面兩條流，屬于組播數(shù)據(jù)，接口顯示為“fff”也是表示本接收或發(fā)送，如源接口是6、目標(biāo)接口是fff,表示是數(shù)據(jù)從編號6接口收到，設(shè)備本地接收；
- 除流表之外，EG/NPE底層還開辟了部分空間，用于存儲數(shù)據(jù)流處理過程中除流表外更詳細(xì)的一些信息，如應(yīng)用識別情況、流控匹配情況等。這部分空間實際上存在，但對于用戶而言是透明的，因此被稱為設(shè)備的私有空間。私有空間在設(shè)備中被分成若干塊，每塊記錄不同的數(shù)據(jù)處理內(nèi)容，并通過私有空間ID進(jìn)行區(qū)分；
- 在EG/NPE 10.x平臺上，因產(chǎn)品限制，私有空間ID和實際存儲的數(shù)據(jù)內(nèi)容不是一一對應(yīng)，需要根據(jù)版本進(jìn)行區(qū)分；在EG 11.x平臺上，所有私有空間ID是固定的。
命令：
示例1：查看數(shù)據(jù)選路方式
示例2：確定選路轉(zhuǎn)發(fā)路徑匹配情況（11.x）
說明：需要注意的是這里的module id是動態(tài)的，以實際show結(jié)果為準(zhǔn)。
寫在最后
目前遇到的外網(wǎng)無法訪問映射服務(wù)器的故障，基本上這一套“組合拳”下來，大部分的映射問題都可以解決啦。伴著好機(jī)油的道謝和燒烤到手，本來這一波分享就結(jié)束了，但是最后還是友情奉送下史上故障排查“殺手锏”：
文檔評價
