得物App萬米高空WiFi攔截記
0、前情摘要
在一次飛行途中，我司客戶遭遇到了得物App在飛機上的WiFi網絡訪問異常的問題。這讓我們意識到在特定場景下，用戶可能面臨無法使用得物App的困擾。經過SRE團隊與無線團隊、網絡團隊聯合全力排查與優化，最終成功解決了這一問題，并同時挖掘出全網防火墻設備在各個C端用戶工作生活場景訪問不到得物App的問題。為得物er穩定訪問得物提供保障，同時也輸出類似疑難問題排查模板。
1、知識速遞
1.1 什么是空中WiFi技術？
目前機載 WiFi 服務主要有兩大解決方案：地空寬帶（ATG）無線通信系統和機載衛星通信系統（SATCOM）。
- 地空寬帶（ATG）無線通信系統采用定制的無線收發設備，沿飛行航路或特定空域架設地面基站和對空天線，形成 地空通信鏈路。
- 機載衛星通信系統由利用衛星、飛機、衛星地面站三者進行數據通訊
兩者的技術優劣勢對比如下：
指標 | ATG | SATCOM |
時延 | <100ms | 較高，10-700ms，取決于衛星類型和軌道高度 |
覆蓋范圍 | 地面基站覆蓋的區域，主要在陸地上，最大半徑300km | 全球范圍，包括遠離陸地和海洋上的區域 |
網絡連通性 | 地面基站之間可能存在信號盲區 | 通過衛星信號傳輸，具有更高的連通性 |
可靠性 | 可能受地形和基站分布影響 | 受衛星信號強度和可用衛星數量影響 |
適用場景 | 主要適用于陸地上的飛行 | 適用于全球范圍內的飛行，包括跨洋航線 |
馬斯克搞的星鏈服務用的是近軌衛星群，距離地表在550公里范圍左右，時延基本在20ms以內，而我國目前用于客艙通信的衛星基本是同步衛星，離地距離36000公里，時延基本在500ms以上
1.2 電商業務為什么會普遍使用TCP協議
當今互聯網主流通信協議使用的TCP/UDP協議,遵守TCP/IP的4層網絡模型,其中TCP協議相比UDP提供了可靠的、面向連接的通信：
- 三次握手
在TCP協議下，數據傳輸之前，通信雙方需要先建立連接，建立連接時會進行一系列的握手過程，確保數據傳輸前通信雙方的狀態和能力都是正常的
- 包確認機制（ACK)
在數據傳輸時，TCP協議會將數據分成多個包進行傳輸，并且會對每個包進行校驗和確認，確保數據能夠正確無誤地傳輸。
- 擁塞及流量控制
TCP協議提供了擁塞控制和流量控制等機制，能夠自適應地調整傳輸速率，防止網絡擁塞和數據丟失
基于以上TCP協議保證數據的可靠性和完整性，因此在電商應用中廣泛使用TCP協議。
2、天地協同排查
2.1 方案制定
了解了空中WiFi實現技術后，如何定位排查問題便是我們SRE專家思考的問題。對于任務疑難雜癥，永遠的三板斧：模擬復現問題，抓包，分析完整請求鏈路。本次麻煩的是場景特殊，需要在空中WiFi環境上才能復現，同時抓包又是一個技術活，只能我們技術團隊親自出馬了。這里要特別表揚無線平臺的客戶端同學，為了完全復現場景，特地早上7點乘指定班機來回測試，收集重要抓包數據。
2.2 測試方案&工具確認
因復現場景苛刻（必須萬米高空WiFi才會開啟），必須制定好完整的測試方案完成盡可能多的數據收集。無線平臺團隊和SRE團隊協同準備好了測試工具包，可進行網路層面測試包含ping和traceroute，APP層面的請求測試，單域名訪問測試等。并準備好抓包工具，在測試時留存所有抓包數據。SRE在公司同步值班抓取服務端請求包，做雙向對比。
下面是我們的SRE老司機梳理的各協議段排查工具，大家可收藏：
盡管TCP協議具有面向連接、可靠性高等優點，但是在實際的網絡環境中，由于網絡的復雜性、拓撲結構、應用缺陷等因素，會導致各種網絡問題, 以下我們將排障工具和4層模型做了一個歸類：
我們排障一般按從下往上逐層排除可疑點這個思路來時，日常工作會少走一些彎路
2.3 問題復現&測試抓包
客戶端測試同學在飛機巡航狀況下，連上飛機WiFi后，打開得物App，的確存在訪問不了得物App的情況。于是，客戶端同步地下值班人員開啟測試。
（1）打開得物App，瀏覽不同頁面并截圖，確保影響范圍
（2）進行網絡測試包含（ping、traceroute等）
（3）在瀏覽器單獨訪問典型接口，如主接口、社區接口、圖片鏈接等
（4）測試其它電商平臺，觀察其訪問情況。
以上所有訪問保留截圖、日志、抓包數據等
值班SRE同等時間抓取相同時間的接口的入口請求包，保存下來，后做對比分析。
2.4 數據整理
2.4.1 鏈路診斷
網絡鏈路層測試：用ping/traceroute等工具對app.dewu.com/m.dewu.com相關域名進行了拔測，均顯示網絡層正常
這里簡單介紹一下ping/traceroute工具工作原理
（1）ping工具
ping是一種基于icmp協議開發的網絡診斷工具，工作于第3層，其工作原理是向目標主機發出一個icmp的echo request數據包，并等待接收echo response數據包，然后程序自動估算丟包率和數據包的rtt，因此主要用于網絡連通性和網絡時延的診斷
此工具原始作者是Mike Muuss,于1983年開發,后面macos/win/linux相繼實現各自版本，以下沒有特殊說明的情況下，所有相關參數或敘述主要是針對linux版本展開的
- ping工具集成在iputils包中，開源項目https://github.com/iputils/iputils
- 一個基于icmp協議的ping包格式
上圖中紅色標注的屬于ip和icmp協議頭中較關鍵的字段：
協議 | 字段 | 取值 | 含義與作用 |
IP | Identification | 1-65535 | 數據包唯一標識符，另外功能用于ip分片，當一個ip包的負載超過1480時，ip包要分成多片，且多片的identification保持一樣 |
IP | Flags | 3個bit位 | 用于指示IP數據包是否允許分片和每個分片的位置，它的三個bit分別是：
|
IP | TTL | 1-255 | 主要控制網絡中出現回路時，避免IP包無休止的在網絡上轉發，每經歷一個路由器時，此值會減1； 小訣竅：Linux的網絡中默認一般為64，因此在服務側抓包看到的ttl值后，64-當前ttl值，即可知道此包經歷過多少路由器 |
IP | Protocol | 1/2/6/17 | 代表承載的上層協議： 1：ICMP， 2：IGMP， 6：TCP， 17：UDP |
ICMP | Type | 0-18 | 節選部分解釋： 回復應答（ICMP類型0）：ping命令用到該類型的數據包以測試TCP/IP連接； 目標不可達 （ICMP類型3）：用以指示目標網絡、主機或者端口不可達； 回復請求（ICMP類型8）：ping命令用該類型的數據包測試TCP/IP連接； |
ICMP | Identifier | 隨機/指定值 | Identifier 字段在 Echo Request 和 Echo Reply 消息中都存在，作用是幫助區分不同的 ICMP 會話。在發送 Echo Request 消息時，發送方會隨機地生成一個16位的標識符，然后在接收響應包的時候，通過比較響應報文中的標識符，來確認響應報文是否是自己發送的響應 |
ICMP | SequanceNumber | 1-65535 | 當一個 ICMP Echo（ping）請求消息被發送給目標主機時，Sequence Number 字段的值通常從0開始計數，每發送一個 ICMP Echo 請求就會遞增一個。而當目標主機收到 ICMP Echo 請求后，會將它的 Sequence Number 值復制到 ICMP Echo Reply（ping回應）消息中，以便請求端確認它所接收到的回應消息是對相應請求的響應 |
ICMP | TimeStamp | 時間戳 | 主要用于測量RTT，當一個主機收到一個 ICMP Timestamp 請求時，它會記錄返回的 ICMP Timestamp 回應消息中的當前時間戳，并計算出請求和回應之間的時間差 |
- ping的部分參數默認值
參數 | Linux 默認值 | 說明 |
-t | 64 | 指定ttl數值 |
-c | 發送無限數量的 ICMP 數據包 | 指定發送 ICMP 數據包的次數 |
-s | 56 字節 | 指定 ICMP 數據包的大小 |
-W | 10秒 | 指定每個響應包超時時間，單位為秒 |
-i | 1 秒 | 指定發送 ICMP 數據包的時間間隔 |
- ping的例外
從開頭描述的ping的原理可以看出，目標設備必須回復echo response才能判斷網絡連通性和時延，因此如果目標設備設置了類似“net.ipv4.icmp_echo_ignore_all=0”禁止或者防火墻設置了丟棄icmp包策略，此測試結果基本失效,此時需要其它工具如telnet/nc/curl等工具配合測試了
特別有意思的一點：在s20190709版本和此前版本，Identifier取值使用是當前ping進程的pid,如下圖所示：
ping當前進程pid是2570,16進制值是0xa0a,因此在包中第25和26字節中展示出來是0xa0a，之后的版本考慮不安全，因此全部改為隨機值了
ping_common.c
//s20190709版本和此前的版本
if (sock->socktype == SOCK_RAW)
ident = htons(getpid() & 0xFFFF);
//之后的版本
if (sock->socktype == SOCK_RAW && rts->ident == -1)
rts->ident = rand() & IDENTIFIER_MAX;（2）traceroute
- 功能與作用
用于查找數據包從源到終點所需要的網絡路徑，并識別這些路徑上的瓶頸和故障
- 工作原理
它發送一份TTL字段為1的IP數據包給目的主機，處理這份數據包的第一個路由器將TTL值減1，丟棄該數據包，并發送一份超時ICMP報文。這樣就得到了該路徑中的第一個路由器的地址。然后traceroute 在發送一份TTL=2的數據包，這樣我們就能得到第二個路由器的地址， 繼續這個過程直至該數據包到達目的地主機
這個數據包承載的上層協議可以是ICMP/UDP/TCP
- 工具發展歷程
最初是在1987年，由Van Jacobson主導實現，后面macos/win/linux/bsd等也都實現了各自版本，主流linux發行版基本使用的是這個項目https://traceroute.sourceforge.net/提供的
- 配置初始值
//代碼配置節選
#define MAX_HOPS 255 //最大跳數，限制 traceroute 能夠追蹤到的最遠節點的數量
#define MAX_PROBES 10 //每個路由節點的最大探測次數
#define DEF_HOPS 30 //默認的最大跳數
#define DEF_NUM_PROBES 3 //默認的每個節點的探測次數
#define DEF_WAIT_SECS 5.0 //默認的等待每個節點響應的時間
#define DEF_DATA_LEN 40 //IP包上的負載默認大小
#define MAX_PACKET_LEN 65000 //最大的包長度，默認為 65000 字節
#ifndef DEF_AF
#define DEF_AF AF_INET // 默認的地址族，一般設置為 AF_INET，表示 IPv4
static const char *module = "default"; //默認使用udp進行探測
static tr_module default_ops = {
.name = "default",
.init = udp_default_init,
.send_probe = udp_send_probe,
.recv_probe = udp_recv_probe,
.expire_probe = udp_expire_probe,
.header_len = sizeof (struct udphdr),
};
#define DEF_START_PORT 33434 /* udp探測時啟始探測端口 */- 包格式分析
從抓包可以驗證代碼實現邏輯，以及整個探測過程(tcpdump host 1.1.1.1 -Nn -w 保存文件名.pcap)
從兩個工具的介紹和測試數據來看，說明網路層面是正常的。
2.4.2 應用層測試
空中側從ios/android終端，https/http等維度對我司后臺服務接口進行了測試驗證，同時也對友商的app進行了購物體驗，只有得物App的接口返回異常（https/http),且使用瀏覽器測試時返回帶有攔截提示的頁面；
2.4.3 網絡抓包
空中側對ios端進行了抓包，地面側在高防入口進行了抓包，從client/server側角度看，雙方都認為對方發起了強制斷開（reset）信令：從手機端看認為是高防（服務端）先斷開的，從高防側看認為是手機（客戶端）先斷開的
ios端：
高防端：
tcpdump是一個超級好用的開源的抓包工具，一直是我們SRE最重要的工具之一，這里給大家分享一下：
tcpdump是一個功能強大的命令行網絡數據包截獲工具。
通過使用 tcpdump，可以捕獲和分析網絡中的數據包流量，從而能夠診斷網絡問題、監視網絡行為、進行網絡安全審計等操作。
tcpdump也是作為學習網絡協議和數據包結構的非常好的工具，用于對網絡數據包進行分析和解碼。
- tcpdump工作在數據鏈路層
- 工作原理
- 網絡數據包截獲：通過調用 libpcap 庫捕獲從指定網絡接口傳輸的數據包。具體來說，libpcap 庫利用操作系統提供的原始套接字(Socket)接口來截獲網絡數據包，然后通過回調機制將數據包傳遞給tcpdump進程。
- 數據包過濾：tcpdump可以根據用戶設置的過濾規則對捕獲到的數據包進行過濾。過濾規則利用 BPF (Berkeley Packet Filter) 過濾器來實現，這是一個基于指令集的過濾器，它能夠對數據包的各個字段進行匹配和過濾，過濾出符合條件的數據包。
- 數據包解析：一旦通過過濾器選定了要截獲的數據包，tcpdump就會對這些數據包進行解析和格式化，展示其中的各個字段和屬性。數據包解析過程的關鍵是數據包格式的識別和解碼，tcpdump和 libpcap 庫可以識別和處理多種數據包格式，包括以太網、IPv4/IPv6、TCP/UDP、DNS、HTTP 等等。
- 數據包展示：最后，tcpdump將解析后的數據包內容輸出到標準輸出或者用戶指定的文件中，供用戶進行查看和處理。用戶可以對輸出內容進行進一步處理，比如進行過濾、排序、統計等操作，以更好地理解網絡數據流量，分析網絡協議和應用行為，發現問題和優化性能等。
2.5 數據包分析
- 從網絡鏈路層測試數據結果看，網絡層上端口是正常通行的，包括tcp三次握手。那說明整個網絡鏈路是通暢的。不存在網絡不通的情況。（從友商可正常訪問來看也能印證這個問題）
- 從網絡抓包數據來看，從client/server側角度看，雙方都認為對方發起了強制斷開（reset）信令：從手機端看認為是高防（服務端）先斷開的，從高防側看認為是手機（客戶端）先斷開的
- 從應用層上截圖來看，貌似受到類似acl的攔截
綜合結論：最有可能是受到類似防火墻之類的中間層設備攔截
2.6 模擬復現
從如下截圖來看，可能和我司的防火墻同一廠商，于是迅速和網絡同學組織了一次模擬驗證：
將某一終端IP在防火墻上開啟“禁用訪問網站/軟件下載”策略，
然后在瀏覽器上請求https://app.dewu.com,發現命中此策略
同時也從client端及防火墻出口同時進行了抓包：
電腦client側：
防火墻出口側：
基于上面的證據鏈，基本可以確認防火墻的策略誤判了公司得物App的域名為下載類網站
2.7 廠商溝通
將我司復現的問題反饋給廠家后，廠商的策略工程師確認此“訪問網站/軟件下載”策略存在bug，并在溝通中的過程也確認了此航司與我司都是使用同一廠商的防火墻。
2.8 進展同步
4/18，廠商進行了全網策略發布
4/19，我司ac設備自動進行了策略更新
4/21，請朋友幫忙在同一航班驗證得物App使用流暢，驗證通過
3、網絡技術點回顧
3.1 traceroute
從本次的traceroute數據中我們可以確定一點：
- 空中WiFi到國內電商主要域名的時延基本都在600ms以上，此數據也進一步確認空中WiFi使用的SATCOM方式（高延遲）
3.2 ip包頭
- ip包頭中的ttl正常情況下每經過一個路由器，TTL的值就會減1，直到服務器接收時不再變化，也就是正常情況下client和server的包中的值不應該有變化，如果有較大變化都基本是中間設備篡改
- ip包頭中另外一個字段identifcation用于標識IP數據報的唯一性，如果一個ip包需要分片（MTU超過1460），則每個分片的ip包中的identifcation數值一樣; 同時RFC791規范并沒有規定Identification字段的取值方式，但實際情況下我們看到的依次增長（MTU超過1500字節加1），如果有跳變很大，基本也是中間設備篡改
3.3 AC設備網絡管理
AC（Access Controller）是一種中央控制的網絡設備，用于管理多個AP（Access Point）的上網行為。AC 設備上網行為管理功能可以幫助管理員對用戶的上網行為進行監控和管理，包括以下方面：
- 認證和授權管理：AC 設備可以實現多種認證方式，如無線局域網安全性協議（WPA、WPA2）、802.1X 認證等，確保用戶的合法身份，并授權其訪問網絡。
- 流量控制：AC 設備可以對接入的用戶進行流量控制，限制其上行和下行的帶寬、流量總量等參數，以避免網絡擁堵和單個用戶占用過多帶寬資源。
- 上網行為過濾：AC 設備可以對用戶的網絡訪問進行過濾，禁止用戶訪問某些不適宜的網站或應用，確保網絡的安全和穩定。
- 用戶管理和監控：AC 設備可以對所有接入用戶進行統一管理和監控，包括用戶的身份、設備類型、MAC 地址、IP 地址、上網時長等，幫助管理員了解用戶的上網習慣和行為特征，發現和處理異常行為。
功能實現：
用戶認證，可以基于用戶和用戶組來管理用戶的登陸，可以配置本地認證也可以AAA認證等等
URL過濾，運用HTTP識別技術就是獲取到HTTP請求時帶有的host字段來獲知用戶想要訪問的網站，以此來達到過濾網站目的（本次出問題就是此功能上）
HTTP：三次握手后，HTTP發出請求，帶有host字段，從這里得知訪問網站
HTTPS：三次握手后會建立SSL加密通道，在SSL第一次握手時客戶端發出client hello報文時，會有個server name字段（SNI），從這里獲知后進行相應的過濾
參考資料：
1）中國民航網
2）東航官網
3）通信世界
4）中興通訊5G地空通信白皮書2020
