我猜這麼詭異的動作，應該是牆，然後用iptables嘗試復現了劫持的情景

情況

分析

因爲對DNS不是很懂，根據網友的信息，這次事件跟DNS應該沒啥關係，所以相信以下4個ip地址是正確的：

github.io.		3600	IN	A	185.199.108.153
github.io.		3600	IN	A	185.199.111.153
github.io.		3600	IN	A	185.199.109.153
github.io.		3600	IN	A	185.199.110.153

嘗試ping以下自己的站點，TTL爲51，比較穩定：

➜  ~ ping xuanxuanblingbling.github.io
PING xuanxuanblingbling.github.io (185.199.108.153): 56 data bytes
64 bytes from 185.199.108.153: icmp_seq=0 ttl=51 time=104.540 ms
64 bytes from 185.199.108.153: icmp_seq=1 ttl=51 time=98.988 ms
64 bytes from 185.199.108.153: icmp_seq=2 ttl=51 time=98.148 ms
64 bytes from 185.199.108.153: icmp_seq=3 ttl=51 time=104.147 ms
^C
--- xuanxuanblingbling.github.io ping statistics ---

用curl訪問目標站點80端口： curl http://xuanxuanblingbling.github.io/ ，TTL也爲51

但是如果訪問目標站點443端口，無論是通過瀏覽器訪問還是curl後跟https，SYN的ACK回覆的TTL均爲57：

經過網友的提示，知道了工具mtr，全稱my traceroute，在mac和zsh的環境下會有一點環境變量的問題： Mac 下使用 MTR 路由工具 ，使用如下命令： 

➜  sudo mtr xuanxuanblingbling.github.io
➜  sudo mtr xuanxuanblingbling.github.io --tcp -P 80
➜  sudo mtr xuanxuanblingbling.github.io --tcp -P 443

可以看到ICMP的ping包和訪問tcp80的包到達目的地都是14跳，而訪問tcp443的包到達目的地的包都是8跳，57-51=14-8=6。所以可以看出，訪問同一個ip地址的不同的端口的包，在219.158.105.237後分道揚鑣了。這個地址能被這個工具找到的原因是，這個工具可以發送TTL依次遞增的TCP包，常用的traceroute只能發送TTL依次遞增的ICMP包。

路由屬於網絡層，tcp 屬於傳輸層。理論上路由與端口無關。不過，若將這個結果看做路由，這裏就是針對TCP443端口進行了路由，而且路由到了另一個相同目標地址的主機上了。同時也可以使用 http://port.ping.pe/ 這個工具進行在線的測試：

這裏雖然看不出訪問80與訪問443的路徑差異，但是可以看出443端口在某些網絡上壓根就連不上：

詭異的TTL

所以可以看出icmp和tcp80的包都應該是到達了真正的github的服務器並且得到了響應，那麼訪問tcp443的數據包，到底是誰回覆的呢？我們通過curl請求一個包仔細分析，有意思了：

curl https://xuanxuanblingbling.github.io/

總共是12個包：

  1. TCP握手，3個
  2. client server各自hello和ACK，4個
  3. client發不認識的CA並且RST，2個
  4. server回以上的ACK，3個

server總共回了6個包，這6個包裏有4個不一樣的ttl值：

如此詭異的動作應該是牆吧。數據包: 2020-03-27-github-io-443.pcapng

復現

中間人也好，TCP阻斷也好。這些詞都沒有說明，我現在訪問的目標ip真的是 185.199.108.153 ，在wireshark中看到的回包中的IP也是 185.199.108.153 。但我們知道這個回包並不是真正的 185.199.108.153 回覆的，也就是說有人僞造了回包中的源IP。這個技術怎麼實現呢？其實用iptables就能實現，首先在虛擬機的ubuntu進行如下配置，注意這裏的ens33是網卡名，每個主機不同： 

sysctl -w net.ipv4.ip_forward=1 # 開啓路由器轉發
sudo iptables -F -t nat         # 清空nat表
sudo iptables -t nat -L         # 查看nat表
sudo iptables -t nat -A PREROUTING -i ens33 -p tcp --dport 443 -j REDIRECT --to-port 8080 # 使用PREROUTING鏈將所有發往tcp443的包轉發到本地8080端口
echo "hello xuanxuan" | nc -l 8080 # 在本地8080端口監聽

然後在另一臺windows虛擬機中安裝好nc，並且把網關配置成ubuntu的ip地址，然後通過nc訪問目標的443端口：

發現這個數據包： 2020-03-27-iptables-443.pcapng 的確是源IP被僞造了，而且我並沒有在任何一張網卡上設置IP地址爲： 185.199.108.153 ，所以這個回覆hello xuanxuan的數據包的源IP是iptables自己填寫的，即iptables本身就能實現源地址僞造的功能。所以如果在骨幹路由器的節點上進行了類似的操作就可以達到這次的效果，不過可以看出我們這裏模擬的TTL還是規律的，至於現實中爲什麼會出現TTL如此詭異的情況？後面到底還做了什麼手腳？我不知道。有的網友說用了BGP FlowSpec這個技術，我也不是很懂。不過我認爲技術上是：

  1. 針對不同端口進行了類似路由的處理
  2. 且僞造了源IP進行回覆
相關文章