運營商間網絡無法互通問題

■ 遼寧 劉嘉琦

編者按：不同運營商網絡之間的有效連接與通信對于企業網絡連接與業務系統的平穩運行至關重要。本文講解了筆者單位出現的不同運營商之間的網絡出現無法互通的問題，給單位造成不小的影響。筆者針對這一問題進行了詳細探討，并給出了相關解決方案和建議。

由于筆者單位信息化業務發展的需要，現有公網地址已不能滿足當前需求。因此公司向中國電信購買了8 個公網地址，為106.38.72.48/29。單位將其中的106.38.72.49 分配給新上線的VPN 使用，作為公網訪問的地址。

網絡出口基本架構

單位的互聯網網絡邊界定義為邊界接入區，邊界接入區由一臺分帶寬交換機、兩臺負載均衡和兩臺防火墻組成。電信和聯通的線路被分帶寬交換機一分為二，分別連接鏈路負載均衡設備。負載均衡設備連接兩臺防火墻，防火墻采用雙機方式部署。防火墻負責出口的安全策略控制及部分應用服務器的地址轉換，利用靜態路由與NAT 技術，均衡雙出口流量。配置好出接口與區域、NAT 轉換與路由通信。防火墻的e0/1 口設置為電信的出口，e0/3 口設置為聯通的出口，防火墻的對外接口連接2 個ISP(電信和聯通)。

與邊界交換區相連的是核心交換區，核心交換區由兩臺核心交換機組成，交換機采用雙機方式部署，VPN 設備以雙活模式旁路方式部署在核心交換機上，作為在公司外訪問公司業務系統的通道，如圖1 所示。

故障描述

VPN 設備部署完成后，在邊界墻上設置地址轉換策略通過公網可正常使用。在業務使用過程中，筆者發現接入聯通網絡（3G、4G、ADSL 等）的終端設備包括電腦、手機、Pad 等無法訪問VPN 的電信地址，在接入聯通網絡的設備上對電信公網地址進行Ping 測試發現不通，路由測試也不可達，如圖2 所示。

同時通過對邊界防火墻的抓包發現，在聯通公網訪問此電信公網地址時防火墻上相應端口抓包并無相關數據流量。因此，筆者初步判定運營商間互聯互通有問題，此后協調聯通和電信兩家運行商一起對故障進行了排查。

圖1 網絡出口拓撲圖

1.聯通運營商故障排查

登錄聯通的網管的局端設備進行查看，可以看到去往目的地址106.38.72.49的下一跳為202.97.32.120，如圖3 所示。

通過地址排查，可以看出從202.97.32.120 已進入電信網內，區域為AS 4134，如圖4 所示。

繼續對電信設備地址202.97.32.120 進行Ping 包測試，在發送500 個數據包不丟包后，可以判斷數據包已到達電信網內。

2.電信運營商故障排查

經聯通確認斷點202.97.57.101 下一跳進入北京電信城域網，在電信的斷點路由器上運行trace 命令對106.38.72.49 進行測試。查看斷點下一跳已進入互聯網出口專線的網內，如圖5 所示。由此可以判斷電信網內路由正常。

通過以上排查可以判斷運營商的ISP 路由沒有問題，數據的流向從聯通到電信是有路由可達，但實際數據卻無法訪問。因此需要進一步查看設備的回程路由是否正確，即從VPN 返回的數據包是否正確的從電信網絡到達聯通網絡。

圖2 路由跟蹤圖

圖3 聯通局端設備路由跟蹤圖

圖4 聯通跨越電信路由跟蹤圖

圖5 電信設備路由跟蹤圖

圖6 防火墻地址轉換日志圖

3.邊界防火墻排查

由于單位所使用的VPN在功能上無法進行回包測試，同時屬于生產業務系統，不能進行斷路測試。

因此，為了進一步確認問題，筆者用筆記本電腦搭建測試環境，將筆記本旁路部署在核心交換機上，分配內網地址100.100.1.14，在出口防火墻上做地址轉換，轉換為公網地址106.38.72.51。此時在防火墻上能查看到目的地址轉換的記錄，說明已有數據包到達防火墻，如圖6 所示。

在筆記本上對目標聯通地址進行路由測試，發現訪問聯通的地址數據包直接從聯通的出口發出，訪問電信的地址數據包直接就從電信的出口發出，因此無法直接模擬從電信跨越聯通的回程路由。

圖7 防火墻數據出入抓包圖

筆者由此聯想到是不是也是同樣的原因導致了數據回包不對而造成網絡訪問不通。為了進一步驗證，筆者在防火墻出口上進行抓包，發現了問題所在：從聯通訪問電信公網地址的數據來包在eth0/1 口進入（電信出口），但回包在eth0/3 口上（聯通出口），如圖7 所示。

解決方案

最終確認問題是由于數據包的進出口不一致導致，因此筆者在防火墻的配置上取消逆向路由設置，問題得以解決。

防火墻設備會話表會保存會話信息，并根據會話表進行包轉發及安全控制。如果開啟了逆向路由功能則返回的會話進入防火墻路由查找模塊后需要查返回會話發起的源地址的路由，如策略路由、ISP 路由、目的路由等。此案例中根據ISP 路由查到從eth0/3 路由出去，則該返回會話就會從eth0/3 出去，如果沒有查到，再按照原路返回，即從eth0/1 轉發出去。如果關閉逆向路由功能則返回會話不進行路由查詢，直接按照會話發起的原始方向進行返回，即從eth0/1 轉發出去。因此在取消了逆向路由后，數據包的回包直接從進入的端口返回，這樣就解決了數據包的出入端口不一致而導致的網絡不通的問題。

思考與建議

隨著單位信息化的逐步深入，如何發現、定位并快速解決網絡故障尤為重要。因此首先需要確定網絡故障點，恢復網絡的正常運行；然后發現網絡規劃和配置中的欠佳之處，改善優化網絡性能；最后觀察網絡的運行狀況，及時預測網絡通信質量。

對于企業網絡故障問題的排查解決，筆者提出以下建議：

對于可能出現的故障，應堅持每天例行巡檢制度。相關巡檢人員反饋巡檢結果，對當前的狀態進行記錄，對未來可能發生的問題進行預測。

每周重要時段負責系統與負責網絡的相關人員同時巡檢，以便遇到故障時及時協調處理。

積累運維經驗。單個系統遇訪問故障，重點巡查系統本身及其所在服務器；全局性問題時重點排查交換機、防火墻等網絡和安全設備。

建立知識共享機制。網絡設備、服務器等相關設備和系統的簡易操作進行共享，便于及時診斷故障。

建立與設備廠商的溝通聯絡機制。運維人員由于自身的局限性，對于設備較為底層的深入操作并不太深入，有時需要廠商介入指導，可以針對緊急情況進行協調處理，減少故障恢復時間。

建立短信告警機制，維護運維人員名單，導入短信發布模板，遇信息系統故障時及時向受影響的用戶發布通知。

部署網絡監控系統，針對網絡出現的故障能及時報警，為排查解決問題爭取寶貴時間

建立良好的運營商關系。有些互聯網故障需要電信運營商共同解決，而電信運營商所管轄網絡運維人員有時并不一定了解，因此在出現故障時可以及時與運營商一起針對業務進行排查，而不至于出現盲區。

結語

企業信息化越來越深入，所涉及的應用系統和管理的網絡也會越來越多，建立故障處置機制以及規范網絡建設尤為重要。

從技術上來講，公司應當優化網絡結構，擴展網絡帶寬，更換核心網絡設備；構建信息安全縱深防御，加強網絡安全防護技術手段；優化在公網環境下的便攜式計算機使用方式；構建基于公鑰基礎密碼設施，部署VPN 系統等，建立安全防護體系；逐步按照國家信息安全相關法規、標準，對系統進行定級、備案、改造、測評和整改。在此基礎上，建立信息化故障響應處理機制，確保信息化系統高效而安全的運行。

從管理上來講，對照技術建設情況，構建符合標準要求和實際管理需要的網絡與信息安全保障體系，編制并出臺信息安全等級保護頂層制度和安全防護策略文件；逐步建立應用系統、基礎設施、信息安全、應急處置等多層次的管理細則，完善信息化運行維護管理體系，落實定期演練要求，滿足網絡運行基本要求。