開發與維運

應用數據遷移網絡異常案例分析

作者:連珣

問題描述及現象

某客戶計劃通過P2V工具遷移500臺左右鏡像至阿里雲華北1(青島),在應用數據遷移傳輸過程中是把用戶的系統盤、數據盤的數據通過公網傳輸到阿里雲中轉ECS實例上。

某客戶6.12-6.13號批量遷移100臺基本正常,從2018.6.13號晚10點左右開始連接阿里雲中轉ECS實例就出現中斷,現象為在客戶端telnet中轉ECS實例8703端口提示Connection closed by foreign host. 但檢查中轉ECS實例的http 服務8080正常,而且其它地方測試中轉ECS實例8073端口、8080端口服務均正常。

6.20-6.21恢復正常後,繼續批量遷移了130臺左右,但6.25號開始又問題重現。

問題處理過程

6.15號

12點左右開始,客戶再次重現問題。
在客戶側telnet 10次都失敗了,在阿里雲ECS側(47.104.79.200,i-m5ecitgdpobfwwrzb6bm)抓包如上rsync_server.cap。同時在其它地方telnet 正常。

2.1.png

和客戶修改傳輸端口為8702測試了一下,telnet 10次全部成功,換回8703就不行了。這個跟網絡運營商一貫的封端口的手法很類似,應該是端口被記錄並限制了。

6.25號

客戶臨時改端口方案也行不通了,修改了2次端口都是傳了一部分之後就被強制斷開了,報一樣的傳輸錯誤。但是在其他地方telnet中轉ECS測試傳輸正常。

6.26號

20:30分-22:00分 遷雲專家服務團隊進入排障
1)從歷史抓包信息來看,初步判斷是安全策略或網絡質量導致請求超時。

2.2.png

注:關於TCP的幾個FLAGS字段標識,我這裡簡單介紹一下,有興趣深入瞭解的可以自行百度查相關材料,大概含義是:

SYN表示建立連接,

FIN表示關閉連接,

ACK表示響應,

PSH表示有 DATA數據傳輸,

RST表示連接重置。

2)同時,從客戶反饋的網絡架構環境來看,客戶網絡環境部署了一些DDOS、FW等的安全防護的設備。

3)重新啟動遷移任務進行測試,此時段網絡傳輸正常。

22:10分-23:00問題重現
1)從客戶反饋的出口監控流量上看已經達到了帶寬上限200M。

2.3.png

2)客戶側通過檢查FW上的log日誌暫未發現異常信息。

2.4.png

3)由於時間關係,總結並計劃第二天排查的思路:

(1)請XXX客戶數據中心部門畫一下當前的網絡拓撲圖,明天和阿里雲專家一起開會介紹。

(2)請XXX客戶數據中心部門和運營商確認:如果超過了目前購買的200M帶寬,運營商會如何處理?協調讓運營商取消限制進行一次測試。

(3)後續遷移,啟用遷移工具限流,設置總流量不超過100M。

(4)請XXX客戶數據中心部門,將遷移時的3個隨機IP(NAT出去的外部地址)修改為1個,然後進行測試。

6.27號

10:10 瞭解客戶環境
按昨晚計劃的排查思路,客戶介紹網絡環境,從中瞭解到客戶IDC部署了流量清洗AntiDDoS設備、鏈路負載均衡F5、H3C M9006防火牆設備等。大致的網絡環境如下所示:

2.5.png

10:20 查看日誌
查看AntiDDoS、M9006日誌、策略等,均未發現異常信息。

2.6.png

2.7.png

2.8.png

2.9.png

10:30 切換線路
將原來的移動線路切換至聯通線路,將SNAT設置為一個公網IP X.X.X.62,同時將帶寬限流為20M進行遷移測試,此時P2V遷移工具傳系統盤、數據盤均正常。

11:00 問題重現
源服務器測試:

2.10.png

其它公網環境:

2.11.png

12:00-15:00 問題範圍定位
1)在客戶網絡環境互聯網區最外層跟運營商對接互聯的華為C6850設備上設置聯通問題IP(X.X.X.62),也即是原來SNAT設置的公網IP。測試此時聯通線路是否正常的.排除定位是聯通線路問題還是企業內部網絡問題,把範圍定位.

2.12.png

2)在C6850 測試8703端口不通,但可以訪問外部網絡,跟源遷移服務器情況一致,基本可以判斷此異常問題跟客戶網絡環境無關。

2.13.png

15:30 更換SNAT公網地址
更換SNAT公網地址測試8703端口通過,即將聯通外網IP X.X.X.62更改為X.X.X.60).基本上可以確定客戶的X.X.X.62 8703端口被上游運營商、雲廠商封堵或攔截。

7、總結並計劃明天下一步的排查思路:

1)阿里雲網絡排查,聯繫“網絡運營服務檯”協助定位。

2)阿里雲安全策略排查,聯繫阿里雲安全同事。

3)切換電信線路進行復盤遷移測試(移動、聯通線路均已測試且都能重現同樣的問題出來,但為了讓客戶更加積極配合我們進行排查問題,故繼續又選電信線路進行測試,儘管理論上三家運營商同時封端口的概率很低)。

6.28號 問題解決

1)09:30 諮詢阿里雲-安全部李XX,從描述的現象看很像是安全攻擊。

2)10:30 聯繫阿里雲-安全部陳XX,陳XX通過安全運營平臺查看到攔截信息。

2.14.png

3)12:30阿里雲-安全部陳XX把客戶的公網IP添加為白名單後問題解決。

影響範圍

數據遷移中斷,影響項目正常進行。

問題結論

安全策略:本次數據遷移網絡異常主要是命中了阿里雲的“防惡意攻擊的安全策略”。

觸發場景:在短時間內的大批量臨時的ECS消耗(創建到釋放)場景可能會觸發。

Leave a Reply

Your email address will not be published. Required fields are marked *