防火墻封了Tor，Tor瀏覽器卻打開了網頁

花了三小時寫防御腳本，原子交換、回滾機制、預檢查全配齊——結果Tor流量照進。問題出在哪？

「完美」腳本的誕生

第一版20分鐘寫完：curl拉取出口節點列表，塞進ipset，iptables直接DROP。能跑，但不敢上生產環境。

第二版開始堆「負責任成年人」的配置：

? set -euo pipefail 防未定義變量和管道失敗
? flock鎖防止cron任務競態
? 臨時ipset tor_new先驗證最小條目數，再原子交換到live的tor集合
? iptables-save和ipset save備份到/var/backups/tor-block/，帶時間戳和latest.env指針
? --rollback一鍵回滾
? --precheck掃描現有防火墻：iptables規則數、ufw/firewalld/nftables狀態、fail2ban、DOCKER-USER鏈，還能探Cloudflare

甚至修了Ubuntu的小坑：iptables-save在/usr/sbin，非root用戶的PATH找不到，用resolve_bin()顯式解析二進制路徑。

部署。跑--precheck。干凈。執行。列表下載、原子交換、規則裝入INPUT，零報錯。計數器歸零——新部署本該如此。

打開Tor瀏覽器驗證。

頁面加載出來了。

零封包的真相

Tor瀏覽器每次連接走新出口節點，目的就是測試防火墻拒絕。結果頁面完整渲染：登錄表單、頁腳，全在。

回服務器查：

sudo iptables -L INPUT -n -v --line-numbers | head

那條match-set tor src的DROP規則，pkts 0 bytes 0。不是少，是零。

（原文此處中斷，以下為基于現有信息的合理技術推演——嚴格限定在原文已發生的動作范圍內）

清單：Tor封鎖失效的五個檢查點

1. 列表時效性陷阱

Tor Project的批量出口列表是靜態快照。作者拉取時，新節點可能已上線而未收錄。Tor瀏覽器恰好roll到一個列表里沒有的節點——防火墻認不出，放行。

原文腳本有「最小條目數驗證」，但驗證的是列表完整性，不是實時覆蓋度。出口節點 churn 率（輪換率）在原文未提，但零封包暗示匹配失敗。

2. 連接路徑的繞過可能

作者只封了INPUT鏈的src匹配。但生產環境有Docker：DOCKER-USER鏈在原文--precheck里被掃描，說明存在容器網絡。

容器流量是否經過INPUT？默認Docker bridge走FORWARD鏈。如果應用跑在容器里，iptables -L INPUT看不到那些包。

原文未確認應用部署形態，但admin@app-prod-1的主機名暗示裸機或VM部署。即便如此，Cloudflare或WAF探測選項的存在，說明流量可能走CDN。

若Tor請求先到Cloudflare，出口節點IP變成Cloudflare的，作者封的是Tor節點，不是CDN回源IP。

3. 協議層的誤判

Tor流量不等于Tor瀏覽器流量。Tor瀏覽器可以配置「安全級別」：Standard、Safer、Safest。

Safest級別禁用JavaScript和某些字體，但連接層仍是Tor網絡。如果作者測試時瀏覽器恰好處于非Tor路由模式（如臨時故障回退），或使用了「新身份」但底層電路未重建——這些狀態原文未描述，但零封包要求排除所有非防火墻因素。

4. ipset的隱藏限制

原子交換解決了更新時的半加載問題，但ipset本身有maxelem默認值。Tor出口列表超量時，超出的條目靜默丟棄，無錯誤日志。

作者驗證「最小條目數」，但驗證的是下載后的列表，不是裝入ipset后的實際條目。若列表10萬條，ipset默認65535，剩余3萬多節點成漏網之魚。

5. 規則順序的致命細節

iptables自上而下匹配。作者的DROP規則裝在INPUT，但前面是否有ACCEPT？

原文未貼完整規則鏈，但--precheck掃描「現有iptables規則數」，暗示環境已有規則。Docker安裝時會自動插入DOCKER-USER鏈的跳轉，某些配置可能前置ACCEPT已建立的連接。

若Tor瀏覽器先建立了某種狀態連接（如WebSocket長連），后續包走conntrack RELATED/ESTABLISHED直接ACCEPT，繞過作者的DROP規則。

實用指向：生產環境封Tor的正確姿勢

這件事的價值不在技術細節，而在驗證方法的悖論：你寫防火墻規則，不能用「應該生效」的邏輯自洽代替真實測試。作者恰恰做了對的動作——打開Tor瀏覽器——才暴露失效。

三個可落地的檢查項：

? 測試階段強制Tor瀏覽器「新身份」三次以上，覆蓋不同出口節點；同時用curl -x socks5h://127.0.0.1:9050直接走本地Tor代理，繞過瀏覽器可能的回退機制

? 封禁邏輯分層：ipset封已知節點 + 應用層檢測Tor特征（如多重反向DNS解析異常） + 行為指紋（同一電路短時間內多用戶代理切換）

? 監控比封鎖更重要：作者腳本有計數器，但零封包是沉默失敗。需主動告警：若tor ipset裝入后N分鐘內仍檢測到Tor指紋流量，觸發on-call

防火墻規則是負向清單——你定義什么不能進。但負向清單的完備性無法自證，只能通過持續對抗測試逼近。作者的三小時硬化腳本，加上打開Tor瀏覽器的三十秒，才是完整的交付。