■ 四川 賴文書
編者按: 單位出現了分公司的服務器無法與總部FTP服務器連接問題,經過與各部門同事不斷溝通,發現是由于FTP同步軟件觸發安全網關端口防御導致。
軟件同事老A突然跑來說分公司的服務器無法與總部FTP服務器傳數據,讓我們檢查網絡,他提供的故障涉及源IP是170.220.170.39,目的IP是172.16.115.13。
地址源IP是互聯網的地址,目的IP是業務專網邊界安全網關的地址,很明顯互聯網與專網是不通的,應用的同事不了解這些情況,給他解釋了具體的網絡結構,有問題再聯系。
第二天分公司的運維同事小C直接聯系到我們,還是反饋昨天的問題,并且提到了分公司到總部FTP服務器剛剛都是通的,一運行他們的FTP腳本就不通了。我們確認了專網邊界安全網關安全策略是沒有人動過,同時也通過其他途徑Telnet測試了總部FTP服務器的21端口映射到安全網關的狀態正常。

圖1 端口掃描
奇怪了,這邊檢測完全正常,而對端就是不通,這種情況很容易引發工作上的扯淡推責。從專業的角度分析問題,還需要抓包工具確認對端的IP是否達到了安全網關,因為從分公司到總部還經過了千山萬水,因為業務專網是租用電信運營商的MSTP(Multi-Service Transport Platform)專線網絡組建的,其中任何一個環節出現異常都會引發故障。
在安全網關的Web管理頁面沒有找到網絡抓包工具,只得開啟SSH登錄到安全網關系統后臺調試。以前從來沒用過網御星云的安全網關,登錄后臺命令行界面也一時半會不知道如何操作。嘗試了在Linux系統里的tcpdump命令,真還有該工具。經過研究終于會用tcpdump抓包,讓分公司運維同事小C去服務器上ping 172.16.115.13,這邊抓包始終找不到對端的IP 170.220.170.39,那就是對端的數據包根本沒有到達安全網關。可是對端能正常ping總公司安全網關的IP,為什么抓不到數據包,太蹊蹺了。
讓對方使用tracert命令跟蹤路由,居然也看不到具體路徑,好像全被各個網絡防火墻節點過濾掉了。這樣的測試結果真讓我們不敢相信對方ping的IP就是我們安全網關的地址,也就沒法進一步推進故障的排查。
這時分公司運維同事小C又說,另一臺服務器現在也能TelnetFTP服務器的端口并通過截圖為證,但是一執行他們的的FTP腳本端口立刻就不通了。我們再次檢查安全網關上的配置發現“應用防護”/“抗掃描”/“設置”項里有個“端口掃描”如圖1,其中配置項有個“黑名單”引起大家的注意,會不會對端的網絡行為觸發了端口掃描,超過閾值被自動加入黑名單。
一番查找在管理頁面的“防火墻“/”黑名單“里真才看到了幾個IP被關小黑屋了。截圖給分公司的同事確認是否有他們相關的IP,根據”黑名單“上的時間對端很快發現有個IP好像他們的業務專網的出口地址,我們將該IP刪除讓其測試到總公司FTP服務器的端口,又能正常Telnet 172.16.115.13 21。果然是我們安全網關的安全配置引起了對端服務器無法與FTP服務器端口連接,可是為什么他們的FTP同步腳本就觸發了抗端口掃描安全策略呢?

圖2 Syncovery軟件界面
為了進一步排查引發故障的根本原因,是腳本引起的還是對端服務器或者網絡確有端口掃描行為?分公司運維同事小C分享了他們的ftp同步腳本模板如下:
#!/bin/bash
#mirror to ftp server
HOST="IP:端口"
USER="用戶名"
PASS="密碼"
LCD="本地路徑"
RCD="遠程路徑"
lftp -c "set ftp:listoptions -a;
open ftp://$USER:$PASS@$HOST;
lcd $LCD; #切換本地目錄
cd $RCD; #切換遠端目錄
mirror --reverse #反向鏡像(上傳文件)
--verbose #詳細輸出
--exclude-glob
a-dir-to-exclude/ #不包括相匹配的文件
--exclude-glob a-file-to-exclude
--excludeglob a-file-groupto-exclude*
--excludeglob other-files-toesclude"
LFTP是一款Unix系統下命令行界面的FTP客戶端軟件,除FTP外還支持FTPS、HTTP、HTTPS、SFTP、FXP等多種協議。此外,LFTP也內含一個簡單的BitTorrent客戶端。用戶可在互動模式下運行,也可直接使用腳本操作,亦支持多線程下載。
通過分析FTP腳本感覺不應該觸發端口抗掃描策略才對啊,一旦建立了FTP連接應該不會再頻繁連接21端口。最后溝通發現他們的腳本只是手動同步時才用的,平時都是用Syncovery軟件自動進行同步的,簡單了解軟件的情況,就是一款功能強大的同步軟件如圖2。也是他們最近才試用的工具,而為實現數據同步的時效性,配置了每1分鐘自動同步。對此種情況我們可以將分公司出口IP加入安全網關的白名單,但就失去了安全防御的作用。經反復測試把端口抗掃描策略的閾值從50改到了80才保障同步軟件的正常運行,不至于觸發安全策略被阻斷,初步判斷該軟件同步文件時有大量的端口連接活動。
此次故障中總結三點:
1.分析網絡故障原因必須收集掌握相關信息如源IP、目的 IP、網絡拓撲、具體應用和網絡安全策略,第一次軟件同事老A只反饋有問題,還得我們直接聯系分公司運維同事小C才行。
2.在溝通中由于網絡運維和系統運維的視角不同,反饋的信息需要甄別對待,比如分公司運維同事小C說的源IP不僅是NAT前內服務器IP,而且還是使用了非私有地址段,讓我們誤以為其是互聯網上的設備。
3.為解決問題需要雙方積極配合冷靜思考,否則就像第一次軟件同事老A報故障的結果仍然沒解決問題,作為負責網絡管理的我們還需要在溝通中引導軟件開發和運維人員提供準確的信息,并且配合相關測試確認,才能提高解決問題的效率。