Firewall on Tarragon

GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點、救援入口、IAP 規則與 IAM、停用舊規則驗證、OS Login 啟用與移除外部 IP

Sun, 25 Oct 2026 00:00:00 +0800

實測日期是 2026-10-24，在 GCP 測試專案 blog-verify-20261024（zone asia-east1-b，default 網路）上，對一台 Debian 12 的 e2-micro 與一台 Windows Server 2022 的 e2-medium，用本機的 gcloud 照這一篇的順序操作；IAM 條件與 OS Login 角色另外用第二個 Google 帳號登入驗證。

這篇記錄把 VM 的管理員登入從防火牆對 0.0.0.0/0 開放 22 與 3389 port，改成走 IAP TCP forwarding 的實際操作。內容依操作的順序是：切換前盤點依賴舊規則的連線；準備並實際登入一次救援入口（Serial Console 與本機救援帳號）；啟用 IAP API、開啟 IAP 的稽核紀錄、建立只放行 IAP 來源的防火牆規則與 network tag；授予開通道的 IAM 權限；停用舊規則、用 IAP 驗證新規則；刪除對外開放的規則；收斂 default-allow-internal 與 default-allow-icmp；啟用 OS Login；建 Cloud NAT 並移除外部 IP。每一步寫出這次的取值與實測結果，以及沒做或換一種做法時的結果；替代做法與沒做時的結果沒有另外標註的是這次實測看到的，照官方文件推出的寫出文件，推論的寫明沒有實跑。IAP 的連線路徑、預設規則為什麼要換、切換的順序為什麼這樣排、IAM 授權的範圍、連不上時的依層判讀、OS Login 與 Cloud NAT 的機制，寫在 GCP VM 的 SSH 與 RDP 管理通道：從預設的全開規則改走 IAP TCP forwarding（下文稱概念篇），這裡不重寫。

這一篇的指令以單台 VM 為對象。由 MIG 或 GKE 管理的 VM，同樣的設定改寫在 instance template 與 node pool 上，做法在 GCP 上 MIG 與 GKE 管理存取的實測紀錄；Shared VPC 的 service project、用 Terraform 管理的專案，指令要改寫在別的位置；新專案從零開始則可以跳過盤點與停用驗證。這幾種環境的調整見概念篇開場之後「另外四種環境要先調整做法再往下讀」那一段。

切換前的盤點：依賴舊規則的連線

default-allow-ssh 放行的不只是管理員本人的 SSH：CI 或部署腳本用外部 IP 直連 VM、Ansible 這類組態管理工具、監控程式的探測、第三方廠商的維護連線，都可能經過這條規則，而預設規則沒有開 logging，手上沒有紀錄可以查出它們。盤點分兩步。先對舊規則開啟 logging，列出經過它的候選來源：

1# 對舊規則開啟 logging，之後每一次放行都會寫進 Cloud Logging
2gcloud compute firewall-rules update default-allow-ssh --enable-logging
3gcloud compute firewall-rules update default-allow-rdp --enable-logging
4
5# 觀察一段時間後，列出經由舊規則連進來的來源 IP 與次數（RDP 把規則名稱換成 default-allow-rdp）
6gcloud logging read \
7  'logName:"compute.googleapis.com%2Ffirewall" AND jsonPayload.rule_details.reference:"default-allow-ssh"' \
8  --freshness=7d --format="value(jsonPayload.connection.src_ip)" | sort | uniq -c

--freshness=7d 是查詢往回看的時間長度，依自己的部署週期調整，要涵蓋到一次完整的部署與排程工作。實際依賴這條規則的連線，要從 VM 上的成功登入紀錄找（理由見概念篇〈切換到 IAP 的順序〉）：

1# 在 Linux VM 上列出這段期間成功的 SSH 登入：帳號、來源 IP 與金鑰指紋
2sudo journalctl -u ssh -u sshd --since "7 days ago" | grep "Accepted publickey"

每一行的格式是 Accepted publickey for from ... <金鑰指紋>，用帳號與金鑰指紋就認得出是哪個人或哪個自動化工具。Windows VM 看事件檢視器的安全性紀錄裡事件 ID 4624、登入類型 10（遠端互動，也就是 RDP）的事件。找出來的非人員來源要先改走 IAP 才能停用舊規則：CI 與自動化工具用服務帳號開 IAP 通道，一般 ssh 的工具照概念篇〈IAP TCP forwarding 的連線路徑與來源範圍〉的 ProxyCommand 改設定。

沒做時：停用舊規則的那一刻，依賴它的 CI、監控與廠商連線跟管理員的一起被拒；這些失敗出現在部署或排程執行時，不一定在切換當下被看到（從規則的作用推論，這次沒有實跑）。
替代做法：觀察期縮短或省略，換到的是切換提早，付出的是只盤點到觀察期內發生過的連線，一個月跑一次的排程會漏掉；只看防火牆紀錄、不看 VM 上的登入紀錄，換到的是不必登入每一台 VM，付出的是 CI 這類來源 IP 每次不同的連線認不出來（兩者都從紀錄的形狀推論，這次沒有實跑）。

準備救援入口：Serial Console 與本機救援帳號

Serial Console 透過 VM 的虛擬序列埠提供登入，不經過 VM 的網路設定與 sshd，在防火牆 tag 漏加、sshd 設定改壞、OS Login 設錯、磁碟滿導致 sshd 起不來時當作救援入口。它用 VM 內的本機帳號密碼登入，與 metadata 金鑰、OS Login 都無關，所以救援帳號要在 VM 還正常時就建好：

1# 在每台 Linux VM 上建一個設了密碼的本機救援帳號（RHEL 系把 sudo 群組換成 wheel）
2sudo useradd -m rescue && sudo passwd rescue && sudo usermod -aG sudo rescue
3
4# 確認 sshd 仍然只收金鑰，救援帳號的密碼只在 Serial Console 上有效
5sudo sshd -T | grep -i passwordauthentication

rescue 是自己取的帳號名稱。密碼用密碼管理工具逐台隨機產生、存在團隊的密碼庫，不同 VM 不共用同一組；持有救援密碼的人離開團隊時，逐台輪替。sshd -T 印出 sshd 實際生效的設定，那一行要是 passwordauthentication no，否則救援帳號的密碼也能從 SSH 登入。Windows VM 的序列主控台（Special Administration Console）用 Windows 的本機管理員帳號登入，要事先確認那個帳號的密碼在手上。

Serial Console 的互動登入預設關閉，平時保持關閉，救援時才對單一 VM 開啟：

1# 救援時對單一 VM 開啟 Serial Console 並連上
2gcloud compute instances add-metadata  --zone= --metadata serial-port-enable=TRUE
3gcloud compute connect-to-serial-port  --zone=
4
5# 救援結束後關回去
6gcloud compute instances add-metadata  --zone= --metadata serial-port-enable=FALSE

與用 gcloud compute instances list 查，第一欄是 VM 名稱、第二欄是 zone。建好救援帳號之後，對一台 VM 照上面的指令開啟、用 rescue 登入並執行一次 sudo -v 確認 sudo 可用，再關回去；這次在 Debian 12 的 VM 上實跑，登入與 sudo 都成功。Windows VM 的 SAC 這次沒有實跑。

沒做時：停用舊規則、或之後啟用 OS Login 時任何一項設錯，VM 沒有不經過網路與 sshd 的入口；剩下的路是在 metadata 設 startup-script（Linux）或 windows-startup-script-ps1（Windows）、重開機以 root 或 SYSTEM 執行來建帳號或改回設定，或把開機磁碟卸下掛到另一台 VM 修改，兩條都要重開機（Compute Engine 的啟動腳本與救援文件，這次沒有實跑）。
替代做法：
- 救援帳號寫進自訂映像檔，換到的是新建的 VM 一開始就有，付出的是密碼雜湊在每台 VM 上相同、要輪替就要重做映像（推論，這次沒有實跑）。
- 靠 startup-script 臨時建帳號，換到的是平時不留密碼，付出的是救援時要重開機，而且 startup-script 存在 metadata 裡，有讀取權限的人都看得到內容（Compute Engine 的 metadata 文件，這次沒有實跑）。
- 組織強制了 compute.disableSerialPortAccess 時，救援名單要有能對專案解除這條政策的人，見 GCP VM 的 SSH 與 RDP 管理通道的〈組織層級的護欄：Organization Policy 與階層式防火牆〉。

啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則

IAP 端點以 API 的形式在專案上開關，沒有啟用時，--tunnel-through-iap 的連線在 IAP 端點那一步就開不起來：

1# 啟用 IAP API（每個專案一次）
2gcloud services enable iap.googleapis.com

同一步在 Google Cloud 控制台的「IAM 與管理 > 稽核記錄」為 Cloud Identity-Aware Proxy 開啟 Data Access 紀錄裡的「管理員讀取」（ADMIN_READ）類型。開通道時 IAP 檢查的權限 iap.tunnelInstances.accessViaIAP 歸在這個類型，每一次開通道會留下一筆方法名稱為 AuthorizeUser 的紀錄。開啟之後經由 IAP 連一次，查到這次連線的紀錄才算開對了類型（protoPayload.resourceName 是 VM 的執行個體 ID）：

1gcloud logging read 'protoPayload.serviceName="iap.googleapis.com" AND protoPayload.methodName="AuthorizeUser"' \
2  --freshness=1h --format="value(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName)"

也在同一步確認所有要開通道的 Google 帳號都已強制兩步驟驗證，理由見概念篇〈IAP 的 IAM 授權範圍：誰拿得到通道〉最後兩段。

沒做時（不開 ADMIN_READ）：開通道的帳號與目標 VM 沒有 VM 以外的紀錄，事後調查只剩 Admin Activity 裡的設定變更與 VM 上的 sshd 紀錄；開啟之前的通道紀錄查不回來（Cloud Audit Logs 文件，這次沒有實跑）。
替代做法：只開「資料讀取」（DATA_READ）實測過：連了十次左右，紀錄零筆。兩種都開，換到的是不必判斷權限歸在哪一類，付出的是紀錄量與費用增加（推論，這次沒有量）。

新規則只開需要的 port，並用 target tag 限定作用的 VM：

 1# 放行 IAP 的 IPv4 來源連到帶指定 tag 的 Linux VM 的 22 port
 2gcloud compute firewall-rules create allow-ssh-from-iap \
 3  --network= \
 4  --direction=INGRESS \
 5  --action=allow \
 6  --rules=tcp:22 \
 7  --source-ranges=35.235.240.0/20 \
 8  --target-tags= \
 9  --enable-logging
10
11# 有 Windows VM 時，另建一條放行 3389 port 的規則，用另一個 tag
12gcloud compute firewall-rules create allow-rdp-from-iap \
13  --network= \
14  --direction=INGRESS \
15  --action=allow \
16  --rules=tcp:3389 \
17  --source-ranges=35.235.240.0/20 \
18  --target-tags= \
19  --enable-logging

allow-ssh-from-iap、allow-rdp-from-iap：規則名稱，自己取，同一個專案裡不能重複。
：VM 所在的 VPC 名稱，預設網路就是 default，自建網路用 gcloud compute networks list 查。
、：自己取的 network tag 名稱，例如 ssh-iap、rdp-iap。SSH 與 RDP 用不同的 tag，Linux VM 就不會被順便開了 3389。
--enable-logging：讓防火牆把這條規則的每一次放行寫進 Cloud Logging，驗證新規則與之後稽核都要用到。
--source-ranges=35.235.240.0/20：Google 公開的 IAP 來源位址段，每個專案都相同；--rules 依通道填要開的 port（SSH 是 tcp:22、RDP 是 tcp:3389）。這兩條規則沒有寫 --priority，預設是 1000（實測），比 default-allow-ssh 的 65534 先被評估。

自建的 custom-mode VPC 有 IPv6 VM 時，再建一條名稱不同（例如 allow-ssh-from-iap-v6）、--source-ranges=2600:2d00:1:7::/64、其餘引數相同的規則。接著對每台 VM 加上對應的 tag，VM 分布在不同 zone 時逐台以各自的 --zone 執行：

1gcloud compute instances add-tags  --zone= --tags=
2gcloud compute instances add-tags  --zone= --tags=

沒做時（漏加 tag）：停用舊規則之後，IAP 回 4003（failed to connect to backend），Connectivity Tests 指出擋下它的是 default-deny-ingress。
替代做法：
- 省略 --target-tags，換到的是不必逐台加 tag，付出的是 IAP 來源連得到網路裡每一台 VM 的 22 port（照規則的作用推論，這次沒有實跑）。
- 把 --rules 寫成 all，換到的是不必列 port，付出的是 IAP 來源連得到每一台 VM 的每一個 port，等於把 default-allow-internal 的寬度複製給 IAP（照規則的作用推論，這次沒有實跑）。
- 改用 --target-service-accounts 以服務帳號選 VM，換到的是 tag 不能被持有 VM 修改權限的人隨手加上（能編輯 VM 的人改得了它的 tag），付出的是同一個服務帳號的 VM 全部一起套用，而且 VM 換服務帳號要停機（VPC 防火牆規則文件，這次沒有實跑）。

授予開通道的 IAM 權限

開通道的權限是 IAM role roles/iap.tunnelResourceAccessor。下面的指令把它綁在專案層級，並用 IAM Conditions（在角色綁定上附加條件，條件成立時這個綁定才生效）限定可以連的 port 或期限；條件的寫法依環境選一種：

 1# 只有 Linux VM：條件限定只能連 22 port
 2gcloud projects add-iam-policy-binding  \
 3  --member=user: \
 4  --role=roles/iap.tunnelResourceAccessor \
 5  --condition='expression=destination.port == 22,title=iap-ssh-only'
 6
 7# 同時有 Windows VM：條件放行 22 與 3389
 8gcloud projects add-iam-policy-binding  \
 9  --member=user: \
10  --role=roles/iap.tunnelResourceAccessor \
11  --condition='expression=destination.port == 22 || destination.port == 3389,title=iap-ssh-rdp'
12
13# 只允許連特定一台 VM 的 22 port
14gcloud projects add-iam-policy-binding  \
15  --member=user: \
16  --role=roles/iap.tunnelResourceAccessor \
17  --condition='expression=destination.port == 22 && destination.ip == "",title=iap-ssh-one-vm'
18
19# 外包或臨時存取：到期之後綁定自動失效
20gcloud projects add-iam-policy-binding  \
21  --member=user: \
22  --role=roles/iap.tunnelResourceAccessor \
23  --condition='expression=destination.port == 22 && request.time < timestamp(""),title=iap-ssh-until-expiry'

：VM 所在的專案 ID，用 gcloud config get-value project 查目前設定的是哪一個。
、：要給權限的人的 Google 帳號；給一群人時把 user: 換成 group: 加 Google Group 的位址，CI 這類機器身分換成 serviceAccount: 加服務帳號的位址。
：VM 的內部 IP，gcloud compute instances list 的 INTERNAL_IP 欄查得到。
：綁定失效的時間，RFC 3339 格式，例如 2027-03-31T00:00:00Z。
title：這個條件的顯示名稱，自己取，會出現在 IAM 頁面上。

這次用第二個帳號實測：沒有這個角色時開通道回 4033；條件只放行 22 時連 3389 回 4033（Owner 帳號對照回 4003，代表 Owner 不受條件限制、而是被防火牆擋下）；限定單一 VM 與過期的條件連續三分鐘回 4033，正對照在 75 秒內放行。IAM 綁定從送出到生效約 60 到 120 秒，這段時間內的 4033 不代表條件寫錯。

Linux VM 的 gcloud compute ssh 另外要 VM 端的登入權限：還沒啟用 OS Login 時，gcloud compute ssh 把公鑰寫進專案或 VM 的 metadata（實測寫進專案 metadata），所以非 Owner 的帳號要有修改 metadata 的權限（例如 roles/compute.instanceAdmin.v1），VM 掛著服務帳號時另外要那個服務帳號的 roles/iam.serviceAccountUser；已經啟用 OS Login 時，改由〈啟用 OS Login：先授角色、單台先行、再做專案層級〉的登入角色決定。兩種情形都要讀取 VM 與專案資訊的權限（例如 roles/compute.viewer）。

沒做時：非 Owner 的管理員開通道回 4033。Owner 不需要這一步，所以團隊全員都是 Owner 時，這一步看起來不必做，而 IAM Conditions 對 Owner 不生效，條件寫了也限不住任何人（Owner 連 3389 回 4003 而不是 4033）。
替代做法：不加條件，換到的是指令短、不必維護條件，付出的是持有角色的人連得到專案裡每台 VM 的每個 port（只要防火牆放行）；綁給 domain: 或大型群組，換到的是不必逐人授權，付出的是整個組織的帳號都能開通道（兩者都從角色的作用推論，這次沒有實跑）。取捨的判斷見概念篇〈IAP 的 IAM 授權範圍：誰拿得到通道〉。

停用舊規則，用 IAP 驗證新規則

先在舊規則還在時，每一位管理員各自用自己的帳號連一次，確認 IAM 權限：

1# Linux：透過 IAP 通道 SSH 進 VM
2gcloud compute ssh  --zone= --tunnel-through-iap
3
4# Windows：把 VM 的 3389 port 經 IAP 轉到本機的 13389，再用 RDP 用戶端連 localhost:13389
5gcloud compute start-iap-tunnel  3389 --local-host-port=localhost:13389 --zone=

加上 --tunnel-through-iap 時，gcloud 改走 IAP、不連 VM 的外部 IP；VM 還有外部 IP 時，少了這個參數的連線走的是舊路徑。這一次連線驗證的是 IAM：IAP 端點會拒絕沒有權限的帳號。防火牆規則與 tag 這一次驗不到，因為舊規則的 0.0.0.0/0 也放行 IAP 的位址段。接著停用舊規則（規則仍在，只是不生效），由一位管理員對 Linux 與 Windows 各一台 VM 再連一次：

1gcloud compute firewall-rules update default-allow-ssh --disabled
2gcloud compute firewall-rules update default-allow-rdp --disabled
3gcloud compute ssh  --zone= --tunnel-through-iap

這一次連得上，代表放行連線的是新規則；前提是專案裡沒有其他來源涵蓋 35.235.240.0/20 的允許規則，用概念篇〈預設網路自帶的防火牆規則〉的列出規則指令確認。這次實測停用之後經由 IAP 連得上、不加 --tunnel-through-iap 的直連被拒，Windows 經 IAP 的 3389 回了 X.224 Connection Confirm。新規則建立時加了 --enable-logging，可以查防火牆紀錄確認命中的是哪一條規則：

1# 查最近一小時經由 IAP 規則放行的連線
2gcloud logging read \
3  'logName:"compute.googleapis.com%2Ffirewall" AND jsonPayload.rule_details.reference:"allow-ssh-from-iap"' \
4  --freshness=1h --limit=10

規則剛開啟 logging 的最初幾分鐘，紀錄裡的 rule_details 可能是空的（實測前兩筆沒有、約五分鐘後的三筆有），照本節的順序正好落在這段時間，所以上面這條查不到不代表新規則沒有命中。這時改用來源 IP 查，結果與 rule_details 是否已經填入無關；驗 RDP 的規則時把 22 換成 3389：

1gcloud logging read \
2  'logName:"compute.googleapis.com%2Ffirewall" AND ip_in_net(jsonPayload.connection.src_ip, "35.235.240.0/20") AND jsonPayload.connection.dest_port=22' \
3  --freshness=1h --limit=10 \
4  --format="value(timestamp,jsonPayload.connection.src_ip,jsonPayload.rule_details.reference)"

連不上時，用下面的指令把舊規則恢復，再照概念篇〈IAP 通道連不上時的依層判讀〉找出是哪一層；防火牆規則透過 GCP 的 API 修改，SSH 連不上也改得回來：

1gcloud compute firewall-rules update default-allow-ssh --no-disabled
2gcloud compute firewall-rules update default-allow-rdp --no-disabled

4003 時要用 Connectivity Tests 查是哪一條規則或政策擋下：gcloud network-management connectivity-tests create --source-ip-address=35.235.240.1 --destination-instance=projects//zones//instances/ --destination-port=22 --protocol=TCP，自己取，--source-ip-address 只收單一 IP，取 IAP 位址段裡的任一個。

主控台的 SSH 按鈕（SSH-in-browser）：官方〈Connect to Linux VMs using IAP〉寫明它只在 VM 沒有外部 IP 時才走 IAP。所以 VM 還帶外部 IP 時，停用舊規則之後，用主控台按鈕的人連不上，而 --tunnel-through-iap 驗起來是通的，這不代表新規則壞了；外部 IP 移除之後，主控台按鈕改走 IAP（照官方文件推出，這次沒有實跑）。盤點時把用主控台按鈕登入的人一起找出來，切換期間請他們改用 --tunnel-through-iap。
沒做時（只在舊規則還在時驗證）：連得上的那一次可能是舊規則放行的，tag 漏加或規則寫錯都測不出來，要到刪除舊規則之後才發現（照規則的作用推論，這次沒有實跑）。
替代做法：
- 不停用、只查防火牆紀錄裡命中的規則名稱，換到的是驗證期間外部來源照常連得到，付出的是要等 rule_details 填入，而且兩條規則都放行時紀錄記的是先被評估的那一條（推論，這次沒有在兩條並存時查）。
- 直接刪除舊規則再驗證，換到的是少一步，付出的是出錯時要重建規則，重建時可能寫錯；停用的規則用 --no-disabled 一行恢復原樣。

刪除對外開放的規則

刪除之前，列出還沒帶 tag 的 VM，兩份清單都要是空的（只有 Linux 或只有 Windows 時，查對應的那一份）：

1gcloud compute instances list --filter="NOT tags.items="
2gcloud compute instances list --filter="NOT tags.items="

清單裡出現的是另一種作業系統的 VM 時合理（Linux VM 本來就不帶 RDP 的 tag），其餘的要先補上 tag 再刪規則。專案裡還沒有任何 VM 帶 tag 時，gcloud 會先印一行 WARNING: The following filter keys were not present in any resource : tags.items，下面列出的 VM 清單仍然正確（實測）。

1gcloud compute firewall-rules delete default-allow-ssh default-allow-rdp

刪除之後才發現有漏掉的連線來源時，照原樣把規則建回來，再回頭處理（實測建得回來）：

1gcloud compute firewall-rules create default-allow-ssh --network=default \
2  --direction=INGRESS --action=allow --rules=tcp:22 --source-ranges=0.0.0.0/0 --priority=65534 --enable-logging
3gcloud compute firewall-rules create default-allow-rdp --network=default \
4  --direction=INGRESS --action=allow --rules=tcp:3389 --source-ranges=0.0.0.0/0 --priority=65534 --enable-logging

沒做時（停用之後不刪）：停用的規則不放行任何連線，效果與刪除相同；留著的代價是有人用 --no-disabled 一行就恢復全開（照規則的作用推論，這次沒有實跑）。Security Command Center 的 OPEN_SSH_PORT finding 是否把停用的規則算進去，這次沒有確認。
替代做法：用 gcloud compute firewall-rules update default-allow-ssh --source-ranges=<固定的管理網段> 把來源收窄、不刪除，換到的是保留一條直連的路，付出的是這條路的授權仍然是來源 IP，分辨不出人（取捨見伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口的〈網路可達性的做法：管理 port 對誰開放〉，這次沒有實跑）。

收斂 default-allow-internal 與 default-allow-icmp

default-allow-internal 要先確認 VM 之間實際需要哪些 port（應用連資料庫、節點之間的叢集通訊）再改成具體的規則。改法是為每一組需要的連線各建一條規則，例如應用連 PostgreSQL：

1gcloud compute firewall-rules create allow-app-to-db --network=default \
2  --direction=INGRESS --action=allow --rules=tcp:5432 \
3  --source-tags= --target-tags=

、是自己取的 tag，加在應用與資料庫 VM 上；tcp:5432 換成實際的服務 port。每一組需要的連線都建好之後，再刪 default-allow-internal。default-allow-icmp 的處理看用途：監控或除錯流程會用 ping 確認 VM 存活時，保留並把來源縮到內部網段與監控主機（gcloud compute firewall-rules update default-allow-icmp --source-ranges=10.128.0.0/9,/32，是發 ping 的監控主機的 IP）；沒有這種用途就一起刪除。這一節的指令這次沒有實跑。

沒做時：同一個網路裡的 VM 之間不受 port 限制，一台 VM 被入侵之後能直接連到其他 VM 的資料庫與管理 port；管理通道本身不受影響，所以這一步可以排進另一次變更（照規則的作用推論，這次沒有實跑）。
替代做法：直接刪除 default-allow-internal，換到的是一步收完，付出的是 VM 之間的服務連線當場中斷；整個網路改成自己規劃的 custom-mode VPC，換到的是預設規則一次清掉，付出的是 VM 要搬網路，見概念篇〈預設網路自帶的防火牆規則〉（兩者都是推論，這次沒有實跑）。

啟用 OS Login：先授角色、單台先行、再做專案層級

啟用 OS Login 之後，VM 不再接受 metadata 裡的金鑰（實測：metadata 金鑰被拒），順序為什麼是先授角色、單台先行，見 GCP VM 的 SSH 與 RDP 管理通道的〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉。先把登入角色授予每一位管理員與每一個要登入 VM 的服務帳號；VM 掛著服務帳號時，每一個登入者另外需要那個服務帳號的 roles/iam.serviceAccountUser：

 1# 授予管理員 OS Login 的登入角色：一般登入與含 sudo 的兩種擇一
 2gcloud projects add-iam-policy-binding  \
 3  --member=user: --role=roles/compute.osLogin
 4gcloud projects add-iam-policy-binding  \
 5  --member=user: --role=roles/compute.osAdminLogin
 6
 7# CI 或自動化工具的服務帳號同樣要授予（需要 sudo 時改用 osAdminLogin）
 8gcloud projects add-iam-policy-binding  \
 9  --member=serviceAccount: --role=roles/compute.osLogin
10
11# 查 VM 掛的服務帳號，並授予登入者使用它的權限
12gcloud compute instances describe  --zone= \
13  --format="get(serviceAccounts[0].email)"
14gcloud iam service-accounts add-iam-policy-binding  \
15  --member=user: --role=roles/iam.serviceAccountUser

是 CI 或自動化工具開通道用的服務帳號，是上一條 describe 查出來、VM 掛的那個服務帳號，兩者不同。這次用第二個帳號實測：缺 serviceAccountUser 時 Permission denied (publickey)，補上之後 20 秒內登入；osLogin 不能 sudo、osAdminLogin 可以。

接著先對一台 VM 啟用，讓每一位非 Owner 的管理員各自用自己的帳號連通並確認 sudo 可用，CI 也對這台跑一次部署，再做專案層級：

1# 先對單一 VM 啟用，連通確認
2gcloud compute instances add-metadata  --zone= --metadata enable-oslogin=TRUE
3
4# 確認之後在專案層級啟用（VM 層級的設定會蓋過專案層級）
5gcloud compute project-info add-metadata --metadata enable-oslogin=TRUE
6
7# 連不上時還原（修改 metadata 走 API，不需要登入 VM）
8gcloud compute instances add-metadata  --zone= --metadata enable-oslogin=FALSE
9gcloud compute project-info add-metadata --metadata enable-oslogin=FALSE

專案層級啟用之後再盤點兩件事。VM 層級設了 enable-oslogin=FALSE 的 VM 會蓋過專案設定、仍然讀 metadata 金鑰（實測），用下面這條列出它們的名稱，逐台改成 TRUE 或移除這個鍵：

1gcloud compute instances list --format=json \
2  | jq -r '.[] | select(any(.metadata.items[]?; .key=="enable-oslogin" and (.value|ascii_downcase)=="false")) | .name'

專案 metadata 的 ssh-keys 仍然留著前任與現任成員的公鑰，OS Login 一旦還原成 FALSE 它們就又能用，確認全部 VM 都啟用之後用 gcloud compute project-info remove-metadata --keys=ssh-keys 清掉（實測）。

沒做時（不啟用 OS Login）：登入驗證仍是 metadata 裡的公鑰，寫在專案 metadata 的公鑰對專案裡每台 VM 都生效，成員離職時漏刪一把，那把金鑰就持續能登入整個專案（OS Login 文件，這次沒有實跑）。
替代做法：
- 直接在專案層級啟用、不經過單台，換到的是少一輪驗證，付出的是角色漏授時鎖住的是整個專案的每一台 VM；只由 Owner 驗證，看不出漏授，因為 Owner 持有全部權限（推論，這次沒有實跑）。
- 改用 SSH 憑證（OpenSSH CA），換到的是主機不全在 GCP 時也能用同一套，付出的是要維運 CA，見 OpenSSH 內建 CA 的 SSH 憑證導入。
- 再加 enable-oslogin-2fa=TRUE 要求每次登入多一次第二因素，同樣先對單一 VM 設定驗證，連不上時改回 FALSE。付出的是每一位登入者的 Google 帳號都要先啟用兩步驟驗證，沒有啟用的會登不進去；而 OS Login 文件寫明兩步驟驗證不套用在服務帳號上，CI 這類登入者不受它約束（OS Login 文件，這次沒有實跑）。換到的是帳號密碼或本機的 refresh token 外洩時，登入還要第二因素（推論，這次沒有實跑）。

建 Cloud NAT 並移除外部 IP

Cloud NAT 承接沒有外部 IP 的 VM 往外的連線，建在 Cloud Router 上，以 region 為單位生效。哪些出站連線改由 Cloud NAT 承接、哪些改走 Private Google Access，以及出站的驗證為什麼要在移除外部 IP 之後做，見概念篇〈拿掉外部 IP 之後的出站路徑：Cloud NAT 與 Private Google Access〉。

 1# 在 VM 所在的 region 建 Cloud Router，再在上面建 Cloud NAT（出站 IP 自動配發）
 2gcloud compute routers create  \
 3  --network= --region=
 4gcloud compute routers nats create  \
 5  --router= --region= \
 6  --auto-allocate-nat-external-ips \
 7  --nat-all-subnet-ip-ranges
 8
 9# 外部服務要求來源 IP 白名單時：先預留靜態 IP，NAT 改用它出站
10gcloud compute addresses create  --region=
11gcloud compute routers nats create  \
12  --router= --region= \
13  --nat-external-ip-pool= \
14  --nat-all-subnet-ip-ranges

、、：自己取的資源名稱。
：VM 所在 zone 去掉最後的字母那一段，例如 zone asia-east1-b 對應 region asia-east1；VM 分布在幾個 region 就要各建一組。
--auto-allocate-nat-external-ips 讓 GCP 自動配發出站用的外部 IP，這些 IP 可能變動；--nat-external-ip-pool 改用預留的靜態 IP。
--nat-all-subnet-ip-ranges 讓這個 region 裡所有 subnet 都走這個 NAT，只想讓部分 subnet 出站時改用 --nat-custom-subnet-ip-ranges 逐一列出。

VM 要存取 Cloud Storage、Artifact Registry 這類 Google API 時，subnet 開啟 Private Google Access，就能用內部 IP 連到 Google API，不經過 Cloud NAT：

1gcloud compute networks subnets update  \
2  --region= --enable-private-ip-google-access

用 gcloud compute networks subnets list --filter="region:" 查；default 網路在每個 region 各有一個名為 default 的 subnet。

外部 IP 設定在 VM 網卡的 access config 上，delete-access-config 要靠名稱指定移除哪一個，而這個名稱依 VM 建立的方式不同，所以先查出來。對外提供服務的 VM 移除之前，要先把流量入口換到負載平衡器；只做管理用途的 VM 可以直接移除。先在一台 VM 上移除、確認，再做其餘的 VM：

1# 查 VM 第一張網卡的 access config 名稱
2gcloud compute instances describe  --zone= \
3  --format="get(networkInterfaces[0].accessConfigs[0].name)"
4
5# 用查到的名稱移除外部 IP
6gcloud compute instances delete-access-config  --zone= \
7  --access-config-name=""

移除之後經由 IAP 連進這台 VM，執行 curl -s https://ifconfig.me 印出出站時對方看到的來源 IP；那個 IP 列在 gcloud compute routers get-nat-ip-info --region= 的清單裡，就代表出站走了 Cloud NAT。這次實測 --auto-allocate-nat-external-ips 配到的 IP 正好是這台 VM 剛釋放的外部 IP，移除前後 curl 印出同一個 IP，gcloud compute addresses list 的 PURPOSE 欄是 NAT_AUTO，所以判斷依據是那份清單，而不是移除前後的 IP 有沒有變。連不到網際網路時，用 gcloud compute instances add-access-config --zone= 把外部 IP 加回去，再回頭查 Cloud NAT 的 region 與 subnet 設定。

沒做時（保留外部 IP）：管理通道已經只放行 IAP，SSH 照樣安全；外部 IP 仍讓 VM 的其他 port 只靠防火牆擋，而防火牆規則一寫寬，那台 VM 就直接暴露（照規則的作用推論，這次沒有實跑）。Security Command Center 有標出帶公開 IP 的資源的 finding 類別，VM 不需要對外時移除之後少一類要處理的 finding（Security Health Analytics 文件）。
替代做法：
- 反過來先移除 IP、再建 NAT，換到的是驗證不受外部 IP 干擾，付出的是移除到 NAT 建好之間 VM 連不到網際網路，apt update 這類操作會失敗（推論，這次沒有實跑）。
- 不建 Cloud NAT、只開 Private Google Access，換到的是不經過 NAT、不產生 NAT 的閘道時數與資料處理費，付出的是 VM 只連得到 Google API，連不到外部的套件來源與第三方 API（Cloud NAT 定價與 Private Google Access 文件，這次沒有實跑）。
- 用 --nat-external-ip-pool 改用預留的靜態 IP，換到的是外部服務可以把這個固定的 IP 列進白名單；Cloud NAT 定價頁寫明 NAT 使用的外部 IP 不論靜態或自動配發都按 IP 計費，差別在靜態 IP 從 NAT 拿下來之後仍然保留在專案裡、要另外釋放（Cloud NAT 定價與 IP 位址文件，這次沒有實跑）。

移除之後，這台 VM 只剩 IAP 一條管理路徑，連線一律加 --tunnel-through-iap；救援入口是〈準備救援入口：Serial Console 與本機救援帳號〉建好的那一條。

源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS

Sun, 25 Oct 2026 00:00:00 +0800

事件說明：2026-10-25，在 Oracle Cloud ap-batam-1 區域的一台 A1 主機（Arm 架構，Oracle Linux 10.2，核心 6.12.0-207.111.5.1.el10uek.aarch64，1 OCPU、6 GB）上實測。主機在私有 subnet、沒有公開 IP，管理員經由 Oracle Cloud Bastion 的 port forwarding session 登入（建法見 Oracle Cloud 建立主機的實測紀錄）。firewalld 2.4.3、nftables 後端、預設 zone public，public zone 只開 ssh 與 dhcpv6-client；Docker 用官方的靜態二進位檔 29.9.2（iptables 後端），測試容器是 busybox:1.37。2026-10-26 另在本機 OrbStack 2.2.5 建的一台 Oracle Linux 10.2 機器上（核心是 OrbStack 的 7.2.12-orbstack，firewalld 2.4.3 nftables 後端、Docker CE 29.9.2 以套件安裝、由 systemd 執行）測了 zone 的 sources、IPv6、daemon 的 ip 設定、policy 上的 forward-port、本機 forward-port，以及 reload 清掉 DOCKER-USER 的條件。OrbStack 的核心是它自己編的版本，量到的是 firewalld、iptables-nft、nftables 與 Docker 這幾個使用者層程式的行為，跟 Oracle Linux 映像核心的差異沒有比較。

這篇記錄在一台 Linux 主機上驗證「源站只放行 Cloudflare 的位址」這類防火牆規則的過程：用兩個 network namespace 模擬位址在 Cloudflare 範圍內與範圍外的兩個來源、firewalld 以 ipset 與 rich rule 只放行 Cloudflare 位址到主機本身的程式、Docker 發佈的連接埠不受這條規則約束、DOCKER-USER 鏈的規則在 dockerd 重啟之後還在、在 firewall-cmd --reload 之後是否消失取決於 firewalld 的後端與主機有沒有 direct 設定（iptables 後端時一律清掉；nftables 後端時看有沒有 direct rule 或 passthrough，OCI 的 Oracle Linux 映像自帶 passthrough）、firewalld policy 擋不到發佈的連接埠與它的原因、StrictForwardPorts=yes 只管得到連接埠、掛在目的位址轉換之前的 nftables 表與它的開機載入、出站 DNS 只准送往 VCN 解析器的 policy 對主機與容器的不同效果、清理，以及各寫法在 reload、dockerd 重啟與重開機之後的對照表。每一種限制寫法的機制與取捨寫在概念文章 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖，這裡不重寫。這篇沒有用到 Cloudflare 帳號，也沒有讓 Cloudflare 實際回源：防火牆比對的只有來源位址，所以用 Cloudflare 位址段裡的一個位址當來源，就能驗證規則。Cloudflare 回源時實際用的位址、Authenticated Origin Pulls、Worker 與 Tunnel，接上實際的 Cloudflare 帳號量在 Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠。

前置條件：主機、登入方式與測試檔案

一台跑 firewalld 的 Linux 主機，有 sudo：指令以 Oracle Linux 10 與 firewalld 的 nftables 後端寫成。firewall-cmd --state 回 running、sudo grep FirewallBackend /etc/firewalld/firewalld.conf 回 nftables 才跟這次相同。主機上要有 curl、dig（套件 bind-utils）、python3、iptables（套件 iptables-nft）與 nft，command -v curl dig python3 iptables nft 印得出五個路徑就齊了；這台的平台映像都已經裝好。用 ufw 的主機（Ubuntu）上，Docker 發佈的連接埠同樣繞過 ufw，規則在 ufw reload 與重開機之後的存續、寫進 /etc/ufw/after.rules 的做法，記在 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑。
登入路徑跟要測的連接埠分開：這次經由 Bastion 連 SSH 的連接埠 22，測試只改動 8080 到 8083，public zone 的 ssh 沒有動，規則寫錯也不會把自己鎖在外面。主機有公開 IP、從網際網路直接 SSH 時，同樣只動測試用的連接埠。
Docker 與測試映像：這台主機在私有 subnet，只有連到 Oracle 服務的 service gateway，連不到 download.docker.com 與 Docker Hub。所以在本機下載靜態二進位檔、匯出映像與 Cloudflare 的位址清單，再傳上主機：
```
1curl -sSfLO https://download.docker.com/linux/static/stable/aarch64/docker-29.9.2.tgz
2docker pull --platform linux/arm64 busybox:1.37 && docker save busybox:1.37 -o busybox-1.37.tar
3curl -s https://www.cloudflare.com/ips-v4 > cf-ips-v4.txt
4ssh -F  <主機的 Host 名稱> 'mkdir -p /tmp/verify-fw'
5scp -F  docker-29.9.2.tgz busybox-1.37.tar cf-ips-v4.txt <主機的 Host 名稱>:/tmp/verify-fw/
```
aarch64 對應 A1 這種 Arm 主機，x86 主機換成 x86_64，--platform 換成 linux/amd64；29.9.2 是 2026-10-25 時 stable/aarch64/ 目錄裡最新的版本，照抄之前先打開那個目錄看一次。是寫了 ProxyJump 經由 Bastion 的 ssh 設定（寫法在上面那篇 Oracle Cloud 實測紀錄的〈建 port forwarding session 並經由本機的轉送登入〉），<主機的 Host 名稱> 是那份設定裡主機的 Host。約 82 MB 的檔案經由 Bastion 傳了約 5 分鐘（本機計時，依本機的上行頻寬與 Bastion 而變）。cf-ips-v4.txt 在 2026-10-25 是 15 段 IPv4，最後一行沒有換行（wc -l 回 14）；清單會變，每次照著做時重抓。
主機連得到網際網路時改用套件安裝：加 Docker 的 RHEL 套件庫再 dnf install docker-ce。Docker 寫防火牆規則的行為由 dockerd 決定，跟安裝方式無關；差別在套件版附 systemd 的 unit，裝好就由 systemd 執行 dockerd，下文 start_dockerd 與 restart_dockerd 裡的 nohup dockerd 與 pkill -x dockerd 要換成 systemctl start docker 與 systemctl restart docker（unit 帶 socket 啟用與自動重啟，pkill 之後 dockerd 會被拉起來），重開機之後 dockerd 也會自動啟動。這一段依套件的安裝方式推論，沒有實跑。
暫存目錄用 verify- 開頭：測完一條 find /tmp /var/tmp -maxdepth 1 -name 'verify-*' 就查得出有沒有漏清的檔案。這台的 /tmp 在重開機之後還在；/tmp 是 tmpfs 的主機（Fedora、Debian 13 這類）重開機會清空它，那時把下文的 D 改成 /var/tmp/verify-fw，傳檔的目的地也跟著改。

共用的變數與函式

下文每一個指令區塊都在主機上同一個 root shell 裡依序執行（sudo -i 之後一路跑到清理），變數與函式只存在那個 shell 裡；中途換了 shell 或重開機之後，重新貼一次這個區塊。HOSTIP 填主機自己的 IP：ip -br a 主要網卡那一行的位址，取斜線之前的部分（10.0.1.35/24 填 10.0.1.35）。RESOLVER 填主機用的 DNS 解析器（/etc/resolv.conf 的 nameserver），Oracle Cloud VCN 裡是 169.254.169.254，只在出站 DNS 那一節用到。

 1HOSTIP=<主機的 IP>
 2RESOLVER=<主機的 DNS 解析器>
 3D=/tmp/verify-fw
 4export PATH=$D/docker:$PATH
 5cd $D
 6ns_setup() {
 7  ip netns add verify-cf; ip netns add verify-other
 8  ip link add vcf-h type veth peer name vcf-n netns verify-cf
 9  ip link add voth-h type veth peer name voth-n netns verify-other
10  ip addr add 192.0.2.1/32 dev vcf-h; ip link set vcf-h up            # 主機這一端的位址，只當 namespace 的閘道
11  ip addr add 192.0.2.5/32 dev voth-h; ip link set voth-h up
12  ip route add 173.245.48.10/32 dev vcf-h                              # 回給 verify-cf 的封包從 vcf-h 送出
13  ip route add 203.0.113.10/32 dev voth-h
14  ip -n verify-cf addr add 173.245.48.10/32 dev vcf-n; ip -n verify-cf link set vcf-n up; ip -n verify-cf link set lo up
15  ip -n verify-cf route add 192.0.2.1/32 dev vcf-n; ip -n verify-cf route add default via 192.0.2.1 dev vcf-n
16  ip -n verify-other addr add 203.0.113.10/32 dev voth-n; ip -n verify-other link set voth-n up; ip -n verify-other link set lo up
17  ip -n verify-other route add 192.0.2.5/32 dev voth-n; ip -n verify-other route add default via 192.0.2.5 dev voth-n
18}
19probe() {  # probe <連接埠>：兩個來源各連一次 http://$HOSTIP:<連接埠>/，-m 5 是 5 秒逾時
20  for ns in verify-cf verify-other; do
21    out=$(ip netns exec $ns curl -sS -m 5 -o /dev/null -w '%{http_code}' http://$HOSTIP:$1/ 2>&1); rc=$?
22    printf '  %-13s -> :%s  rc=%s  %s\n' "$ns" "$1" "$rc" "$out"
23  done
24}
25start_dockerd() {  # 背景啟動 dockerd，等到 docker info 回得了（最多 30 秒）
26  nohup dockerd >>$D/dockerd.log 2>&1 &
27  for i in $(seq 30); do docker info >/dev/null 2>&1 && break; sleep 1; done
28}
29restart_dockerd() {  # 停掉 dockerd、等它結束、再啟動，並把測試容器啟動回來
30  pkill -x dockerd; while pgrep -x dockerd >/dev/null; do sleep 1; done
31  start_dockerd
32  docker start verify-web-all verify-web-lo verify-web-v >/dev/null 2>&1; sleep 2
33}

docker start 的三個容器在〈Docker 發佈的連接埠與 firewalld 的規則〉那一節建立，在那之前呼叫 restart_dockerd 時這一行什麼都不做。

用 network namespace 模擬 Cloudflare 與其他來源

要測「只放行 Cloudflare 的位址」，需要兩個來源：一個的位址在 Cloudflare 的範圍裡，一個不在。ns_setup 在主機上建兩個 network namespace（核心裡各自獨立的一套網路介面與路由表），各用一對 veth（成對的虛擬網路介面，從一端送進去的封包從另一端出來）接到主機：verify-cf 的位址是 173.245.48.10（落在 Cloudflare 的 173.245.48.0/20），verify-other 的位址是 203.0.113.10（RFC 5737 保留給文件用的 TEST-NET-3，不在任何 Cloudflare 範圍）。兩者都對主機的 IP 發連線，封包從主機的 vcf-h、voth-h 介面進來，經過的防火牆路徑跟從網卡進來的封包相同。

1ns_setup
2firewall-cmd --get-zone-of-interface=vcf-h; firewall-cmd --get-default-zone

ns_setup 只跑一次；namespace 已經存在時再跑會印一串 File exists。--get-zone-of-interface=vcf-h 回 no zone、--get-default-zone 回 public：veth 介面沒有被指派到任何 zone，firewalld 把它們的流量交給預設 zone 處理，跟主機的網卡同一個 zone。

下文輸出裡的 10.0.1.35 是這次那台主機的私有 IP，每段輸出前的 == 行是實測時腳本印的說明。probe 的輸出有三種讀法：rc=0 200 是連上並拿到回應；rc=7、after 0 ms: Could not connect to server 是主機立即回拒（firewalld 以 ICMP 回拒，或沒有程式在聽）；rc=28、Connection timed out after 5002 milliseconds 是封包被丟棄、沒有任何回應。連線失敗時 curl 另外印一行 000（-w 印的狀態碼），下文的輸出把那一行省略了。

這一步可以換成實體的兩個來源（另一台主機，或實際讓 Cloudflare 回源），結果相同，因為防火牆只看封包的來源位址（依規則的比對方式推論）；代價是要多一台主機或一個 Cloudflare 帳號，而且一般主機的位址不會落在 Cloudflare 的範圍裡，Cloudflare 位址被放行的情形測不到。

firewalld 以 ipset 只放行 Cloudflare 位址到主機本身的程式

主機上聽 8080 的程式代表直接跑在主機上的網站程式。還沒加任何規則時，兩個來源都被 public zone 回拒：

1nohup python3 -m http.server 8080 --directory $D >$D/http8080.log 2>&1 &
2sleep 1; probe 8080

1== 沒有任何放行 8080 的規則
2  verify-cf     -> :8080  rc=7  curl: (7) Failed to connect to 10.0.1.35 port 8080 after 0 ms: Could not connect to server
3  verify-other  -> :8080  rc=7  curl: (7) Failed to connect to 10.0.1.35 port 8080 after 0 ms: Could not connect to server

把 Cloudflare 的位址段放進一個 ipset，再加一條 rich rule（firewalld 可以同時寫來源、連接埠與動作的規則）放行這個 ipset 到 8080：

1firewall-cmd --permanent --new-ipset=cloudflare-v4 --type=hash:net     # hash:net 存的是位址段
2firewall-cmd --permanent --ipset=cloudflare-v4 --add-entries-from-file=$D/cf-ips-v4.txt
3firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" port port="8080" protocol="tcp" accept'
4firewall-cmd --reload
5firewall-cmd --ipset=cloudflare-v4 --get-entries | wc -l
6probe 8080

115
2== 放行 ipset cloudflare-v4 到 8080
3  verify-cf     -> :8080  rc=0  200
4  verify-other  -> :8080  rc=7  curl: (7) Failed to connect to 10.0.1.35 port 8080 after 0 ms: Could not connect to server

ipset 裡是 15 段，跟下載的清單相同。正式設定時把 8080 換成 80 與 443（或 service="http"、service="https"）。這一步的選項與替代做法：

--permanent 加 --reload，或不帶 --permanent：帶 --permanent 的規則寫進設定檔；不帶時只改執行中的規則，下一次 --reload 就消失。這次用 --permanent，dockerd 啟動之後與 reload 之後 8080 的結果都跟上面相同（實測）；重開機之後依 --permanent 的機制會在，重開機後沒有再連 8080。
ipset，或每一段各寫一條 rich rule：每段一條也行得通，15 段就是 15 條規則，清單更新時要逐條比對；ipset 更新時只換集合的內容，rich rule 不動。依 firewalld 的規則寫法推論，沒有實跑。
把 ipset 加到一個 zone 的 sources：來源落在 ipset 的連線改由那個 zone 處理，放行的範圍是那個 zone 開的全部服務與連接埠。OrbStack 那一台上建了一個只開 8080 的 zone，sources 放 ipset:cloudflare-v4（實測時這個 zone 叫 verify-cf，跟 namespace 同名，這裡改名避免混淆；firewall-cmd --permanent --new-zone=verify-cfzone、--zone=verify-cfzone --add-source=ipset:cloudflare-v4、--zone=verify-cfzone --add-port=8080/tcp）：verify-cf 連 8080 拿到 200、verify-other 被回拒，跟 rich rule 的結果相同；差別在 verify-cf 連 22 時回 No route to host（被 verify-cfzone 回拒，它沒有開 ssh），verify-other 連 22 仍由 public zone 處理。zone sources 接管的是那些位址的全部入站連線，來源落在清單裡的連線只看這個 zone 開了什麼，public zone 的設定對它們不再生效。用 trusted zone 時則相反，那些位址連任何連接埠都放行。Docker 發佈的 8081 照樣兩個來源都連得到，zone 管不到轉送路徑。測完以 firewall-cmd --permanent --delete-zone=verify-cfzone 加 firewall-cmd --reload 刪掉這個 zone。
IPv6：OCI 這台主機沒有全域的 IPv6 位址，在 OrbStack 那一台上用一個 ULA（unique local address，fd00::/8 裡只在本地使用的 IPv6 位址）fd00:beef::1 當主機的 IPv6 位址（兩個來源加 IPv6 位址的指令見 ufw 那一篇〈共用的函式與兩個測試來源〉的 ns_setup6）、兩個 namespace 各加一個 IPv6 位址（verify-cf 用 Cloudflare 的 2606:4700::10，verify-other 用文件保留的 2001:db8::10）測。--option=family=inet6 建的 ipset 放進 ips-v6 的 7 段，rich rule 寫 family="ipv6"：verify-cf 經由 IPv6 連 8080 拿到 200、verify-other 被回拒，跟 IPv4 相同。同一組 IPv6 位址也拿來量 Docker 發佈的 8081，結果寫在〈Docker 發佈的連接埠與 firewalld 的規則〉裡 IPv6 那一份發佈的那一段。測完以 --remove-rich-rule 刪掉這一段與那一段加的兩條 IPv6 rich rule（8080 與 8081）再 reload；namespace 裡的 IPv6 位址隨清理段刪 namespace 一起消失，lo 上的 ULA 與 cloudflare-v6 ipset 寫在清理段。

Docker 發佈的連接埠與 firewalld 的規則

解開靜態檔、在背景啟動 dockerd，看它對 firewalld 與 iptables 做了什麼：

1sysctl net.ipv4.ip_forward
2tar xzf $D/docker-29.9.2.tgz -C $D
3start_dockerd
4docker info --format 'firewall backend: {{.FirewallBackend}}'
5sysctl net.ipv4.ip_forward
6firewall-cmd --zone=docker --list-all; firewall-cmd --info-policy=docker-forwarding
7iptables -S FORWARD

 1net.ipv4.ip_forward = 0
 2firewall backend: {iptables+firewalld [...]}
 3net.ipv4.ip_forward = 1
 4docker (active)
 5  target: ACCEPT
 6  interfaces: docker0
 7docker-forwarding (active)
 8  priority: -1
 9  target: ACCEPT
10  ingress-zones: ANY
11  egress-zones: docker
12-P FORWARD DROP
13-A FORWARD -j DOCKER-USER
14-A FORWARD -j DOCKER-FORWARD

（zone 與 policy 只留相關的欄位。）dockerd 把 ip_forward 從 0 改成 1，在 firewalld 裡建了 docker zone 與 docker-forwarding policy；iptables 的 FORWARD 鏈在 dockerd 啟動之後預設政策是 DROP（同一台主機在沒有 dockerd 時是 ACCEPT），開頭跳到 DOCKER-USER 與 DOCKER-FORWARD。接著跑三個容器：一個發佈在全部介面、一個只發佈在本機位址、一個帶存取記錄的當作後面的對照組：

 1docker load -i $D/busybox-1.37.tar
 2mkdir -p $D/www && echo hello > $D/www/index.html
 3# busybox 的 httpd：-f 在前景執行、-p 聽的連接埠、-h 網頁根目錄；-v 印出每一筆存取
 4docker run -d --name verify-web-all -v $D/www:/www:ro -p 8081:80 busybox:1.37 httpd -f -p 80 -h /www
 5docker run -d --name verify-web-lo  -v $D/www:/www:ro -p 127.0.0.1:8082:80 busybox:1.37 httpd -f -p 80 -h /www
 6docker run -d --name verify-web-v   -v $D/www:/www:ro -p 8083:80 busybox:1.37 httpd -f -v -p 80 -h /www
 7sleep 2
 8firewall-cmd --zone=public --list-ports; firewall-cmd --zone=public --list-rich-rules
 9probe 8081; probe 8082
10curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8082/

同一行裡 docker run 的 -v $D/www:/www:ro 是把主機的目錄唯讀掛進容器，httpd -f -v 的 -v 是 busybox httpd 自己的記錄選項，兩者不同。

1（--list-ports 沒有輸出）
2rule family="ipv4" source ipset="cloudflare-v4" port port="8080" protocol="tcp" accept
3== -p 8081:80（沒有指定位址）
4  verify-cf     -> :8081  rc=0  200
5  verify-other  -> :8081  rc=0  200
6== -p 127.0.0.1:8082:80
7  verify-cf     -> :8082  rc=7  ... Could not connect to server
8  verify-other  -> :8082  rc=7  ... Could not connect to server
9200

firewalld 沒有任何一條規則提到 8081，public zone 對未列出的連線一律回拒，而兩個來源都拿到容器的回應。看改寫目的地的那條規則與容器記到的來源：

1iptables -t nat -S DOCKER | grep 8081
2probe 8083 >/dev/null; docker logs verify-web-v 2>&1 | tail -2

1-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8081 -j DNAT --to-destination 172.17.0.2:80
2[::ffff:173.245.48.10]:34162: response:200
3[::ffff:203.0.113.10]:33384: response:200

DNAT（目的位址轉換）那一條就是在主機防火牆之前改寫目的地的規則。容器的記錄裡兩個來源的位址原樣出現：容器看得到真正的來源，所以來源限制做得到，只是要寫在別的位置。只發佈在 127.0.0.1 的 8082 從兩個外部來源都連不到、主機本機連得到；這是 Docker 29.9.2 的結果，Docker〈Port publishing〉寫明 28.0.0 以前同一個 L2 網段的其他主機連得到發佈在 127.0.0.1 的連接埠。對外改由主機上的反向代理接時，反向代理受〈firewalld 以 ipset 只放行 Cloudflare 位址到主機本身的程式〉那種 rich rule 約束。

預設的發佈位址可以在 Docker 的設定裡改，OrbStack 那一台實跑了兩種。/etc/docker/daemon.json 寫 { "ip": "127.0.0.1" } 並重啟 Docker 之後，預設 bridge 網路上 -p 8085:80 的容器發佈在 127.0.0.1:8085，兩個外部來源都連不到；同時間另一個接在自訂網路（docker network create verify-custom）上、-p 8086:80 的容器仍發佈在 0.0.0.0:8086 與 [::]:8086，兩個外部來源都連得到：ip 選項只作用在預設的 bridge 網路。自訂網路建立時帶 -o com.docker.network.bridge.host_binding_ipv4=127.0.0.1（這次建的網路叫 verify-hb），那個網路上 -p 8087:80 的容器就發佈在 127.0.0.1:8087。docker ps 的 PORTS 欄看得到每個容器實際發佈在哪個位址。compose 的自訂網路在 networks: 底下的 driver_opts 寫同一個選項，沒有實跑。測完要還原，否則之後各節重建的容器都會發佈在 127.0.0.1、結果跟文章不同：刪掉這三個容器、docker network rm verify-custom verify-hb、rm /etc/docker/daemon.json、systemctl restart docker。

IPv6 那一份發佈走另一條路。OrbStack 那一台用〈firewalld 以 ipset 只放行 Cloudflare 位址到主機本身的程式〉的 IPv6 那一項建的位址量：Docker 的 -p 8081:80 同時發佈在 IPv6，而容器的網路沒有開 IPv6 時，[::]:8081 由 docker-proxy 這個主機上的程式（Userland Proxy 的一種）接聽。沒有任何規則時兩個來源經由 IPv6 連 8081 都被 public zone 回拒，加一條 rule family="ipv6" source ipset="cloudflare-v6" port port="8081" protocol="tcp" accept 之後只有 verify-cf 連得到。IPv6 那一份走 input 路徑、受 zone 管，跟 IPv4 那一份相反；同一條 rich rule 加上之後，IPv4 的 8081 仍然兩個來源都連得到。容器的網路帶 --ipv6 時，Docker 改用 ip6tables 的位址轉換處理 IPv6，那一種沒有測。

DOCKER-USER 鏈的限制效果與規則的存續

在 DOCKER-USER 寫一條跳到自建鏈 CF-ONLY 的規則，CF-ONLY 對 Cloudflare 的每一段回到原本的流程（RETURN），其餘丟棄。這一組指令在這一節會跑兩次，所以寫成函式：

1add_cf_only() {
2  iptables -N CF-ONLY
3  while read -r net; do [ -n "$net" ] && iptables -A CF-ONLY -s "$net" -j RETURN; done < <(cat $D/cf-ips-v4.txt; echo)
4  iptables -A CF-ONLY -j DROP
5  iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL -j CF-ONLY
6}
7add_cf_only
8probe 8081; probe 8083

正式設定把 8081 換成 80 與 443 時，跳轉那一條要加 -m conntrack --ctstate DNAT，只比對送往發佈連接埠、經過位址轉換的連線；少了它，容器自己往外連 443、容器之間連 80 的封包也會進 CF-ONLY 被丟掉（ufw 那一篇在 Ubuntu 上補測過：ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑的〈DOCKER-USER 規則的效果，以及它在 ufw reload、Docker 重啟與重開機之後的存續〉）。

< <(cat …; echo) 補一個換行，因為 Cloudflare 的清單最後一行沒有換行，read 會漏讀最後一段。每一段各寫一條 -s 而不用 iptables 的 -m set --match-set cloudflare-v4：firewalld 的 nftables 後端把 ipset 建成 nftables 的集合，不是 iptables 的 set 模組讀的那種核心 ipset，推論 -m set 引用不到它，沒有實跑。--ctorigdstport 8081 比對連線追蹤記下的原始目的連接埠：封包到 DOCKER-USER 時目的地已經改成容器的 80，寫 --dport 8081 比對不到。--ctdir ORIGINAL 讓規則只看發起方向的封包，容器回覆的封包不進 CF-ONLY。-I 把規則插在 DOCKER-USER 最前面；最後那一條用 DROP，範圍外的來源等到逾時，換成 REJECT 會變成立即失敗，沒有比較。

1== DOCKER-USER 只放行 Cloudflare 到原始目的連接埠 8081
2  verify-cf     -> :8081  rc=0  200
3  verify-other  -> :8081  rc=28  curl: (28) Connection timed out after 5002 milliseconds
4== 對照：沒有套規則的 8083
5  verify-cf     -> :8083  rc=0  200
6  verify-other  -> :8083  rc=0  200

規則擋得住。接著分開看 firewalld 重新載入與 dockerd 重啟。先重新載入 firewalld：

1firewall-cmd --reload; sleep 2
2iptables -S DOCKER-USER; iptables -S CF-ONLY; probe 8081

1== firewall-cmd --reload 之後
2-N DOCKER-USER
3iptables: No chain/target/match by that name.
4  verify-cf     -> :8081  rc=0  200
5  verify-other  -> :8081  rc=0  200

firewall-cmd --reload 之後，DOCKER-USER 只剩空的鏈，CF-ONLY 整條不見了，範圍外的來源又連得到。分出是誰清掉的：先停掉 dockerd，建一條測試鏈再 reload，再在 dockerd 執行中做一次：

1pkill -x dockerd; while pgrep -x dockerd >/dev/null; do sleep 1; done
2iptables -N VERIFY-T; iptables -A VERIFY-T -j RETURN; iptables -I DOCKER-USER -j VERIFY-T
3iptables -S | grep -c VERIFY-T
4firewall-cmd --reload; sleep 2; iptables -S | grep -c VERIFY-T
5restart_dockerd
6iptables -N VERIFY-T; iptables -A VERIFY-T -j RETURN; iptables -I DOCKER-USER -j VERIFY-T
7iptables -S | grep -c VERIFY-T
8firewall-cmd --reload; sleep 3; iptables -S | grep -c VERIFY-T
9grep -i firewalld $D/dockerd.log | tail -3

兩次都是 reload 之前 3、reload 之後 0：清掉 iptables 裡自建規則的是 firewalld 的重新載入，跟 dockerd 有沒有在跑無關；dockerd 的記錄裡只有它在 reload 之後重建自己 zone 與 policy 的訊息（Firewalld: docker zone already exists, returning 這類）。這台主機的 /etc/firewalld/firewalld.conf 是 FlushAllOnReload=yes；〈firewalld.conf〉寫明這是預設值，作用是 reload 時清掉全部執行中的規則。

OrbStack 那一台的 firewalld 沒有任何 direct 設定（firewall-cmd --direct --get-all-rules 與 --get-all-passthroughs 都沒有輸出），DOCKER-USER 裡的同一條規則在 FlushAllOnReload=yes 與 no 下 reload 之後都還在、照樣擋得住。在那一台加一條 direct rule 之後：

1firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 169.254.0.0/16 -p tcp -j ACCEPT
2firewall-cmd --reload
3iptables -N VERIFY-T; iptables -I DOCKER-USER -j VERIFY-T
4iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP
5firewall-cmd --reload; sleep 3
6iptables -S DOCKER-USER; iptables -S VERIFY-T

1-N DOCKER-USER
2iptables: No chain/target/match by that name.

reload 之後 DOCKER-USER 只剩空鏈、自建鏈 VERIFY-T 整條不見，範圍外的來源又連得到；FlushAllOnReload 改成 no 再做一次，結果相同。那條 direct rule 只是用來觸發 firewalld 管理 iptables，內容不重要。測完 firewall-cmd --permanent --direct --remove-rule … 移除它，/etc/firewalld/direct.xml 會留下一個只有空元素的檔，刪掉再 reload。

direct 設定的另一種是 passthrough（直接交給 iptables 的一行規則）。同一台改加一條 passthrough、不加 direct rule：

1firewall-cmd --permanent --direct --add-passthrough ipv4 -A OUTPUT -d 169.254.0.2/32 -p tcp --dport 3260 -j ACCEPT
2firewall-cmd --reload; sleep 3
3iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP
4firewall-cmd --reload; sleep 3
5iptables -S DOCKER-USER

1-N DOCKER-USER

只有一條 passthrough 時 reload 也清掉了 DOCKER-USER 的規則；加 passthrough 之前（沒有任何 direct 設定時），同一條規則留過了 reload。量完移除 passthrough、刪掉 direct.xml 再 reload，--get-all-passthroughs 回 0。所以在 nftables 後端（這兩台都是）上，清掉 iptables 自建規則的條件是 firewalld 有沒有 direct 設定（direct rule 或 passthrough 任一種），跟 FlushAllOnReload 的值無關。查的時候兩個指令都要跑：--get-all-rules 只列 direct rule，不列 passthrough。

firewalld 改用 iptables 後端時沒有這個條件。OrbStack 那一台把 /etc/firewalld/firewalld.conf 的 FirewallBackend 改成 iptables、重啟 firewalld 與 Docker，--get-all-rules 與 --get-all-passthroughs 都是 0，DOCKER-USER 裡的同一條規則在 firewall-cmd --reload 之後一樣不見了：原因依後端的設計推論是 iptables 後端的 firewalld 自己管理 iptables 的表，reload 時整張重建。量完改回 nftables、重啟兩個服務，nft list tables | grep -c 'inet firewalld' 回 1、iptables -t nat -S DOCKER | grep -c 8081 回 1，firewalld 的表與 Docker 的位址轉換規則都回來了。direct 設定也不是主機固定的屬性：之後裝的軟體可能再加進來，例如 fail2ban 的 firewallcmd-* 動作在 jail 啟動時寫 direct rule（依 fail2ban 的動作設定推論，沒有實跑），查的時候沒有、之後 reload 才清掉。只寫在執行中設定、沒有 --permanent 的 direct rule 是否同樣觸發，沒有量。

OCI 的 Oracle Linux 映像本來就有 passthrough。2026-10-26 用同一個映像（Oracle-Linux-10.2-aarch64-2026.10.16-0）建的另一台主機上：

1ls -l /etc/firewalld/direct.xml
2grep -c ' /etc/firewalld/direct.xml
3firewall-cmd --direct --get-all-rules | wc -l; firewall-cmd --direct --get-all-passthroughs | wc -l

1-rw-r--r--. 1 root root 8495 Aug  8 00:48 /etc/firewalld/direct.xml
232
30
432

direct.xml 有 32 條 passthrough，內容是 BareMetalInstanceServices 鏈：主機送往 169.254.0.0/16（Oracle Cloud 的執行個體中繼資料、iSCSI、DNS 與 NTP 這類服務）的連線，只放行列出的幾個服務連接埠，其中 iSCSI 的 3260 與部分 80 只限 root 的程式，其餘 TCP 與 UDP 一律回拒；每一條的註解寫著修改或移除之前先讀 Oracle 文件的〈Oracle-Provided Images〉。--get-all-rules 只列 direct rule、不列 passthrough，所以回 0；要用 --get-all-passthroughs 才看得到。依 OrbStack 那一台的 passthrough 結果，這 32 條就是第一輪 reload 清掉 DOCKER-USER 的原因；在這台主機上沒有移除它們再 reload 確認。這幾條規則保護主機與中繼資料服務之間的連線，刪掉它們換取 DOCKER-USER 的存續不划算；在 OCI 的 Oracle Linux 上，要長期使用的限制改寫進下文的自建 nftables 表。

再把同一組規則加回去，只重啟 dockerd、不動 firewalld：

1add_cf_only
2restart_dockerd
3iptables -S DOCKER-USER; iptables -S CF-ONLY | wc -l; probe 8081

1== 只重啟 dockerd（不 reload firewalld）
2-N DOCKER-USER
3-A DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL -j CF-ONLY
417
5  verify-cf     -> :8081  rc=0  200
6  verify-other  -> :8081  rc=28  curl: (28) Connection timed out after 5002 milliseconds

dockerd 重啟不清 DOCKER-USER，CF-ONLY 的 17 行（建鏈一行、15 段 RETURN、一條 DROP）都在，照樣擋得住。iptables 指令加的規則只存在執行中的核心裡，重開機之後不在；實測那一輪重開機之前 DOCKER-USER 已經被 reload 清空，所以重開機這一項依機制寫成，沒有單獨實測。這一節做完時 CF-ONLY 還在，〈firewalld policy 對發佈連接埠的效果與轉送鏈的順序〉開頭的 reload 會清掉它。

firewalld policy 對發佈連接埠的效果與轉送鏈的順序

Docker 用 docker-forwarding policy 放行轉送到 docker zone 的流量，所以試著加一條優先序更高的 policy，從 public 轉送到 docker 只放行 Cloudflare。firewall-cmd --reload 會一併清掉〈DOCKER-USER 鏈的限制效果與規則的存續〉留下的 CF-ONLY：

1firewall-cmd --permanent --new-policy=cf-to-docker
2firewall-cmd --permanent --policy=cf-to-docker --add-ingress-zone=public
3firewall-cmd --permanent --policy=cf-to-docker --add-egress-zone=docker
4firewall-cmd --permanent --policy=cf-to-docker --set-priority=-10      # 比 docker-forwarding 的 -1 先比對
5firewall-cmd --permanent --policy=cf-to-docker --set-target=DROP
6firewall-cmd --permanent --policy=cf-to-docker --add-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" accept'
7firewall-cmd --reload
8probe 8081
9restart_dockerd; probe 8081

reload 剛完成就連，兩個來源連 8081 都立即被回拒；restart_dockerd 之後再連，兩個來源都拿到 8081 的回應，policy 沒有擋下範圍外的來源。reload 剛完成時的回拒，推論是 Docker 的目的位址轉換規則還沒重建、封包沒有被改寫而落到 public zone 的回拒：〈DOCKER-USER 鏈的限制效果與規則的存續〉裡 reload 之後等 2 秒、下面移除這條 policy 之後等 3 秒再連，8081 都通了；回拒持續多久沒有量。policy 擋不住的原因在 firewalld 自己的轉送鏈：

1nft list chain inet firewalld filter_FORWARD

 1chain filter_FORWARD {
 2	type filter hook forward priority filter + 10; policy accept;
 3	ct state { established, related } accept
 4	ct status dnat accept
 5	iifname "lo" accept
 6	ct state invalid drop
 7	...
 8	jump filter_FORWARD_POLICIES
 9	reject with icmpx admin-prohibited
10}

ct status dnat accept 排在 jump filter_FORWARD_POLICIES 之前，經過目的位址轉換的連線在任何 policy 之前就被接受，policy 寫什麼都輪不到它。移除這條 policy，讓 StrictForwardPorts 那一節從沒有 policy 的狀態開始：

1firewall-cmd --permanent --delete-policy=cf-to-docker
2firewall-cmd --reload; sleep 3
3probe 8081

移除之後兩個來源都連得到 8081。

StrictForwardPorts=yes：轉送鏈的變化與 forward-port 規則的比對條件

firewalld 轉送鏈 filter_FORWARD 開頭的 ct status dnat accept 由設定檔的 StrictForwardPorts 控制，預設 no。這一節開始時，ipset cloudflare-v4、8080 的 rich rule 與三個容器都在，cf-to-docker 已經移除。（實測時這一節在另一輪、以重新建好的 namespace、ipset 與 verify-web-all 跑，結果不受影響。）改成 yes 再看轉送鏈與連線結果：

1cp /etc/firewalld/firewalld.conf /etc/firewalld/firewalld.conf.verify-bak
2sed -i 's/^StrictForwardPorts=no/StrictForwardPorts=yes/' /etc/firewalld/firewalld.conf
3grep '^StrictForwardPorts=' /etc/firewalld/firewalld.conf
4firewall-cmd --reload; sleep 3
5nft list chain inet firewalld filter_FORWARD; nft list chain inet firewalld filter_FORWARD_dnat
6probe 8081

grep 要回 StrictForwardPorts=yes；設定檔裡沒有這一行（較舊的 firewalld 沒有這個選項）時 sed 什麼都不改、也不報錯，後面的結果會跟下面不同。

 1StrictForwardPorts=yes
 2	ct state { established, related } accept
 3	ct status dnat jump filter_FORWARD_dnat
 4	...
 5	chain filter_FORWARD_dnat {
 6		reject with icmpx admin-prohibited
 7	}
 8== StrictForwardPorts=yes，還沒有任何放行
 9  verify-cf     -> :8081  rc=7  ... Could not connect to server
10  verify-other  -> :8081  rc=7  ... Could not connect to server

經過目的位址轉換的連線改跳到 filter_FORWARD_dnat，那條鏈只有回拒，兩個來源都連不到發佈的 8081。先試 policy：從 public 轉送到 docker、只放行 Cloudflare，target 用預設的 CONTINUE：

1firewall-cmd --permanent --new-policy=cf-to-docker
2firewall-cmd --permanent --policy=cf-to-docker --add-ingress-zone=public
3firewall-cmd --permanent --policy=cf-to-docker --add-egress-zone=docker
4firewall-cmd --permanent --policy=cf-to-docker --set-priority=-10
5firewall-cmd --permanent --policy=cf-to-docker --add-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" accept'
6firewall-cmd --reload; sleep 3; probe 8081
7restart_dockerd; probe 8081
8firewall-cmd --permanent --delete-policy=cf-to-docker; firewall-cmd --reload; sleep 3

加上 policy、reload 與 dockerd 重啟之後，兩個來源都還是立即被回拒：經過目的位址轉換的連線進的是 filter_FORWARD_dnat，policy 輪不到它們。〈firewalld.conf〉與 firewalld 官方部落格〈Strict Forward Ports〉的說法是，發佈的連接埠要用 firewalld 的 forward-port 明確放行。試的是 public zone 的 forward-port rich rule，限定來源是 Cloudflare 的 ipset：

1CIP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' verify-web-all)
2echo $CIP
3firewall-cmd --permanent --zone=public --add-rich-rule="rule family=\"ipv4\" source ipset=\"cloudflare-v4\" forward-port port=\"8081\" protocol=\"tcp\" to-port=\"80\" to-addr=\"$CIP\""
4firewall-cmd --reload; sleep 3
5nft list chain inet firewalld filter_FORWARD_dnat
6probe 8081
7restart_dockerd; probe 8081

CIP 是容器在 docker0 網路上的位址（這次是 172.17.0.2）。Docker 29 的 docker inspect 已經沒有 .NetworkSettings.IPAddress 這個欄位，用舊的寫法會回 map has no entry for key "IPAddress"，CIP 是空的，接著 firewall-cmd 回 INVALID_RULE: internal error in _lexer(): to-addr=；所以從 .NetworkSettings.Networks 取。

1	chain filter_FORWARD_dnat {
2		ct original proto-dst 8081 accept
3		reject with icmpx admin-prohibited
4	}
5== 加上限定來源的 forward-port rich rule
6  verify-cf     -> :8081  rc=0  200
7  verify-other  -> :8081  rc=0  200

firewalld 依這條 rich rule 在 filter_FORWARD_dnat 寫的放行是 ct original proto-dst 8081 accept，只比對原始目的連接埠，rich rule 的來源條件沒有寫進這一條，所以範圍外的來源也連得到；dockerd 重啟之後結果相同。rich rule 的來源條件只出現在 firewalld 依同一條規則另外寫的那條目的位址轉換裡，而 Docker 自己的位址轉換已經先改寫了封包。

OrbStack 那一台另外在 StrictForwardPorts=yes 下試了兩種 forward-port。一是寫在 policy 上：新建 policy verify-fp（--new-policy=verify-fp、--add-ingress-zone=public、--add-egress-zone=docker），從 public 到 docker，rich rule 一樣帶來源 ipset 與 to-addr。firewall-cmd 接受這條規則（回 success），reload 之後 filter_FORWARD_dnat 裡仍然只有 reject with icmpx admin-prohibited，沒有任何放行，兩個來源連 8081 都被回拒：policy 上的 forward-port 沒有在 StrictForwardPorts 的那條鏈裡留下放行。二是不帶 to-addr、轉到本機另一個連接埠：

1firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" forward-port port="8088" protocol="tcp" to-port="8080"'
2firewall-cmd --reload; sleep 3; probe 8088

public zone 沒有開 8080，而 verify-cf 連 8088 拿到 8080 那個主機程式的回應、verify-other 被回拒：轉到本機的 forward-port 帶著來源條件，結果是只有 Cloudflare 連得到。它轉到的是主機上的程式（封包改寫成本機位址之後走 input 路徑，見 DNAT 卡），不是容器，所以只適用於網站由主機上的程式（或聽在主機位址上的反向代理）提供的情形。還原這一節改的設定：

1firewall-cmd --permanent --zone=public --remove-rich-rule="rule family=\"ipv4\" source ipset=\"cloudflare-v4\" forward-port port=\"8081\" protocol=\"tcp\" to-port=\"80\" to-addr=\"$CIP\""
2firewall-cmd --permanent --delete-policy=verify-fp             # OrbStack 那一台試的 policy
3firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" forward-port port="8088" protocol="tcp" to-port="8080"'
4mv /etc/firewalld/firewalld.conf.verify-bak /etc/firewalld/firewalld.conf
5firewall-cmd --reload; sleep 3
6grep '^StrictForwardPorts=' /etc/firewalld/firewalld.conf; firewall-cmd --zone=public --list-rich-rules

grep 回 StrictForwardPorts=no，rich rule 只剩 8080 那一條。OrbStack 那一台改 StrictForwardPorts 時用的是 sed 直接改值，沒有備份檔，還原也用 sed 改回 no；mv 那一行是 OCI 那一台的做法。

自己的 nftables 表：掛在目的位址轉換之前

這一節開始時 StrictForwardPorts 是 no，三個容器都在跑。在 nftables 建一張自己的表 verify_cf_only，鏈接在 prerouting 這個 hook 上、優先序 dstnat - 10（排在 Docker 與 firewalld 的目的位址轉換之前），封包的目的連接埠還是 8081 時就比對來源：

 1CF=$(paste -sd, $D/cf-ips-v4.txt)
 2cat > $D/verify-cf-only.nft < 3table inet verify_cf_only {
 4  set cloudflare_v4 { type ipv4_addr; flags interval; elements = { $CF } }
 5  chain prerouting {
 6    type filter hook prerouting priority dstnat - 10; policy accept;
 7    iifname != "lo" tcp dport { 8081 } ip saddr != @cloudflare_v4 drop
 8  }
 9}
10EOF
11nft -f $D/verify-cf-only.nft
12probe 8081; probe 8083
13curl -sS -o /dev/null -w '%{http_code}\n' http://$HOSTIP:8081/

iifname != "lo" 讓主機自己連自己的位址不受限制；flags interval 讓位址集合 cloudflare_v4 存得下位址段。優先序排在 dstnat 或之後時，封包的目的連接埠已經被改寫成 80，tcp dport { 8081 } 比對不到，範圍外的來源會連得到（依 nftables 的 hook 順序推論，沒有實跑）。ip saddr 只比對 IPv4；主機有 IPv6 時，IPv6 的連線不受這條規則限制，要另寫一條 ip6 saddr 與 IPv6 的集合，後果見概念文章的〈只放行 CDN 位址的套用時機、範圍與清單的維護〉。

1== 自己的 nft 表，只放行 Cloudflare 到 8081
2  verify-cf     -> :8081  rc=0  200
3  verify-other  -> :8081  rc=28  curl: (28) Connection timed out after 5002 milliseconds
4== 對照 8083
5  verify-cf     -> :8083  rc=0  200
6  verify-other  -> :8083  rc=0  200
7200

接著重新載入 firewalld 與重啟 dockerd，各看一次：

1firewall-cmd --reload; sleep 3; nft list tables | grep verify; probe 8081
2restart_dockerd; nft list tables | grep verify; probe 8081

兩次都列得出 table inet verify_cf_only，結果跟上面相同。firewalld 重新載入只重建它自己的 inet firewalld 這張表，自建的表留著。

nft -f 只改執行中的規則，開機時要由 nftables.service 載入。先看這台主機上這個服務與它的設定檔原本的狀態：

1systemctl is-enabled nftables
2grep -v '^#' /etc/sysconfig/nftables.conf | grep -c .
3systemctl cat nftables | grep -E '^Exec'; systemctl cat firewalld | grep '^Conflicts'

這台回 disabled、0（設定檔有 6 行、全部是註解）。ExecStop 是 /sbin/nft flush ruleset，ExecReload 是 nft 'flush ruleset; include "/etc/sysconfig/nftables.conf";'；firewalld 的 Conflicts= 列的是 iptables.service ip6tables.service ebtables.service ipset.service，沒有 nftables.service，所以兩者可以同時啟用。設定檔原本就有內容、尤其有 flush ruleset 時，開機載入它會清掉 firewalld 已經建好的表，那時不要在這個檔加 include，改用下面替代做法裡的 oneshot unit。設定檔原本是空的時：

1cp /etc/sysconfig/nftables.conf /etc/sysconfig/nftables.conf.verify-bak
2cp $D/verify-cf-only.nft /etc/nftables/verify-cf-only.nft
3echo 'include "/etc/nftables/verify-cf-only.nft"' >> /etc/sysconfig/nftables.conf
4nft -c -f /etc/sysconfig/nftables.conf && echo "syntax ok"     # -c 只檢查語法，不套用
5systemctl enable nftables
6systemctl reboot

重開機之後：

1nft list tables
2systemctl is-active firewalld nftables
3journalctl -b -u nftables -u firewalld --no-pager | tail -3

1table inet verify_cf_only
2table inet firewalld
3table ip filter
4table ip6 filter
5active
6active
7... Started firewalld.service - firewalld - dynamic firewall daemon.
8... Starting nftables.service - Netfilter Tables...
9... Finished nftables.service - Netfilter Tables.

這一次 firewalld 先啟動、nftables.service 接著完成，兩張表都在。接著 sudo -i、重新貼〈共用的變數與函式〉的區塊，再跑：

1ns_setup
2start_dockerd
3docker start verify-web-all verify-web-lo verify-web-v; sleep 2
4probe 8081; probe 8083

1== 重開機後 8081（開機載入的 nft 表）
2  verify-cf     -> :8081  rc=0  200
3  verify-other  -> :8081  rc=28  curl: (28) Connection timed out after 5002 milliseconds
4== 重開機後 8083（沒有限制）
5  verify-cf     -> :8083  rc=0  200
6  verify-other  -> :8083  rc=0  200

nftables.service 的 stop、restart 與 reload 都會先 flush ruleset，清掉的是整個 nftables 規則集，firewalld 的 inet firewalld 表也在裡面。所以這個服務只用來開機載入；改了 verify-cf-only.nft 之後，先 nft delete table inet verify_cf_only 再 nft -f 那一個檔。這一段依 unit 檔的內容寫成，沒有實跑 restart。

這一步的替代做法：

自己寫一個開機時執行 nft -f /etc/nftables/verify-cf-only.nft 的 systemd oneshot unit：不經過 nftables.service，避開它的 flush ruleset，誤下 systemctl restart nftables 也不會清掉 firewalld 的表；代價是多一個要維護的 unit，沒有實跑。
把同樣的規則寫成 firewalld 的 direct rule 或 passthrough：firewalld 會在每次重新載入時重寫，但〈firewalld.direct〉寫明 direct 介面已經棄用、由 policy 取代；而且主機一有 direct 設定，reload 就會清掉 iptables 裡其他自建的規則（〈DOCKER-USER 鏈的限制效果與規則的存續〉量到的），沒有實跑這個寫法本身。
把 { 8081 } 換成 { 80, 443 }：這是正式設定的寫法，但要多一個條件 fib daddr type local（目的地是這台主機自己的位址）。少了它時，容器自己往外連 443、容器之間連 80 的封包也從 docker0 進 prerouting、目的連接埠一樣是 443 或 80、來源不在清單，一起被丟掉。OrbStack 那一台補測：規則寫成 iifname != "lo" tcp dport { 80, 443, 8081 } ip saddr != @cloudflare_v4 drop 時，一個 busybox 容器 wget https://www.cloudflare.com/ 與連另一個容器的 80 都失敗；改成 iifname != "lo" fib daddr type local tcp dport { 80, 443, 8081 } ip saddr != @cloudflare_v4 drop 之後兩者恢復，範圍外的來源連 8081 仍然逾時。拿掉 tcp dport 這個條件時，規則變成對整台主機所有連接埠的 Cloudflare 限制，那時要另外排除管理通道進來的介面或來源，否則 SSH 一起被擋。

這張表的規則不出現在 firewall-cmd --list-all 裡，查的指令是 nft list table inet verify_cf_only。

出站的 DNS 只准送往 VCN 解析器：主機與容器的差別

在 verify-other（203.0.113.10）放一個收 UDP 53 與 TCP 443 的小程式，把收到的封包記進 log，用 log 的筆數判斷封包有沒有送到。RESOLVER 是〈共用的變數與函式〉裡填的主機解析器：

 1cat > $D/listen.py <<'EOF'
 2import socket, threading, sys
 3log = open(sys.argv[1], "a", buffering=1)
 4def udp():
 5    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s.bind(("203.0.113.10", 53))
 6    while True:
 7        data, peer = s.recvfrom(4096); log.write(f"udp53 from {peer[0]}\n")
 8def tcp():
 9    s = socket.socket(); s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1); s.bind(("203.0.113.10", 443)); s.listen()
10    while True:
11        c, peer = s.accept(); log.write(f"tcp443 from {peer[0]}\n"); c.close()
12threading.Thread(target=udp, daemon=True).start(); tcp()
13EOF
14ip netns exec verify-other python3 $D/listen.py $D/listen.log &
15sleep 1
16check() {  # 清空 log，送四種流量，數對方收到的封包
17  : > $D/listen.log
18  dig +tries=1 +time=2 @$RESOLVER oracle.com A +short >/dev/null 2>&1 && r1=ok || r1=fail
19  dig +tries=1 +time=2 @203.0.113.10 oracle.com A >/dev/null 2>&1
20  curl -s -m 3 -o /dev/null http://203.0.113.10:443/
21  docker run --rm busybox:1.37 nslookup -timeout=2 oracle.com 203.0.113.10 >/dev/null 2>&1
22  sleep 1
23  echo "  host -> $RESOLVER:53  $r1"
24  echo "  203.0.113.10 收到的封包：$(sort $D/listen.log | uniq -c | tr '\n' ';')"
25}
26check

dig +tries=1 只送一次查詢；容器裡 busybox 的 nslookup 用 docker run --rm 起一個只跑這一條指令的容器。curl 連 443 用的是 HTTP，監聽程式收到連線就關掉，對方記到一筆 tcp443 就代表封包送到了，回應內容不重要；這是一般的 TCP 連線，不是 DNS over HTTPS 的查詢。加限制之前：

1== 沒有出站限制
2  host -> 169.254.169.254:53  ok
3  203.0.113.10 收到的封包：1 tcp443 from 192.0.2.5; 5 udp53 from 192.0.2.5;

容器的封包經過 Docker 的位址偽裝（masquerade），在對方看來來源也是主機的 192.0.2.5，所以收到的 5 個 UDP 53 混著主機與容器的。加一條從 HOST（主機本身送出的流量）到 ANY（任何 zone）的 policy：

1firewall-cmd --permanent --new-policy=egress-dns
2firewall-cmd --permanent --policy=egress-dns --add-ingress-zone=HOST
3firewall-cmd --permanent --policy=egress-dns --add-egress-zone=ANY
4firewall-cmd --permanent --policy=egress-dns --add-rich-rule="rule priority=\"-2\" family=\"ipv4\" destination address=\"$RESOLVER\" service name=\"dns\" accept"
5firewall-cmd --permanent --policy=egress-dns --add-rich-rule='rule priority="-1" service name="dns" reject'
6firewall-cmd --reload; sleep 3
7check

priority 小的 rich rule 先比對，放行指定解析器的那一條要排在拒絕之前。

1== firewalld policy egress-dns（HOST -> ANY）
2  host -> 169.254.169.254:53  ok
3  203.0.113.10 收到的封包：1 tcp443 from 192.0.2.5; 4 udp53 from 192.0.2.5;

分開送，確認那 4 個是誰的：

1: > $D/listen.log; dig +tries=1 +time=2 @203.0.113.10 oracle.com A | grep -E 'refused|timed out'; sleep 1; wc -l < $D/listen.log
2: > $D/listen.log; docker run --rm busybox:1.37 nslookup -timeout=2 oracle.com 203.0.113.10 >/dev/null 2>&1; sleep 1; wc -l < $D/listen.log

只有主機 dig @203.0.113.10 時對方收到 0 個，dig 印 communications error to 203.0.113.10#53: connection refused；只有容器 nslookup 時對方收到 4 個。這條 policy 擋下主機本身的查詢，容器的查詢走轉送路徑、不經過 HOST，照樣送出去；送往 443 的連線在加限制之前與之後都送到。這裡的容器跑在預設的 bridge 網路（介面 docker0），查詢直接從容器送出。compose 的自訂網路上，容器先問 Docker 內建的解析器 127.0.0.11，內建解析器往外查的封包由主機送出，結果反過來：OrbStack 那一台上把這條 policy 改成拒絕主機送出的全部 dns，compose 容器經由 127.0.0.11 的查詢失敗、bridge 容器照常；量法與 conntrack 的輸出在 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑的〈compose 自訂網路的容器經由 127.0.0.11 查詢時，DNS 封包從哪裡送出〉。容器自己送出的查詢另外寫在 DOCKER-USER（自訂網路的介面是 br- 開頭，-i docker0 改成 -i br-+ 或兩條都寫）：

1iptables -I DOCKER-USER -i docker0 -p udp --dport 53 ! -d $RESOLVER -j REJECT
2iptables -I DOCKER-USER -i docker0 -p tcp --dport 53 ! -d $RESOLVER -j REJECT
3check

1== 再加 DOCKER-USER：容器的 53 只准到 169.254.169.254
2  host -> 169.254.169.254:53  ok
3  203.0.113.10 收到的封包：1 tcp443 from 192.0.2.5;

這兩條寫在 DOCKER-USER，有〈DOCKER-USER 鏈的限制效果與規則的存續〉量到的問題：這台主機上 firewall-cmd --reload 之後規則消失，重開機之後也不在。要長期使用就改寫進自建的 nftables 表，鏈接在 forward hook 上。OrbStack 那一台實跑了這個寫法（RESOLVER 是〈共用的變數與函式〉填的主機解析器）：

1cat > $D/verify-egress.nft <2table inet verify_egress {
3  chain forward {
4    type filter hook forward priority filter - 10; policy accept;
5    iifname { "docker0", "br-*" } meta l4proto { tcp, udp } th dport 53 ip daddr != $RESOLVER drop
6  }
7}
8EOF
9nft -f $D/verify-egress.nft

"br-*" 比對 compose 自訂網路的介面；th dport 53 同時比對 TCP 與 UDP 的目的連接埠；優先序 filter - 10 排在 firewalld 的轉送鏈（filter + 10）之前。bridge 容器與 compose 容器直接問 1.1.1.1 的查詢都失敗，經由各自預設解析器的照常；firewall-cmd --reload 之後 nft list tables 仍列得出 table inet verify_egress，結果相同。compose 容器經由 127.0.0.11 的那一路不經過 forward hook，要靠上面主機的 policy。開機載入的做法同〈自己的 nftables 表：掛在目的位址轉換之前〉。

清理：容器、dockerd、防火牆設定與暫存檔

照上面的順序做完時，要清的有：三個容器與映像、dockerd、兩個 namespace、8080 的 rich rule、ipset、egress-dns policy、Docker 建的 zone 與 policy、自建的 nftables 表與它的開機載入，以及暫存目錄。中途停下來的讀者，只跑做過的那幾節對應的行；--remove-rich-rule 與 --delete-* 對不存在的項目只回錯誤，不改別的設定。

 1docker rm -f verify-web-all verify-web-lo verify-web-v; docker rmi busybox:1.37
 2pkill -x dockerd; while pgrep -x dockerd >/dev/null; do sleep 1; done; pkill -x containerd
 3pkill -f 'http.server 8080'; pkill -f "$D/listen.py"
 4ip link del vcf-h; ip link del voth-h; ip netns del verify-cf; ip netns del verify-other
 5firewall-cmd --permanent --zone=public --remove-rich-rule='rule family="ipv4" source ipset="cloudflare-v4" port port="8080" protocol="tcp" accept'
 6firewall-cmd --permanent --delete-policy=egress-dns
 7firewall-cmd --permanent --delete-ipset=cloudflare-v4
 8firewall-cmd --permanent --delete-policy=docker-forwarding     # 這台主機原本沒有 Docker 時才刪
 9firewall-cmd --permanent --delete-zone=docker                  # 同上
10firewall-cmd --reload
11nft delete table inet verify_cf_only
12mv /etc/sysconfig/nftables.conf.verify-bak /etc/sysconfig/nftables.conf; rm -f /etc/nftables/verify-cf-only.nft
13systemctl disable nftables                                     # 實測前是 disabled 時才關
14rm -rf /var/lib/docker /var/lib/containerd /run/docker /var/run/docker.sock   # 這台主機原本沒有 Docker 時才刪
15cd /; rm -rf /tmp/verify-fw
16systemctl reboot

OrbStack 那一台另外多了幾項，各節測完已經還原的（zone verify-cfzone、IPv6 的 rich rule、daemon.json、policy verify-fp、8088 的 forward-port、table inet verify_egress）不必再清，剩下的是 lo 上的 ULA 與 IPv6 的 ipset；這兩行沒有實跑：

1ip -6 addr del fd00:beef::1/128 dev lo
2firewall-cmd --permanent --delete-ipset=cloudflare-v6; firewall-cmd --reload

ipset 排在引用它的 rich rule 之後刪。Docker 建的 docker zone 與 docker-forwarding policy 寫進了 firewalld 的永久設定，dockerd 停掉之後還在。/var/lib/docker 與 /var/lib/containerd 存著 Docker 的映像、容器與 volume；這次的主機原本沒有 Docker，所以整個刪掉。主機原本就有 Docker、這次只是借用時，只刪這次建的三個容器（busybox:1.37 原本就有的話也留著），zone、policy 與這兩個目錄都留著，dockerd 與 containerd 用 systemctl 管，不用 pkill。重開機是為了清掉 dockerd 留在 iptables 的 nat 與 filter 規則，以及被它改成 1 的 ip_forward。重開之後：

1nft list tables; sysctl net.ipv4.ip_forward
2firewall-cmd --list-all | grep -E 'services|rich|forward-ports'; firewall-cmd --get-ipsets
3grep '^StrictForwardPorts=' /etc/firewalld/firewalld.conf
4find /tmp /var/tmp -maxdepth 1 -name 'verify-*'

nft list tables 只剩 inet firewalld、ip filter、ip6 filter（跟實測前登入後第一次查的結果相同），net.ipv4.ip_forward = 0，public zone 只有 dhcpv6-client ssh、沒有 rich rule 與 forward-port，--get-ipsets 沒有輸出，StrictForwardPorts=no，find 沒有輸出。

各種寫法在重新載入、dockerd 重啟與重開機之後的結果

這張表的「範圍外的來源」欄量的是規則剛套上時；其餘三欄量的是規則套上之後各做一次那個動作，範圍外的來源還連不連得到、規則還在不在。「沒有單獨測」是那個動作做過、但這條規則不是當時要量的對象，沒有記錄它的狀態；「沒有測」是沒有做那個動作。DOCKER-USER 那一列只比對連接埠，正式改成 80、443 時要加 --ctstate DNAT，自建 nftables 表那一列要加 fib daddr type local（各節的說明）。

寫法	範圍外的來源連發佈的連接埠	`firewall-cmd --reload` 之後	dockerd 重啟之後	重開機之後
firewalld rich rule（只放行 ipset，寫在 zone 上）	連得到（規則管不到轉送路徑）	規則還在	規則還在	沒有單獨測（`--permanent` 依機制會在）
只發佈在 `127.0.0.1`	連不到	沒有單獨測	沒有測	沒有測（發佈位址屬於容器設定）
`DOCKER-USER` 跳到自建鏈	被擋（逾時）	nftables 後端有 direct rule 或 passthrough 時、或 iptables 後端時規則消失（OCI 的映像有 passthrough），其餘還在	規則還在	沒有單獨測（依機制不在）
firewalld policy（`public` 到 `docker`）	連得到（`ct status dnat accept`）	以 reload 套用，見正文	連得到	沒有測
`StrictForwardPorts=yes` 加限定來源的 forward-port	連得到（放行規則只比對連接埠）	連得到（規則以 reload 套用）	連得到	沒有測
`StrictForwardPorts=yes` 加 policy 上的 forward-port	連不到（範圍內的也被回拒）	以 reload 套用	沒有測	沒有測
自建 nftables 表（prerouting，位址轉換之前）	被擋（逾時）	規則還在	規則還在	規則還在（`nftables.service`）

OrbStack 那一台補測的幾列（DOCKER-USER 在沒有 direct 設定時的存續、policy 上的 forward-port）環境與 OCI 那一台不同，見事件說明；轉到本機程式的 forward-port 與自建表的出站 DNS 限制不是限制發佈的連接埠，不列在這張表，結果在各自的段落。

GCP VM 的 SSH 與 RDP 管理通道：從預設的全開規則改走 IAP TCP forwarding

Fri, 23 Oct 2026 00:00:00 +0800

這篇整理 GCP Compute Engine 上管理員登入 VM 的通道（Linux 的 SSH、Windows 的 RDP），從防火牆對 0.0.0.0/0 開放 22 與 3389 port 改成走 Identity-Aware Proxy（IAP）TCP forwarding 的機制與判斷依據：預設網路的規則與它們留下的暴露面、IAP 的連線路徑、切換的順序為什麼這樣排、連不上時的依層判讀、IAM 授權的範圍、OS Login、拿掉外部 IP 之後的出站路徑、組織層級的護欄與稽核。範圍從專案裡已經有 VM、而且用的是預設網路（default network）開始；自建網路上手寫的全開規則，處理方式相同。從盤點、救援入口、建規則與授權、停用舊規則驗證、啟用 OS Login 到移除外部 IP 的逐步操作與實跑結果，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄。IAP 這一類代理服務的共通機制見 Identity-Aware Proxy（身分感知代理）。

管理通道為什麼要收斂、它拆成哪幾層、各層有哪些與廠商無關的做法，在伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口。本篇是那套模型在 GCP 上的一種組合：

管理通道的層	本篇在 GCP 上的做法
網路可達性	防火牆只放行 IAP 的來源位址段，VM 移除外部 IP
通道授權	Google 帳號加 IAM role `roles/iap.tunnelResourceAccessor`
主機登入驗證	Linux 用 OS Login；Windows 用 VM 上的 Windows 帳號

救援入口用 Serial Console，它不經過上面三層的設定，有自己的 IAM 權限與開關。

這個組合假設組織的身分提供者（identity provider，IdP）是 Google 帳號：IAP 與 OS Login 都依 Google 的 IAM 判斷。組織用的是 Microsoft Entra ID、Okta 這類其他 IdP 時，有兩條路。一條是讓 Cloud Identity 以 SAML 單一登入接那個 IdP、並由 IdP 把帳號同步進來，使用者在原本的 IdP 登入、拿到的是 Google 身分，本篇全部適用。另一條是通道授權改用能接那個 IdP 的代理服務，網路可達性跟著那個代理走（防火牆改放行它的位址段，或改用不開入站 port 的反向連線）；這時本篇依賴 Google 帳號的幾節——〈IAP 的 IAM 授權範圍：誰拿得到通道〉、〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉的 OS Login 與組織政策的 compute.requireOsLogin、稽核紀錄裡 IAP 的 Data Access 紀錄——都不適用，Cloud NAT、移除外部 IP、Serial Console 與防火牆規則的收斂仍然適用。

另外四種環境要先調整做法再往下讀：

由 managed instance group（MIG）或 GKE 管理的 VM：tag、metadata、救援帳號與移除外部 IP 都要改在 instance template、node pool 設定或映像檔裡。逐台用 gcloud 修改，VM 在自動修復、升級或縮放時重建，修改就消失，tag 消失之後 IAP 規則也套不到新的 VM。這兩種環境的設定位置、救援改用重建的做法與 GKE 控制層的存取，見GCP 上由 MIG 與 GKE 管理的 VM 的管理存取。
Shared VPC 的 service project：防火牆規則住在 host project，防火牆相關的指令要在 host project 執行；停用 default-allow-ssh 這類規則會同時影響其他 service project 的 VM。
用 Terraform 這類 IaC 管理的專案：每一個 gcloud 修改都要改寫成程式碼。只在 CLI 加的 tag、IAM 授權與 metadata，若所屬資源在程式碼裡被完整定義（例如 google_compute_instance 寫了 tags、用 google_project_iam_policy 管 IAM），下一次 apply 會把它拿掉；只在 CLI 刪掉的規則與外部 IP，下一次 apply 會建回來。用 CLI 停用舊規則做驗證的期間要暫停所有 apply。兩個方向的落差與過渡期的做法見兩套真相並存的過渡期操作。
新專案從零開始：沒有舊規則要移走，切換前的盤點與停用驗證可以跳過，直接建 IAP 規則、OS Login 與 Cloud NAT；建 VM 時加 --no-address 就不配外部 IP。2024 年 5 月 3 日之後建立的 Organization 會預設強制一組 Organization Policy，其中可能已經包含本篇〈組織層級的護欄：Organization Policy 與階層式防火牆〉提到的幾項；用 gcloud resource-manager org-policies list --organization= 查組織層級設定了哪些（用 gcloud organizations list 查）。

預設網路自帶的防火牆規則

專案第一次啟用 Compute Engine API 時，GCP 會自動建一個叫 default 的 auto-mode VPC，並在上面預先建好四條入站規則。這四條規則的設計目標是讓第一次用 GCP 的人開完 VM 就連得上，所以來源範圍放得很寬。

規則名稱	放行內容	來源範圍
`default-allow-ssh`	tcp:22	`0.0.0.0/0`
`default-allow-rdp`	tcp:3389	`0.0.0.0/0`
`default-allow-icmp`	ICMP	`0.0.0.0/0`
`default-allow-internal`	同網路內 TCP、UDP 所有 port 與 ICMP	`10.128.0.0/9`

GCP 的防火牆規則依 priority 數字由小到大評估。這四條的 priority 是 65534，只排在 VPC 隱含的「拒絕所有入站」規則（65535）前面，所以自己建立的規則（不指定時是 1000）都會比它們先被評估。它們也沒有指定 target tag（防火牆規則用來挑選作用對象的標記），作用對象是這個網路裡的每一台 VM。Oracle Cloud 與 AWS 預設網路的同類規則見網路：subnet、私有 IP、公開 IP 與防火牆規則的〈各家預設網路規則對 SSH 的開放〉。

只收掉 default-allow-ssh 會留下兩個暴露面。default-allow-rdp 讓每一台 Windows VM 的遠端桌面對整個網際網路開放，而 RDP 預設接受密碼登入。default-allow-internal 讓同一個網路裡的 VM 之間不受 port 限制，一台 VM 被入侵之後，攻擊者從那台機器能直接連到其他 VM 的資料庫 port 與管理 port，這種擴散方式叫橫向移動（lateral movement）。另外，這四條自動建立的規則預設沒有開啟 firewall rules logging，防火牆這一層不會留下被掃描或被連入的紀錄。管理 port 對外開放的風險與廠商無關，見伺服器管理通道的設計的〈對外開放管理 port 的實際風險〉。

CIS Google Cloud Platform Foundation Benchmark 的 3.1 條因此建議專案裡不保留 default 網路，改用自己規劃 subnet 的 custom-mode VPC。已經有服務跑在 default 網路上的專案，可以先收斂這四條規則，搬遷網路排進另一次變更；收斂 default-allow-internal 與 default-allow-icmp 的指令與實測結果在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈收斂 default-allow-internal 與 default-allow-icmp〉。

列出專案目前在 default 網路上的規則，--format 讓 gcloud 把來源範圍與 target tag 兩欄加進輸出（預設表格沒有這兩欄）：

1# 列出 default 網路上的防火牆規則，含來源範圍、放行內容與 target tag
2gcloud compute firewall-rules list --filter="network:default" \
3  --format="table(name,priority,sourceRanges.list():label=SRC_RANGES,allowed[].map().firewall_rule().list():label=ALLOW,targetTags.list():label=TARGET_TAGS,disabled)"

輸出裡要看 SRC_RANGES 欄是 0.0.0.0/0 的列，以及 TARGET_TAGS 欄是空白的列——空白代表規則套用到整個網路的每一台 VM。這兩條規則要換掉、不能直接刪：刪除的當下，管理員自己的 SSH 與 RDP 連線會一起中斷，理由見〈切換到 IAP 的順序〉。從 Security Command Center 的 OPEN_SSH_PORT 或 OPEN_RDP_PORT finding 進來的，finding 裡寫著被標記的那條規則的資源名稱，以那個名稱替換指令裡的 default-allow-ssh；網路不是 default 時，把 --filter 裡的網路名稱一起換掉。

IAP TCP forwarding 的連線路徑與來源範圍

IAP TCP forwarding 是 GCP 的身分感知代理：管理員的 gcloud 先用 HTTPS 連到 Google 的 IAP 端點，IAP 檢查這個 Google 帳號有沒有開通道的 IAM 權限，通過之後由 IAP 從 35.235.240.0/20 這段位址連到 VM 的內部 IP 與指定 port，再把兩端的位元組來回轉送。

一條連線因此由兩個元件各檢查一次，分別對應通道授權與主機登入驗證：

驗證位置	由誰檢查	檢查什麼
IAP 端點	Google IAM	這個 Google 帳號在這個 VM 上有沒有 `iap.tunnelInstances.accessViaIAP` 權限
VM 內部	Linux 上的 sshd／Windows 的遠端桌面服務	SSH 金鑰在不在授權清單裡（metadata 金鑰或 OS Login）／Windows 帳號密碼

IAP 只決定是否允許開通道，開了通道之後登入 VM 仍然要過 VM 自己的認證，所以兩者要分開設定、分開稽核：IAM 給得太寬，sshd 就暴露給不該碰這台 VM 的成員；VM 的金鑰管理鬆散，拿到通道的人就能用別人留下的金鑰登入。

35.235.240.0/20 是 Google 文件公開的 IAP TCP forwarding 來源範圍，裡面包含 IAP 轉送時使用的全部位址。IPv6 的 VM 要另外放行 2600:2d00:1:7::/64；auto-mode 的 default 網路只有 IPv4 subnet，IPv6 的規則只在自建、開了 dual-stack subnet 的 custom-mode VPC 上用得到。這兩段位址是 Google 定義的規格值，每個專案都相同，可以直接寫進防火牆規則；Google 調整範圍時以 IAP TCP forwarding 文件為準。防火牆規則的關鍵是 --source-ranges=35.235.240.0/20 加上 --target-tags 限定作用的 VM、--rules 只開需要的 port，完整的建立指令與各引數在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則〉。

設定完成之後，日常的連線指令是這幾條，與用 gcloud compute instances list 查，第一欄是 VM 名稱、第二欄是 zone：

1# Linux：透過 IAP 通道 SSH 進 VM
2gcloud compute ssh  --zone= --tunnel-through-iap
3
4# Linux：透過 IAP 通道傳檔
5gcloud compute scp  : --zone= --tunnel-through-iap
6
7# Windows：把 VM 的 3389 port 經 IAP 轉到本機的 13389，再用 RDP 用戶端連 localhost:13389
8gcloud compute start-iap-tunnel  3389 --local-host-port=localhost:13389 --zone=

主控台上 VM 旁的 SSH 按鈕（SSH-in-browser）不是這幾條指令：官方〈Connect to Linux VMs using IAP〉寫明它只在 VM 沒有外部 IP 時才走 IAP，VM 還帶外部 IP 時它連的是外部 IP，舊規則停用之後就連不上。本機的 port 用 3389 以外的號碼（這裡是 13389），管理員自己的 Windows 電腦開著遠端桌面時，本機的 3389 已經被占用。Ansible 這類用一般 ssh 連線的工具，在 ssh 設定裡用 ProxyCommand 讓 gcloud 開通道：

1# ~/.ssh/config： 寫 VM 名稱，ssh 連線時代入 %h
2Host 
3  ProxyCommand gcloud compute start-iap-tunnel %h 22 --listen-on-stdin --zone= --project=
4  User 
5  IdentityFile

--listen-on-stdin 讓 gcloud 把通道接到標準輸入輸出，ssh 就經由 IAP 連到 %h；這個旗標不出現在 gcloud compute start-iap-tunnel --help 的輸出裡，而功能存在。VM 啟用了 OS Login 時，一般 ssh 不會像 gcloud compute ssh 那樣自動把公鑰登錄到帳號的 OS Login profile，所以先以 Ansible 開通道所用的服務帳號（）的身分登錄一次：gcloud compute os-login ssh-keys add --key-file= --impersonate-service-account=，是對應的公鑰檔；用同樣加上 --impersonate-service-account 的 gcloud compute os-login describe-profile 輸出裡的 username。

IAP 通道的代價在傳輸速度：所有位元組都經過 Google 的轉送，傳大檔案比直連慢，大量傳檔適合改用 Cloud Storage 當中轉。

切換到 IAP 的順序

切換的順序由兩個事實決定。default-allow-ssh 的來源 0.0.0.0/0 本身就涵蓋 IAP 的位址段，所以舊規則還在的時候，經由 IAP 的連線成功，可能是舊規則放行的，證明不了新規則寫對了；驗證新規則因此要先停用舊規則。而停用舊規則的那一刻，從公開網際網路來的 SSH 與 RDP 都會被拒絕，包括管理員自己的連線與依賴這條規則的 CI、監控、廠商連線。所以：依賴舊規則的連線要先盤點出來並改走 IAP；救援入口（Serial Console 與本機救援帳號）要在停用之前準備好並實際登入過；新規則、tag 與 IAM 權限要在停用之前建好；停用之後確認新路徑可用，才刪除舊規則。與廠商無關的推導見伺服器管理通道的設計的〈切換管理通道時避免把自己鎖在外面〉。

這個順序裡有三件事的判斷落在 GCP 的機制上：

盤點靠 VM 上的登入紀錄，不只靠防火牆紀錄：全開規則的紀錄大部分是網際網路掃描程式的來源，CI 託管執行環境的 IP 每次不同，混在裡面認不出來；VM 上 sshd 紀錄的帳號與金鑰指紋才認得出是哪個人或哪個工具。
驗證用停用而不是刪除：停用的規則用 --no-disabled 一行恢復原樣，刪除之後要重建、重建時可能寫錯；防火牆規則透過 GCP 的 API 修改，SSH 連不上也改得回來。
Serial Console 的權限收不窄：連 Serial Console 需要能修改這台 VM 的權限（例如 roles/compute.instanceAdmin.v1），而這個角色也是一般 VM 管理會用到的權限，所以光靠 IAM 收不窄救援入口；真正把它收窄的是組織政策 compute.disableSerialPortAccess（見〈組織層級的護欄：Organization Policy 與階層式防火牆〉）。組織強制了這條政策時，救援名單裡要有持有組織政策權限、能對專案解除它的人。

每一步的指令、實跑看到的輸出，以及每一步沒做或換一種做法時的結果，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點在〈切換前的盤點：依賴舊規則的連線〉，救援入口在〈準備救援入口：Serial Console 與本機救援帳號〉，停用驗證在〈停用舊規則，用 IAP 驗證新規則〉，default-allow-internal 與 default-allow-icmp 的收斂在〈收斂 default-allow-internal 與 default-allow-icmp〉。

IAP 通道連不上時的依層判讀

--tunnel-through-iap 的連線失敗時，錯誤訊息與它停在哪一層對得起來：

錯誤訊息說 API 未啟用：連線停在 IAP 端點之前，專案上還沒有啟用 iap.googleapis.com。
4033（not authorized）：停在通道授權。成因是這個帳號沒有 roles/iap.tunnelResourceAccessor、IAM Conditions 不允許這個 port 或 VM、條件的期限已過，或 VM 不存在、沒有在執行；帳號實際拿不拿得到權限，以 Policy Troubleshooter 的結果為準（見〈IAP 的 IAM 授權範圍：誰拿得到通道〉）。IAM 綁定送出之後約 60 到 120 秒才生效，這段時間內的 4033 不代表條件寫錯。
4003（failed to connect to backend）：IAP 已經放行，連不到 VM 的那個 port。成因在網路可達性那一層：VM 沒帶 tag、新規則的網路或 port 寫錯、組織的階層式防火牆或 network firewall policy 先擋下（這類政策優先於專案規則，專案規則寫對了也連不上），或 VM 上的作業系統防火牆（ufw、firewalld、Windows 防火牆）與 sshd 沒有在監聽。防火牆這一段由 Connectivity Tests（gcloud network-management connectivity-tests create，來源給 IAP 位址段裡的一個 IP、目的地給這台 VM 與 port）模擬一次 IAP 到 VM 的連線，結果指出是哪一條規則或政策擋下；完整的指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈停用舊規則，用 IAP 驗證新規則〉。VM 內部的成因要從 Serial Console 進去看。
通道開了、登入時 Permission denied (publickey)：停在主機登入驗證。啟用了 OS Login 時，成因是 OS Login 的登入角色或 roles/iam.serviceAccountUser 缺了；沒啟用時，成因是 metadata 裡沒有這把公鑰或缺修改 metadata 的權限（見〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉）。

IAP 的 IAM 授權範圍：誰拿得到通道

改走 IAP 之後，VM 的連線權限改由 IAM 決定，所以 IAM policy 的寬度就是 SSH 與 RDP 的暴露面。開通道的角色 roles/iap.tunnelResourceAccessor 可以用 IAM Conditions 限定 port（destination.port == 22）、單台 VM（destination.ip == ""）或期限（request.time < timestamp("")），各種條件的完整指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈授予開通道的 IAM 權限〉。幾個地方會讓這個範圍在不知不覺中變大或對不到人：

專案層級的基本角色：Owner 這一類基本角色涵蓋開通道的權限，而且不受 IAM Conditions 限制。日常登入用的帳號拿掉基本角色、改授本篇列出的具體角色，Owner 只留給緊急時才用的帳號；團隊全員都是 Owner 時，IAM Conditions 對任何人都不生效，OS Login 的單台先行驗證也找不到非 Owner 的人來做。綁定之前先用 gcloud projects get-iam-policy 列出目前持有基本角色的成員，再用 IAM 的 Policy Troubleshooter 確認某個帳號實際拿不拿得到 iap.tunnelInstances.accessViaIAP；get-iam-policy 只列出直接綁定，群組與繼承來的權限以 Policy Troubleshooter 的結果為準。稽核要一份「所有拿得到通道的人」的清單時，用 Policy Analyzer（gcloud asset analyze-iam-policy --organization= --permissions=iap.tunnelInstances.accessViaIAP --expand-groups），--expand-groups 讓結果把 Google Group 展開成成員（預設不展開，只列到群組），要逐台列出 VM 時另加 --expand-resources；Policy Troubleshooter 一次只回答一個帳號。
整批授權：把 roles/iap.tunnelResourceAccessor 綁給 domain: 或大型群組，等於讓整個組織的帳號都能開通道。綁給負責維運的群組，並用 IAM Conditions 限定 port 與 VM。
服務帳號：CI 或自動化工具用的服務帳號若持有通道權限，它的金鑰外洩就等同一把能連進所有 VM 的鑰匙。GCP 上這類帳號用 Workload Identity Federation（Workload Identity）取得短期存取憑證，不發長期金鑰：CI 平台簽發的 OIDC token 換成服務帳號的身分，設定方式以 GCP 的 Workload Identity Federation 文件為準，與 AWS 上用 OIDC 換取 IAM role 的對照見身分與存取憑證地基 — IAM 模型、OIDC 短期憑證與權限邊界設計的〈OIDC：給 CI/CD 的短期憑證〉。服務帳號要的角色與人相同：開通道的 roles/iap.tunnelResourceAccessor，啟用 OS Login 之後另加 OS Login 的登入角色，VM 掛著服務帳號時再加那個服務帳號的 roles/iam.serviceAccountUser。
組織外的帳號：外包人員用他自己公司或個人的 Google 帳號時，OS Login 預設不讓組織外的帳號登入，要在組織層級另外授予 roles/compute.osLoginExternalUser（未實跑：測試帳號底下沒有 Organization）；組織若強制了 Organization Policy 的 iam.allowedPolicyMemberDomains（只允許組織網域的成員出現在 IAM 綁定裡），連綁定本身都會被拒絕；2024 年 5 月 3 日之後建立的 Organization 預設就強制這一條，用〈組織層級的護欄：Organization Policy 與階層式防火牆〉的 org-policies list 確認。這類帳號也不受組織的兩步驟驗證強制管轄，所以替外包人員在組織的 Cloud Identity 建帳號，比授權給外部帳號更容易控制，合約到期時停用帳號、或用帶 request.time 的條件讓綁定自動失效。

通道授權改用 Google 帳號之後，帳號被釣魚，攻擊者就能從 IAP 開通道。GCP 上的對應設定是在 Google Workspace 或 Cloud Identity 對能開通道的帳號強制兩步驟驗證，管理員帳號用硬體安全金鑰或 passkey 這類防釣魚的方式——一次性驗證碼會在釣魚頁面上被一起騙走。gcloud 登入之後會在本機保存 refresh token，管理員帳號停用前這份 token 一直可用，而 token 檔可以被複製；Workspace 與 Cloud Identity 的管理控制台有 Google Cloud 工作階段控制，設定多久要重新驗證一次（1 到 24 小時）；這項設定預設關閉，啟用之後這個間隔才是本機 token 被複製之後能用多久的上限，被設成受信任而豁免的應用程式不受它限制。需要再收緊時，Context-Aware Access 可以在 IAM 綁定上加 access level 條件（Access Context Manager 定義的一組連線條件，例如只允許公司管理的裝置或特定網段）。

人員異動時，移出群組或移除 IAM 綁定只擋下下一次開通道；已經開著的工作階段要另外在 VM 上結束，做法見〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉最後結束工作階段的那兩段。

GCP 上把 SSH 公鑰交給 Linux VM 有兩種方式，分別對應伺服器管理通道的設計〈主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回〉裡的靜態公鑰與由中央服務決定的公鑰：metadata 金鑰寫在專案或 VM 的 metadata（設在專案或 VM 上的鍵值設定）裡，由 VM 上的 guest agent（GCP 映像檔內建、把 metadata 同步進 VM 的常駐程式）寫進 authorized_keys；OS Login 依 Google 帳號與 IAM role 決定誰能登入、能不能用 sudo。寫在專案 metadata 的公鑰對專案內每一台沒有啟用 OS Login 的 VM 都生效，成員離職時漏刪一把，那把金鑰就持續能登入整個專案，而沒啟用 OS Login 時 gcloud compute ssh 預設就是把公鑰寫進專案 metadata。兩者的機制與差別見 OS Login 卡。Oracle Cloud 與 AWS 上不放金鑰時由哪些服務登入、各自包辦管理通道的哪幾層，見登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務的〈不放金鑰時的登入服務〉。

啟用 OS Login（metadata 的 enable-oslogin=TRUE）之後，VM 不再接受 metadata 裡的金鑰，原本靠 metadata 金鑰登入的管理員與自動化工具會立刻連不進去。啟用的順序因此由三個條件決定：

角色先授：每一位管理員與每一個要登入 VM 的服務帳號先拿到登入角色（roles/compute.osLogin 一般登入，roles/compute.osAdminLogin 含 sudo）；VM 掛著服務帳號時（gcloud compute instances describe 輸出的 serviceAccounts 欄不是空的，用 Google Cloud 控制台以預設值建立的 VM 會掛上 Compute Engine 預設服務帳號），每一個登入者另外需要那個服務帳號的 roles/iam.serviceAccountUser。
單台先行：先在單一 VM 上啟用，讓角色漏授這類錯誤只鎖住那一台；驗證要由非 Owner 的管理員做，Owner 本身持有全部權限，只由 Owner 驗證會看不出漏授。
VM 層級蓋過專案層級：專案層級啟用之後，VM 層級設了 enable-oslogin=FALSE 的 VM 仍然讀 metadata 金鑰；專案 metadata 的 ssh-keys 留著前任與現任成員的公鑰，OS Login 一旦還原成 FALSE 它們就又能用，所以全部 VM 都啟用之後要清掉。

啟用、還原、列出 FALSE 的 VM 與清除 ssh-keys 的指令，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈啟用 OS Login：先授角色、單台先行、再做專案層級〉。OS Login 只作用在 Linux VM，Windows VM 的登入仍由 Windows 帳號決定。OS Login 也可以要求登入時的兩步驟驗證（metadata 設 enable-oslogin-2fa=TRUE），讓每一次 SSH 登入都多一次 Google 帳號的第二因素；沒有啟用兩步驟驗證的帳號會登不進去，所以同樣先對單一 VM 設定驗證。OS Login 文件寫明這項要求不套用在服務帳號上，CI 這類登入者不受它約束。

帳號停用或角色移除之後，下一次登入就會失敗；已經建立的工作階段不受影響，所以處理離職或帳號外洩時，管理員要另外登入 VM 結束那個使用者的工作階段。在 systemd 的發行版上：

1# 結束 systemd-logind 登記過的工作階段
2sudo loginctl terminate-user 
3
4# 確認那個使用者的行程已經全部結束；有輸出就代表還有行程在跑
5pgrep -u  -a
6
7# 還有剩下的行程時，直接結束
8sudo pkill -KILL -u

是 OS Login 由 Google 帳號轉成的使用者名稱，例如 alice_example_com。確認的依據是 pgrep 的輸出，而不是 terminate-user 的回傳值：loginctl 只結束 systemd-logind 登記過的工作階段，登入時 pam_systemd 登記失敗的工作階段（VM 的日誌裡有 pam_systemd(sshd:session): Failed to create session）不在它的清單裡，這時 loginctl terminate-user 會回報使用者沒有登入，而行程仍在執行。Windows VM 上用 query session 找出那個使用者的 RDP 工作階段，再用 logoff 結束。

拿掉外部 IP 之後的出站路徑：Cloud NAT 與 Private Google Access

Cloud NAT 承接沒有外部 IP 的 VM 往外的連線，apt update、docker pull、呼叫第三方 API 都靠它；它和 AWS 的 NAT Gateway 承擔同一件事，機制見 NAT。Cloud NAT 建在 Cloud Router（GCP 管理 VPC 路由的元件）上，以 region 為單位生效，VM 分布在幾個 region 就要各建一組；出站 IP 可以讓 GCP 自動配發（可能變動），或改用預留的靜態 IP（外部服務要求來源 IP 白名單時）。VM 要存取 Cloud Storage、Artifact Registry 這類 Google API 時，subnet 開啟 Private Google Access，就能用內部 IP 連到 Google API，不經過 Cloud NAT，也就不產生 NAT 的資料處理費。

拿掉外部 IP 的判斷有兩點：

哪些 VM 可以拿：對外提供服務的 VM（網站、API）移除外部 IP 之前，要先把流量入口換到負載平衡器，否則移除的當下服務就中斷，入口層的設計見流量入口層 — 請求怎麼從使用者到達應用。只做管理用途的 VM 可以直接移除。
驗證要在移除之後做：網卡還帶著外部 IP 時，Cloud NAT 不處理這張網卡的出站流量，流量走的是 VM 自己的外部 IP，所以移除之前測出站一定是通的，證明不了 Cloud NAT 有效。移除之後在 VM 上看出站的來源 IP，判斷依據是那個 IP 在不在 Cloud NAT 的 IP 清單（gcloud compute routers get-nat-ip-info）裡，而不是移除前後的 IP 有沒有變：自動配發的 Cloud NAT 可能正好配到這台 VM 剛釋放的那個外部 IP。

建 Cloud NAT、開 Private Google Access、查 access config 名稱與移除外部 IP、驗證出站的指令與實跑結果，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈建 Cloud NAT 並移除外部 IP〉。移除之後，這台 VM 只剩 IAP 一條管理路徑，連線一律加 --tunnel-through-iap。

組織層級的護欄：Organization Policy 與階層式防火牆

default 網路與 default-allow-ssh、default-allow-rdp 這些預設規則，每個新建的專案都會重新長出來，所以單一專案的收斂只保護那一個專案。要讓組織裡的新專案不再帶著這些規則，在 Organization Policy 設定下面幾個 constraint。這一節的指令需要專案屬於一個 Organization 資源，執行者要有組織層級的權限（roles/orgpolicy.policyAdmin 與 roles/compute.orgFirewallPolicyAdmin）；這一節的指令沒有實跑（測試帳號底下沒有 Organization）。2024 年 5 月 3 日之後建立的 Organization 會預設強制一組 constraint，先用 gcloud resource-manager org-policies list --organization= 看哪些已經生效。

compute.skipDefaultNetworkCreation：新專案不再自動建立 default 網路。
compute.vmExternalIpAccess：只允許列在清單上的 VM 持有外部 IP，其餘 VM 建立時帶外部 IP 會被拒絕。
compute.requireOsLogin：新建的專案與 VM 啟用 OS Login，任何層級都無法用 metadata 把它關掉；既有 VM 是否已啟用要另外盤點，而既有的管理員要先拿到 OS Login 的登入角色。
compute.disableSerialPortAccess：關閉 Serial Console 的存取，讓救援入口平時保持關閉；救援時由持有組織政策權限的人對那個專案解除，救援結束後恢復。

 1# 在組織層級強制布林型的 constraint（skipDefaultNetworkCreation、requireOsLogin、disableSerialPortAccess 同一種寫法）
 2gcloud resource-manager org-policies enable-enforce compute.skipDefaultNetworkCreation \
 3  --organization=
 4
 5# 救援時，對單一專案解除 Serial Console 的限制
 6gcloud resource-manager org-policies disable-enforce compute.disableSerialPortAccess \
 7  --project=
 8
 9# 救援結束後，刪掉專案層級的例外，讓專案重新繼承組織層級的強制
10gcloud resource-manager org-policies delete compute.disableSerialPortAccess \
11  --project=

用 gcloud organizations list 查。compute.vmExternalIpAccess 是清單型的 constraint，要用政策檔列出允許的 VM，寫法以 Organization Policy 文件為準。

階層式防火牆政策（hierarchical firewall policy）套用在組織或資料夾上，優先於專案的 VPC 防火牆規則評估。政策裡的規則依 priority 數字由小到大評估，命中 allow 或 deny 就停止，專案的規則不會再被看到；命中 goto_next 則把這條連線交給下一層（最終是專案的 VPC 規則）判斷。所以規則的相對 priority 決定結果：

交給專案判斷的 IAP 規則（來源 35.235.240.0/20，有 IPv6 VM 時加上 2600:2d00:1:7::/64；tcp:22 與 tcp:3389；動作 goto_next）priority 要比拒絕規則小，否則 IAP 的流量先被拒絕規則擋下。它用 goto_next 而不用 allow：allow 會讓 IAP 的位址段直接通到組織內每一台 VM，繞過專案用 target tag 做的收斂。
VM 之間或從 VPN 進來的 SSH 需要保留時，它們的來源（內部網段、VPN 的位址段）同樣要有一條 priority 比拒絕規則小的 goto_next 規則，因為拒絕規則的 0.0.0.0/0 也涵蓋內部位址。
拒絕 0.0.0.0/0 連到 tcp:22 與 tcp:3389 的規則只涵蓋 IPv4，IPv6 要另寫一條拒絕 ::/0 的規則，這兩條拒絕規則之間沒有先後依賴。

 1# 建立組織層級的防火牆政策，加入規則，再關聯到一個資料夾（之後再關聯到組織）
 2gcloud compute firewall-policies create --short-name= --organization=
 3
 4gcloud compute firewall-policies rules create 100 --firewall-policy= \
 5  --organization= --direction=INGRESS --action=goto_next \
 6  --src-ip-ranges=35.235.240.0/20 --layer4-configs=tcp:22,tcp:3389
 7
 8gcloud compute firewall-policies rules create 1000 --firewall-policy= \
 9  --organization= --direction=INGRESS --action=deny \
10  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22,tcp:3389
11
12gcloud compute firewall-policies associations create --firewall-policy= \
13  --organization= --folder=

100、1000 是規則的 priority，只要 goto_next 那幾條比拒絕規則小就行，中間留空號給之後要插入的規則。是自己取的政策名稱。--folder= 把政策關聯到一個資料夾；組織與資料夾層級的政策影響其下每一個專案，先關聯到一個測試用的資料夾，確認既有服務沒有依賴被擋掉的路徑，再關聯到組織（拿掉 --folder）。

稽核與偵測：firewall log、Cloud Audit Logs 與 Security Command Center

伺服器管理通道的設計〈組織層級的護欄與稽核紀錄〉列出事後要查的三項事件，在 GCP 上分別從這幾個來源查：

誰在什麼時候經由哪條通道登入了哪台 VM：開通道的帳號與目標 VM 記在 Cloud Audit Logs 裡 IAP 的 Data Access 紀錄，要為 Cloud Identity-Aware Proxy 開啟「管理員讀取」（ADMIN_READ）類型才有：開通道時 IAP 檢查的權限 iap.tunnelInstances.accessViaIAP 歸在這個類型，只開「資料讀取」（DATA_READ）時，實測連了十次左右，開通道的紀錄一筆都沒有。開啟之後經由 IAP 連一次、查到方法名稱為 AuthorizeUser 的紀錄才算開對，查詢指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄的〈啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則〉。登入 VM 的帳號記在 VM 上的 sshd 紀錄，啟用 OS Login 時是由 Google 帳號轉成的使用者名稱。啟用 OS Login 時，每一次登入另外在 Cloud Audit Logs 留下 OS Login 檢查登入權限的 Data Access 紀錄，記著 Google 帳號與目標 VM，而且存在 VM 之外，取得 VM root 的人清不掉：
```
1# 列出最近七天每一次 OS Login 的時間、Google 帳號與目標 VM；--freshness 依調查範圍調整
2gcloud logging read 'protoPayload.serviceName="oslogin.googleapis.com" AND protoPayload.methodName:"CheckPolicy"' \
3  --freshness=7d --format="value(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName)"
```
實測的專案沒有為 Cloud OS Login API 另外開啟 Data Access 紀錄，CheckPolicy 的紀錄仍然寫進了 data_access 這個紀錄檔；查不到時，到「IAM 與管理 > 稽核記錄」確認 Cloud OS Login API 的 Data Access 設定，並用 gcloud projects get-iam-policy --format="json(auditConfigs)" 看專案層有沒有排除它。firewall rules logging 記錄每一次放行的來源 IP、目的 VM、port 與命中的規則名稱，經由 IAP 的連線來源都是 IAP 的位址段，從這份紀錄看不出是哪個人。
誰在什麼時候開了救援入口：開啟 Serial Console 的 metadata 修改與組織政策的解除屬於 Admin Activity 紀錄，預設就有。
環境裡是否出現新的對外開放管理 port：Security Command Center 的 Security Health Analytics 持續掃描組織內的防火牆規則，OPEN_SSH_PORT 與 OPEN_RDP_PORT 這兩類 finding 對應的就是對外開放 22 與 3389 的規則。處理方式是照〈切換到 IAP 的順序〉把規則換掉（逐步指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄），直接刪除會中斷管理員自己的連線；規則刪除或縮小來源之後，下一次掃描會把對應的 finding 標為已解決。

事件發生時才發現 IAP 的 Data Access 紀錄沒開，開啟之前的通道紀錄查不回來，剩下的來源是 Admin Activity 紀錄裡 metadata 與 IAM 的變更，以及 VM 上的 sshd 紀錄；sshd 紀錄只存在 VM 本機，取得 root 的攻擊者可以清掉，所以要保全時先把 VM 的磁碟做快照，證據的保全與分流見 8.18 Incident Intake & Evidence Triage。

AWS 上同類的盤點流程見 Security Group 稽核與清理：兩邊都是先列出來源是 0.0.0.0/0 的規則，逐條確認有沒有服務依賴，再刪除或縮小來源。

ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑

Mon, 26 Oct 2026 00:00:00 +0800

事件說明：2026-10-26，在本機 macOS 的 OrbStack 2.2.5 建的一台 Ubuntu 24.04.5 機器上實測（Arm 架構，核心是 OrbStack 自己的 7.2.12-orbstack，有 systemd、可以重開機）。ufw 0.36.2，iptables 1.8.10（nf_tables 後端），Docker CE 29.9.2 從 Docker 官方的 apt 套件庫安裝，測試容器是 busybox:1.37。機器的 DNS 解析器是 OrbStack 提供的 0.250.250.200。

這篇記錄在一台用 ufw 的 Ubuntu 主機上，Docker 發佈的連接埠跟 ufw 規則之間的關係：用兩個 network namespace 模擬位址在 Cloudflare 範圍內與範圍外的來源、ufw 的入站規則與 route 規則對發佈連接埠的效果、FORWARD 鏈裡 Docker 與 ufw 的跳轉順序、DOCKER-USER 規則在 ufw reload、ufw 關閉再開啟、Docker 重啟與重開機之後還在不在、寫進 /etc/ufw/after.rules 讓規則開機時載入的做法與這個檔案對非 ASCII 字元的限制、-p 發佈在 IPv6 的那一份由 docker-proxy 接收而受 ufw 入站規則管、compose 自訂網路的容器經由 Docker 內建解析器 127.0.0.11 查詢時封包由主機送出，以及清理。為什麼要只放行 CDN 的位址、各種限制寫法的取捨，寫在概念文章 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖；firewalld 主機上的同一組實測在源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS，Podman 與 rootless Docker 在 Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址。

前置條件：Ubuntu 主機、ufw 與 Docker

一台有 systemd、可以重開機的 Ubuntu 主機，有 sudo：雲端 VM、本機 VM 或 OrbStack、Multipass 這類工具建的機器都行。Oracle Cloud 的 Ubuntu 平台映像例外：Oracle 的〈Images〉寫明不要在上面用 ufw 改規則，可能讓主機開不了機，見網路：subnet、私有 IP、公開 IP 與防火牆規則的〈防火牆規則的位置與合併方式〉。這次用 OrbStack 是因為免費、建與刪都在一分鐘內，代價是核心是 OrbStack 自己編的版本、不是 Ubuntu 的映像核心；下文量到的是 iptables、ufw 與 Docker 的行為，它們在 Ubuntu 的映像核心上的差異沒有比較。建法是 orb create ubuntu:noble verify-ufw，之後用 orb -m verify-ufw sudo bash 進 root shell。
登入路徑跟要測的連接埠分開：測試只動 8080、8081 與 IPv6 的 8081。用 SSH 登入雲端主機時，啟用 ufw 之前先 ufw allow 22/tcp（或只放行自己的位址），否則 ufw enable 之後連線會斷；OrbStack 經由自己的通道進機器，不受 ufw 影響。

ufw 與 Docker：

1apt-get update
2apt-get install -y ufw iproute2 iptables conntrack dnsutils curl
3# Docker 官方的 apt 套件庫，步驟見 docs.docker.com 的〈Install Docker Engine on Ubuntu〉
4apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
5docker pull busybox:1.37

docker-ce 帶 systemd 的 unit，裝好就由 systemd 執行並設成開機啟動。Ubuntu 自己的 docker.io 套件版本較舊，Docker 寫防火牆規則的方式依版本而變（28.0.0 改過發佈在 127.0.0.1 的連接埠對同網段主機的可達性），沒有比較。

暫存目錄用 verify- 開頭，放在 /var/tmp：這台機器的 /tmp 是 tmpfs（findmnt /tmp 的 FSTYPE 欄是 tmpfs），重開機就清空；/var/tmp 在磁碟上，重開機後還在。這次第一輪把網頁檔放在 /tmp/verify-fw/www，重開機之後容器自動重新啟動時，Docker 發現 bind mount 的來源目錄不存在，替它建了一個空目錄，httpd 找不到 index.html 而回 404。

共用的函式與兩個測試來源

下文的指令都在同一個 root shell 裡跑。ns_setup 建兩個 network namespace：verify-cf 的位址 173.245.48.10 落在 Cloudflare 的 173.245.48.0/20，verify-other 的 203.0.113.10 是文件保留位址、不在任何 Cloudflare 範圍。兩者各用一對 veth 接到主機，對主機的 IP 發連線，封包從主機的 veth 介面進來，經過的防火牆路徑跟從網卡進來的相同。probe <連接埠> 讓兩個來源各連一次。

 1HOSTIP=$(ip -4 -br a show eth0 | awk '{print $3}' | cut -d/ -f1)   # 主機主要網卡的位址；網卡名不是 eth0 時換掉
 2ns_setup() {
 3  ip netns add verify-cf; ip netns add verify-other
 4  ip link add vcf-h type veth peer name vcf-n netns verify-cf
 5  ip link add voth-h type veth peer name voth-n netns verify-other
 6  ip addr add 192.0.2.1/32 dev vcf-h; ip link set vcf-h up
 7  ip addr add 192.0.2.5/32 dev voth-h; ip link set voth-h up
 8  ip route add 173.245.48.10/32 dev vcf-h; ip route add 203.0.113.10/32 dev voth-h
 9  ip -n verify-cf addr add 173.245.48.10/32 dev vcf-n; ip -n verify-cf link set vcf-n up; ip -n verify-cf link set lo up
10  ip -n verify-cf route add 192.0.2.1/32 dev vcf-n; ip -n verify-cf route add default via 192.0.2.1 dev vcf-n
11  ip -n verify-other addr add 203.0.113.10/32 dev voth-n; ip -n verify-other link set voth-n up; ip -n verify-other link set lo up
12  ip -n verify-other route add 192.0.2.5/32 dev voth-n; ip -n verify-other route add default via 192.0.2.5 dev voth-n
13}
14probe() {  # probe <連接埠>：兩個來源各連一次 http://$HOSTIP:<連接埠>/，5 秒逾時
15  for ns in verify-cf verify-other; do
16    out=$(ip netns exec $ns curl -sS -m 5 -o /dev/null -w '%{http_code}' http://$HOSTIP:$1/ 2>&1); rc=$?
17    printf '  %-13s -> :%s  rc=%s  %s\n' "$ns" "$1" "$rc" "$(echo "$out" | tail -1)"
18  done
19}
20ns_setup
21sysctl -w net.ipv4.ip_forward=1

192.0.2.1 與 192.0.2.5 是主機這一端的位址，只當兩個 namespace 的閘道。namespace 連主機本身的程式（8080）屬於主機自己接收，不需要轉送；連 Docker 發佈的連接埠時，封包被改寫成容器位址之後要由主機轉送到容器網路，ip_forward=1 管的是這一段，Docker 啟動時也會把它設成 1。probe 的輸出有三種讀法：rc=0 200 是連上並拿到回應；rc=7 是主機立即回拒；rc=28 000 是封包被丟棄、5 秒內沒有回應。namespace 與 veth 在重開機之後消失，HOSTIP 與兩個函式只存在這個 shell 裡：重開機或換一個 shell 之後，重新貼一次上面整個區塊（它會重新定義函式並重建 namespace）。

量 IPv6 的那幾節另外替兩個來源各加一個 IPv6 位址，並在主機的 lo 上加一個測試用的 IPv6 位址（ULA，fd00::/8 裡只在本地使用的位址）當連線目標。verify-cf 用 Cloudflare 2606:4700::/32 裡的 2606:4700::10，verify-other 用文件保留的 2001:db8::10：

 1HOST6=fd00:beef::1
 2ns_setup6() {
 3  ip -6 addr add $HOST6/128 dev lo
 4  ip -n verify-cf addr add 2606:4700::10/128 dev vcf-n; ip -n verify-other addr add 2001:db8::10/128 dev voth-n
 5  sleep 3                                                    # 等 veth 的 link-local 位址生效
 6  ip -6 route add 2606:4700::10/128 dev vcf-h; ip -6 route add 2001:db8::10/128 dev voth-h
 7  ip -n verify-cf -6 route add default via $(ip -6 -br a show vcf-h | grep -o 'fe80::[^/]*') dev vcf-n
 8  ip -n verify-other -6 route add default via $(ip -6 -br a show voth-h | grep -o 'fe80::[^/]*') dev voth-n
 9}
10probe6() {  # probe6 <連接埠>：兩個來源各經由 IPv6 連一次 http://[$HOST6]:<連接埠>/
11  for ns in verify-cf verify-other; do
12    out=$(ip netns exec $ns curl -sS -m 5 -o /dev/null -w '%{http_code}' "http://[$HOST6]:$1/" 2>&1); rc=$?
13    printf '  %-13s -> [%s]:%s  rc=%s  %s\n' "$ns" "$HOST6" "$1" "$rc" "$(echo "$out" | tail -1)"
14  done
15}
16ns_setup6

兩個 namespace 的預設路由指向主機那一端 veth 的 link-local 位址（fe80:: 開頭，介面啟用後幾秒才生效）。重開機之後 ns_setup 與 ns_setup6 都要重跑。

主機上聽 8080 的程式代表直接跑在主機上的網站，聽 8081 的容器代表 Docker 發佈的網站：

1mkdir -p /var/tmp/verify-fw/www; echo ok > /var/tmp/verify-fw/www/index.html
2python3 -m http.server 8080 --directory /var/tmp/verify-fw/www >/var/tmp/verify-fw/http8080.log 2>&1 &
3docker run -d --name verify-web --restart unless-stopped -p 8081:80 \
4  -v /var/tmp/verify-fw/www:/www:ro busybox:1.37 httpd -f -p 80 -h /www

--restart unless-stopped 讓容器在 Docker 重啟與重開機之後自己起來，重開機那幾步要靠它。

ufw 的入站規則與 route 規則對發佈連接埠的效果

ufw 預設拒絕入站，只放行 Cloudflare 的一段到 8080 與 8081：

1ufw default deny incoming; ufw default allow outgoing
2ufw allow from 173.245.48.0/20 to any port 8080 proto tcp
3ufw allow from 173.245.48.0/20 to any port 8081 proto tcp
4ufw --force enable
5ufw status verbose
6probe 8080; probe 8081
7iptables -S FORWARD | grep -- '-j'

 1Default: deny (incoming), allow (outgoing), deny (routed)
 28080/tcp                   ALLOW IN    173.245.48.0/20
 38081/tcp                   ALLOW IN    173.245.48.0/20
 4  verify-cf     -> :8080  rc=0  200
 5  verify-other  -> :8080  rc=28  000
 6  verify-cf     -> :8081  rc=0  200
 7  verify-other  -> :8081  rc=0  200
 8-A FORWARD -j DOCKER-USER
 9-A FORWARD -j DOCKER-FORWARD
10-A FORWARD -j ufw-before-logging-forward
11-A FORWARD -j ufw-before-forward
12-A FORWARD -j ufw-after-forward
13-A FORWARD -j ufw-after-logging-forward
14-A FORWARD -j ufw-reject-forward
15-A FORWARD -j ufw-track-forward

主機上的 8080 只有 Cloudflare 那一段連得到，範圍外的來源被丟棄（逾時）：ufw 的入站規則管的是 input 路徑，也就是目的地是主機本身程式的封包。容器的 8081 兩個來源都連得到：Docker 在封包剛進主機時把目的地改寫成容器（DNAT），封包變成要由主機轉出到另一個介面的轉送路徑，不經過 ufw 的入站規則。兩條路徑的分岔與各自的限制寫法，在概念文章 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖的〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。ufw status 列的 8081 規則對它沒有作用。

轉送路徑上 ufw 也有規則：ufw route 寫的規則放在 ufw-user-forward，封包經過 ufw-before-forward 時跳轉（jump）進這條鏈比對，而預設的 deny (routed) 是 FORWARD 鏈的預設政策 DROP。試著用 route 規則擋 8081 與容器的 80：

1ufw route deny proto tcp from any to any port 80
2ufw route deny proto tcp from any to any port 8081
3ufw reload
4probe 8081

1  verify-cf     -> :8081  rc=0  200
2  verify-other  -> :8081  rc=0  200

兩條 route 規則都沒有效果。原因在上面那份跳轉順序：FORWARD 鏈開頭是 Docker 的 DOCKER-USER 與 DOCKER-FORWARD，DOCKER-FORWARD 接受送往發佈連接埠的連線，封包在跳到任何 ufw-* 鏈之前就被接受，ufw 的 route 規則與 FORWARD 的預設 DROP 都輪不到它。測完刪掉這兩條：

1ufw route delete deny proto tcp from any to any port 80
2ufw route delete deny proto tcp from any to any port 8081

刪除的語法是 ufw route delete <規則>；寫成 ufw delete route deny … 時 ufw 回 ERROR: Invalid syntax、規則沒有刪掉。

DOCKER-USER 規則的效果，以及它在 ufw reload、Docker 重啟與重開機之後的存續

DOCKER-USER 排在 FORWARD 鏈最前面，裡面的規則由使用者寫。封包到這裡時目的地已經改成容器的 80，所以比對 conntrack（連線追蹤）記下的原始目的連接埠 8081：

1iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP
2probe 8081

1  verify-cf     -> :8081  rc=0  200
2  verify-other  -> :8081  rc=28  000

範圍外的來源被擋下，DROP 讓它等到逾時；換成 -j REJECT 時它會立即收到回拒，這次沒有比較。

這條規則只比對連接埠與來源，發佈的連接埠是 8081 時沒有副作用；換成正式的 80 與 443 時，容器自己往外連 443（呼叫外部 API、ACME 取憑證）的封包，與同一台主機上容器之間連 80 的封包，也會經過 DOCKER-USER，原始目的連接埠同樣是 443 或 80，來源是容器位址、不在清單裡，一起被丟掉。補測時把同樣寫法的規則套在 443、80、8081 上，一個 busybox 容器 wget https://www.cloudflare.com/ 與連另一個容器的 80 都以非零結束（出站那一次的訊息是 download timed out）；三條規則都加上 -m conntrack --ctstate DNAT（只比對經過位址轉換的連線，也就是送往發佈連接埠的那些）之後，兩者恢復，範圍外的來源連 8081 仍然逾時：

1iptables -I DOCKER-USER -p tcp -m conntrack --ctstate DNAT --ctorigdstport 443 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP

另一種限定法是加 -i <對外的網卡>，只比對從外面進來的封包，補測時同樣讓容器的出站恢復；這次的測試來源從 veth 進來，-i eth0 時範圍外的來源是否仍被擋，沒有量到。下文的規則以 8081 實測，正式設定換成 80、443 時都加 --ctstate DNAT。這裡只放行 Cloudflare 的一段，正式設定時對整份清單各寫一條 -s … -j RETURN 的自建鏈，寫法在源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS 的〈DOCKER-USER 鏈的限制效果與規則的存續〉。接著依序做四個會重建防火牆規則的動作，每做完一個就看一次規則與結果：

1ufw reload;                    iptables -S DOCKER-USER; probe 8081
2ufw disable; ufw --force enable; iptables -S DOCKER-USER; probe 8081
3systemctl restart docker;      iptables -S DOCKER-USER; probe 8081
4reboot                         # OrbStack 在本機跑 orb restart verify-ufw；開機後重新貼〈共用的函式與兩個測試來源〉的區塊
5iptables -S DOCKER-USER; probe 8081

動作	`DOCKER-USER` 裡的規則	範圍外的來源連 8081
`ufw reload`	還在	逾時
`ufw disable` 再 enable	還在	逾時
`systemctl restart docker`	還在	逾時
重開機	不在（只剩空的鏈）	200

ufw 重新載入時只重建自己的 ufw-* 鏈，不碰 Docker 的鏈；Docker 重啟時保留 DOCKER-USER 的內容。iptables 指令加的規則只存在執行中的核心裡，重開機之後就不在，範圍外的來源又連得到。重開機那一列實測用的是 orb restart verify-ufw。

讓規則開機時載入：寫進 /etc/ufw/after.rules

ufw 啟動時會依序套用 /etc/ufw/before.rules、使用者規則與 /etc/ufw/after.rules，三個檔案是 iptables-restore 的格式。在 after.rules 結尾加一段 *filter 區塊，宣告 DOCKER-USER 鏈並寫規則，ufw 每次啟動與重新載入時都會寫入這條規則：

 1cp /etc/ufw/after.rules /var/tmp/verify-fw/after.rules.orig
 2cat >> /etc/ufw/after.rules <<'EOF'
 3
 4# verify-ufw: published 8081 only from one Cloudflare range
 5*filter
 6:DOCKER-USER - [0:0]
 7-A DOCKER-USER -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP
 8COMMIT
 9EOF
10iptables -F DOCKER-USER     # 沒有做〈DOCKER-USER 規則的效果…〉那一節的重開機時，清掉手動加的那一條；宣告這條鏈本身也會清空它，這一行可以省略
11ufw reload
12iptables -S DOCKER-USER; probe 8081

ufw reload 之後規則在、範圍外的來源逾時；systemctl restart docker 之後也一樣。

:DOCKER-USER - [0:0] 這一行宣告這條鏈：鏈不存在時建出來（ufw 開機時比 Docker 先啟動，這時鏈還不存在），鏈已經存在時（Docker 建好的）清空它的內容，再寫入檔案裡的規則。所以上面的 iptables -F 可以省略。宣告會清空這條鏈，帶來一個副作用，另外量過一次：先用 iptables -I 在 DOCKER-USER 加一條別的規則，再寫進這段、ufw reload，那一條就不在了，鏈裡只剩 after.rules 寫的。所以同一台主機上用 after.rules 時，DOCKER-USER 的其他規則（包括下文 DNS 那一節用 iptables -I 加的）也要寫進同一段，否則下一次 ufw reload 就被清掉。

反方向也量過：從 after.rules 刪掉這一段再 ufw reload，鏈裡的規則還在（ufw 不再宣告這條鏈，就不動它），要再 iptables -D 或重開機才消失（依 iptables 規則只存在執行中的核心推論，iptables -D 與重開機這兩項沒有量）。

重開機之後（OrbStack 用 orb restart verify-ufw，雲端主機用 reboot），重新貼〈共用的函式與兩個測試來源〉的區塊，再看：

1iptables -S DOCKER-USER; iptables -S FORWARD | grep -- '-j' | head -2
2probe 8081
3systemctl show -p ActiveEnterTimestampMonotonic ufw docker

1-N DOCKER-USER
2-A DOCKER-USER ! -s 173.245.48.0/20 -p tcp -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL -j DROP
3-A FORWARD -j DOCKER-USER
4-A FORWARD -j DOCKER-FORWARD
5  verify-cf     -> :8081  rc=0  404
6  verify-other  -> :8081  rc=28  000
7ActiveEnterTimestampMonotonic=86988488358
8ActiveEnterTimestampMonotonic=86990212381

規則在，範圍外的來源被擋。兩個時間戳是 ufw 與 docker 兩個 unit 進入 active 的時間（開機後的微秒數），ufw 先、Docker 後：開機時 ufw 先建出 DOCKER-USER 並寫入規則，Docker 啟動時沿用這條已經存在的鏈、不清它的內容，再把兩條跳轉插到 FORWARD 最前面。範圍內的來源回 404 是實測時網頁目錄放在 /tmp、重開機後變成空的（〈前置條件〉的暫存目錄那一項），連線本身送到了容器；下面整份清單那一次放在 /var/tmp，重開機之後是 200。

整份 Cloudflare 清單：IPv4 寫進 after.rules、IPv6 用 ufw 的入站規則

上面那段只放行一個位址段。正式設定時，IPv4 那一份（走轉送路徑）把整份清單寫成一條自建鏈放進 after.rules；IPv6 那一份由 docker-proxy 接收、走 input 路徑（見〈IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果〉），用 ufw 的入站規則對每一段放行。先把上面那段從 after.rules 拿掉（cp /var/tmp/verify-fw/after.rules.orig /etc/ufw/after.rules），再：

 1D=/var/tmp/verify-fw
 2curl -sSf https://www.cloudflare.com/ips-v4 -o $D/ips-v4
 3curl -sSf https://www.cloudflare.com/ips-v6 -o $D/ips-v6
 4{
 5  echo
 6  echo '# verify-ufw: Docker published port 8081, Cloudflare IPv4 ranges only'
 7  echo '*filter'
 8  echo ':DOCKER-USER - [0:0]'
 9  echo ':CF-ONLY - [0:0]'
10  while read -r n || [ -n "$n" ]; do [ -n "$n" ] && echo "-A CF-ONLY -s $n -j RETURN"; done < $D/ips-v4
11  echo '-A CF-ONLY -j DROP'
12  echo '-A DOCKER-USER -p tcp -m conntrack --ctstate DNAT --ctorigdstport 8081 --ctdir ORIGINAL -j CF-ONLY'
13  echo 'COMMIT'
14} >> /etc/ufw/after.rules
15ufw reload
16while read -r n || [ -n "$n" ]; do [ -n "$n" ] && ufw allow proto tcp from "$n" to any port 8081 >/dev/null; done < $D/ips-v6
17grep -c . $D/ips-v4; iptables -S CF-ONLY | grep -c RETURN
18grep -c . $D/ips-v6; ufw status | grep '8081.*ALLOW' | grep -c '::'
19probe 8081

115
215
37
47
5  verify-cf     -> :8081  rc=0  200
6  verify-other  -> :8081  rc=28  000

封包進到 DOCKER-USER、連線經過位址轉換而原始目的連接埠是 8081 時跳到 CF-ONLY（實測那一次的跳轉沒有 --ctstate DNAT，加上它的效果是〈DOCKER-USER 規則的效果…〉量的那一組）：來源落在清單的任一段就 RETURN 回 DOCKER-USER，接著由 Docker 的 DOCKER-FORWARD 放行；全部不符時落到最後的 DROP。8081 換成自己發佈的連接埠，每個連接埠在 DOCKER-USER 寫一行跳轉、在 ufw 寫一組放行。

兩組計數要對得上：grep -c . 數清單的段數，另一個數實際寫進去的規則數。實測那一次是在一台新開的 ufw 上量，ufw 裡只有 IPv6 的那 7 條放行，計數用的是 ufw status | grep -c '8081.*ALLOW'；照本文從前面幾節做下來時，ufw 裡還有一條 IPv4 的 173.245.48.0/20 放行，上面的區塊因此只數來源帶 :: 的那幾條，這個寫法沒有照這個形式跑過。CF-ONLY 那一行只數 RETURN，鏈裡另外還有最後一條 DROP。Cloudflare 這兩份清單的最後一行沒有換行字元，while read -r n 單獨寫時讀不到最後一行、也不報錯，第一次實測時 IPv4 少了 131.0.72.0/22、IPv6 少了 2c0f:f248::/32，被漏掉的位址段回源時會被擋下；|| [ -n "$n" ] 讓迴圈也處理沒有換行結尾的最後一行。

用〈共用的函式與兩個測試來源〉的 ns_setup6 加好 IPv6 位址之後，probe6 8081 也只有 verify-cf 拿到 200。重開機之後重新貼函式的區塊再量一次，IPv4 的 15 條 RETURN 還在，probe 8081 與 probe6 8081 的結果都跟上面相同（IPv6 那一份量的是連線結果，沒有再數規則）。Cloudflare 的清單更新時，重抓兩份清單、把 after.rules 裡這一段換成新產生的內容再 ufw reload，IPv6 那一份另外用 ufw delete 刪掉不在新清單裡的段；這個更新流程沒有實跑。

after.rules 裡的非 ASCII 字元，會讓 ufw 在重寫規則檔時中止。第一次寫進去的註解是「# verify-ufw：Docker 發佈的 8081 …」，ufw reload 照常，而改預設政策時失敗。下面的指令是那一次的紀錄；照本文用 ASCII 註解時，這條指令會成功、把 routed 政策改成 ACCEPT，所以不必照跑，跑了的話以 ufw default deny routed 改回：

1ufw default allow routed; echo "exit=$?"
2grep DEFAULT_FORWARD_POLICY /etc/default/ufw; iptables -S FORWARD | head -1

1UnicodeEncodeError: 'ascii' codec can't encode character '\uff1a' in position 12: ordinal not in range(128)
2exit=1
3DEFAULT_FORWARD_POLICY="ACCEPT"
4-P FORWARD DROP

\uff1a 是全形冒號 ：，position 12 是從 0 起算，也就是註解的第 13 個字元。ufw 改預設政策時會重寫規則檔，遇到這個字元時 Python 以 ASCII 編碼失敗、以 exit 1 結束。失敗之前 /etc/default/ufw 已經改成 ACCEPT，執行中的 FORWARD 鏈還是 DROP：設定檔與執行中的規則不一致。下一次 ufw reload 或重開機時 ufw 會讀設定檔，依這個讀法推論 FORWARD 會變成 ACCEPT，沒有實跑。反方向的 ufw default deny routed 也以同一個錯誤失敗過（Podman 那一篇實測時遇到）。after.rules 本身沒有被截斷（行數與修改時間都沒變）。註解改成 ASCII 之後同一條指令正常完成。檔案裡有沒有非 ASCII 字元，用 grep -nP '[^\x00-\x7F]' /etc/ufw/*.rules 查，沒有輸出就是全部 ASCII。

這一步的替代做法：

iptables-persistent（netfilter-persistent）：開機時載入 iptables-save 存下的整份規則。Docker 與 ufw 的規則也會一起被存進去，開機時跟 Docker、ufw 自己寫的規則重複載入，順序也可能排在它們之前或之後；這一種沒有實跑。
自己的 nftables 表：寫法與開機載入在源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS 的〈自己的 nftables 表：掛在目的位址轉換之前〉，那裡量過它在 firewalld 主機上的存續；在 ufw 主機上沒有實跑。ufw 用的是 iptables-nft，自建的 nftables 表跟它並存，ufw reload 時不會被清（依 ufw 只重建自己的鏈推論）。
不發佈或只發佈在 127.0.0.1（這一項替代的是整個 DOCKER-USER 做法，不只是開機載入）：發佈在 127.0.0.1 的連接埠外部來源連不到（firewalld 那一篇在 Docker 29.9.2 上量過），前面的反向代理以主機上的程式執行時，ufw 的入站規則就管得到它；在 ufw 主機上沒有實跑。

IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果

-p 8081:80 同時發佈在 IPv4 與 IPv6。容器所在的網路沒有開 IPv6（Docker 預設的 bridge 網路就是）時，IPv6 那一份改由主機上的程式接收：

1ss -ltnp | grep 8081

1LISTEN 0  4096     0.0.0.0:8081   0.0.0.0:*   users:(("docker-proxy",pid=616,fd=8))
2LISTEN 0  4096        [::]:8081      [::]:*   users:(("docker-proxy",pid=622,fd=8))

[::]:8081 由 docker-proxy 這個主機上的程式（Userland Proxy 的一種）接聽，它收下連線、再自己連到容器的 IPv4 位址。IPv6 的連線因此送到主機上的程式，走的是 input 路徑。IPv4 的 0.0.0.0:8081 也由 docker-proxy 聽著，而外部來的 IPv4 封包在 prerouting 就被 DNAT 改寫成容器位址，到不了它；它接的是不經過 prerouting 的連線，例如主機本機連 127.0.0.1:8081（依 Docker 的規則推論，沒有實跑）。用〈共用的函式與兩個測試來源〉的 ns_setup6 與 probe6 驗證，ufw 預設拒絕入站、沒有任何 IPv6 的放行規則時：

1probe6 8081

1  verify-cf     -> [fd00:beef::1]:8081  rc=28  000
2  verify-other  -> [fd00:beef::1]:8081  rc=28  000

兩個來源經由 IPv6 都逾時，同一時間經由 IPv4 兩個都拿到 200：IPv6 那一份受 ufw 的入站規則管，跟 IPv4 那一份相反。加上 Cloudflare ips-v6 每一段的放行之後只有 verify-cf 拿到 200（指令與計數的對帳在〈整份 Cloudflare 清單：IPv4 寫進 after.rules、IPv6 用 ufw 的入站規則〉）。第一輪另用一個只有一個來源的 namespace 量過加上與刪掉一條 IPv6 放行規則的前後，三次是逾時、連上（回 404，網頁目錄放在 /tmp 被清掉，連線送到了容器）、逾時。ip6tables -S DOCKER-USER 這時是空的，IPv6 這一路沒有經過它。

這個 IPv4 與 IPv6 分兩套機制的寫法，依賴容器網路沒有開 IPv6：之後有一個網路帶 --ipv6（或 daemon 設定的 default-network-opts 替新網路開了 IPv6），那個網路上發佈的 IPv6 連接埠就改走 ip6tables 的位址轉換與轉送路徑，ufw 的 IPv6 入站放行對它失效，而 ip6tables 的 DOCKER-USER 是空的，沒有任何訊號（依 Docker〈Port publishing〉推論，沒有實跑）。docker network inspect -f '{{.EnableIPv6}}' <網路名> 查得到每個網路有沒有開。

這一路的代價在容器看到的來源。補測時 docker logs verify-web 記到的兩筆是 [::ffff:173.245.48.10]（經由 IPv4、DNAT 轉進來的那一筆）與 [::ffff:172.17.0.1]（經由 IPv6、docker-proxy 轉進來的那一筆）：docker-proxy 自己連到容器，容器看到的來源是預設網路的閘道位址，不是 IPv6 的真實來源。容器裡的反向代理依來源位址判斷（例如只信任 Cloudflare 位址段送來的 CF-Connecting-IP）時，經由 IPv6 回源的請求不符合條件。

這個結果有兩個條件。一是 docker-proxy 有在執行：/etc/docker/daemon.json 寫 { "userland-proxy": false }、重啟 Docker 並重建容器之後，ss 只剩 0.0.0.0:8081（由 dockerd 聽著），docker ps 的 PORTS 欄只有 0.0.0.0:8081->80/tcp，ip6tables -t nat -S DOCKER 沒有任何轉換規則。在 ufw 停用時跑 probe6 8081，兩個來源的 curl 都以 exit 7 結束（連線立即被拒）：IPv6 那一份沒有發佈，不是改走別的路徑。二是容器的網路沒有開 IPv6：網路建立時帶 --ipv6、容器有 IPv6 位址時，Docker 用 ip6tables 把 IPv6 的連線位址轉換送進容器，那時它跟 IPv4 一樣走轉送路徑、不受 ufw 入站規則管，規則要寫在 ip6tables 的 DOCKER-USER；這一種也沒有實跑。

compose 自訂網路的容器經由 127.0.0.11 查詢時，DNS 封包從哪裡送出

容器送出的 DNS 查詢有兩條路，依容器接在哪一種網路而定：

 1mkdir -p /var/tmp/verify-fw/compose
 2cat > /var/tmp/verify-fw/compose/compose.yaml <<'EOF'
 3name: verify
 4services:
 5  dns:
 6    image: busybox:1.37
 7    container_name: verify-dns-compose
 8    command: sleep infinity
 9EOF
10docker compose -f /var/tmp/verify-fw/compose/compose.yaml up -d
11docker run -d --name verify-dns-bridge busybox:1.37 sleep infinity
12docker exec verify-dns-bridge grep nameserver /etc/resolv.conf
13docker exec verify-dns-compose grep nameserver /etc/resolv.conf

1nameserver 0.250.250.200
2nameserver 127.0.0.11

預設 bridge 網路的容器拿到主機 /etc/resolv.conf 的副本，直接問主機的解析器；compose 建的自訂網路（verify_default）上的容器問的是 127.0.0.11，那是 Docker 內建的解析器，它先解析同一個網路裡的服務名稱，其他名稱再往外查。

用 conntrack 看往外查的那一筆封包的來源：

1conntrack -F
2docker exec verify-dns-compose nslookup -timeout=3 example.org >/dev/null 2>&1
3conntrack -L -p udp --dport 53
4conntrack -F
5docker exec verify-dns-bridge nslookup -timeout=3 example.net >/dev/null 2>&1
6conntrack -L -p udp --dport 53

1udp 17 29 src=192.168.139.162 dst=0.250.250.200 sport=50462 dport=53 src=0.250.250.200 dst=192.168.139.162 ...
2udp 17 29 src=172.17.0.3 dst=0.250.250.200 sport=42585 dport=53 src=0.250.250.200 dst=192.168.139.162 ...

第一筆是 compose 容器（位址 172.18.0.2）的查詢：原始方向的來源是主機自己的 IP（192.168.139.162 是這台測試機的位址），代表往外查的封包由主機送出，不是從容器轉送出去的。第二筆是 bridge 容器的：原始來源是容器的 172.17.0.3，回程方向的目的地是主機 IP，那是 Docker 的位址偽裝。conntrack -F 清空連線追蹤表，讓 -L 只列出這一次查詢的那幾筆。

兩條路經過的防火牆位置因此不同。在 DOCKER-USER 擋掉容器網路送往解析器以外的 53，再在主機的 OUTPUT 擋掉全部的 53，量各種查詢。RES 是容器預設會問的上游解析器：這台機器的 /etc/resolv.conf 直接寫著 0.250.250.200。Ubuntu 預設的 systemd-resolved 讓 /etc/resolv.conf 指向 127.0.0.53，容器連不到主機的迴環位址，Docker 那時改把 /run/systemd/resolve/resolv.conf 裡的上游清單給容器；照抄下面那一行會取到 127.0.0.53，! -d $RES 就連 bridge 容器的預設查詢也擋掉。那種主機上改從 /run/systemd/resolve/resolv.conf 取，上游有好幾個時每一個各寫一組規則（依 Docker 的行為推論，沒有實跑）：

 1RES=$(awk '/^nameserver/{print $2; exit}' /etc/resolv.conf)   # systemd-resolved 主機改讀 /run/systemd/resolve/resolv.conf
 2q() { docker exec "$1" nslookup -timeout=3 example.com $2 >/dev/null 2>&1; echo "  $1 ${2:-（預設）} rc=$?"; }
 3qa() { q verify-dns-bridge; q verify-dns-bridge 1.1.1.1; q verify-dns-compose; q verify-dns-compose 1.1.1.1; }
 4for i in docker0 br-+; do for p in udp tcp; do
 5  iptables -I DOCKER-USER -i $i -p $p --dport 53 ! -d $RES -j DROP
 6done; done
 7qa
 8iptables -I OUTPUT -p udp --dport 53 -j DROP; iptables -I OUTPUT -p tcp --dport 53 -j DROP
 9q verify-dns-bridge; q verify-dns-compose
10iptables -D OUTPUT -p udp --dport 53 -j DROP; iptables -D OUTPUT -p tcp --dport 53 -j DROP

br-+ 比對所有 br- 開頭的介面，compose 建的自訂網路都是這種介面名；docker0 是預設網路。nslookup 的第二個引數是要問的 DNS 伺服器，沒給時用容器的 /etc/resolv.conf。

查詢	只有 `DOCKER-USER` 的規則	再加主機 OUTPUT 擋 53
bridge 容器，用預設的解析器	成功	成功
bridge 容器，直接問 `1.1.1.1`	失敗（逾時）	沒有量
compose 容器，用 `127.0.0.11`	成功	失敗
compose 容器，直接問 `1.1.1.1`	失敗（逾時）	沒有量

右欄的兩格「沒有量」：加了 OUTPUT 規則之後只送了兩種用預設解析器的查詢（上面區塊的 q 那一行），直接問 1.1.1.1 的兩種在左欄已經被 DOCKER-USER 擋下。「失敗」是 nslookup 在 3 秒內拿不到回應、以非零結束。

bridge 容器的查詢與 compose 容器直接指定伺服器的查詢，都從容器的介面轉送出去，DOCKER-USER 管得到、主機的 OUTPUT 管不到。compose 容器經由 127.0.0.11 的查詢由主機送出，只有主機的 OUTPUT 管得到；DOCKER-USER 的規則對它沒有作用。所以要讓容器的 DNS 只送往指定的解析器，兩個位置都要寫：DOCKER-USER（或自建 nftables 表的 forward 鏈）擋容器直接送出的，主機的出站規則擋內建解析器替它送出的。用 ufw 寫主機的出站規則時，寫法是先 ufw allow out to <解析器的位址> port 53、再 ufw deny out 53（ufw 依加入順序比對），這兩條沒有實跑，實測用的是上面的 iptables OUTPUT 規則。

這個結果是在主機解析器不是迴環位址（0.250.250.200）時量的；systemd-resolved 的主機上內建解析器往外查的封包從哪裡送出，沒有量。

清理：容器、ufw 規則、after.rules、namespace 與暫存目錄

 1docker rm -f verify-web verify-dns-bridge; docker compose -f /var/tmp/verify-fw/compose/compose.yaml down
 2pkill -f 'http.server 8080'
 3cp /var/tmp/verify-fw/after.rules.orig /etc/ufw/after.rules
 4ufw --force reset            # 回到 ufw 未設定、停用的狀態；主機原本就在用 ufw 時改成逐條 ufw delete
 5iptables -F DOCKER-USER; iptables -X CF-ONLY   # after.rules 不再宣告之後，鏈裡的規則要手動清（或重開機）
 6ip link del vcf-h; ip link del voth-h
 7ip netns del verify-cf; ip netns del verify-other
 8ip -6 addr del fd00:beef::1/128 dev lo
 9rm -f /etc/docker/daemon.json; systemctl restart docker   # 做過 userland-proxy 那一項時才需要
10rm -rf /var/tmp/verify-fw
11find /tmp /var/tmp -maxdepth 1 -name 'verify-*'      # 沒有輸出就清乾淨了

實測時 after.rules 的備份第一輪放在 /tmp、重開機時被清掉，所以還原那一行沒有實跑，改用 sed -i '/^# verify-ufw/,$d' /etc/ufw/after.rules 刪掉加上去的那一段（從註解那一行刪到檔尾，前提是那一段加在檔案最後），grep -c verify /etc/ufw/after.rules 回 0。ufw --force reset 會停用 ufw 並把規則檔備份成帶時間戳的副本，用在專門為實測建的機器上；主機原本有自己的 ufw 規則時，只刪這次加的那幾條（8080、8081 的兩條入站、IPv6 測試段與 ips-v6 各段的放行），改過 routed 政策的話以 ufw default deny routed 改回。整份清單那一次的清理照這個區塊實跑過，ip netns list 沒有輸出、ufw status 回 inactive、DOCKER-USER 只剩空鏈。veth 要在 namespace 之前刪：先刪 namespace 時，接在裡面的那一端消失，整對 veth 跟著不在，之後的 ip link del 回 Cannot find device（結果一樣乾淨，只是多一行錯誤訊息）。實測的清理在一個 bash -c '…' 裡跑時，pkill -f 'http.server 8080' 比對到了那個 bash 自己的命令列、把它殺掉，後面的指令都沒有執行；在互動式 shell 裡一行一行貼不會遇到，要寫成腳本時改用 pkill -f '[h]ttp.server 8080'，讓比對字串不出現在自己的命令列裡。機器是專為實測建的時，整台刪掉最乾淨：orb delete verify-ufw。

各寫法在 ufw 主機上的結果

寫法	範圍外的來源連發佈的連接埠（IPv4）	`ufw reload` 之後	Docker 重啟之後	重開機之後
ufw 入站規則（`ufw allow from … to any port 8081`）	連得到（管不到轉送路徑）	沒有單獨測	沒有單獨測	沒有測
ufw route 規則（`ufw route deny`）	連得到（排在 Docker 的鏈之後）	連得到	沒有測	沒有測
iptables 指令加進 `DOCKER-USER`	被擋（逾時）	規則還在（after.rules 沒有宣告這條鏈時）	規則還在	規則不在
寫進 `/etc/ufw/after.rules`	被擋（逾時）	規則還在	規則還在	規則還在
IPv6 那一份：ufw 入站規則只放行 `ips-v6`	被擋（逾時，經由 IPv6 連）	沒有單獨測	沒有測	被擋（沒有再數規則）

第二欄是規則剛套上時，範圍外的來源經由 IPv4（最後一列經由 IPv6）連發佈的連接埠的結果；後三欄是做完那個動作之後規則還在不在。「沒有單獨測」是那個動作做過、但這條規則不是當時要量的對象（例如量 DOCKER-USER 時順帶 reload 過），沒有記錄它的狀態；「沒有測」是沒有做那個動作。

Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址

Mon, 26 Oct 2026 00:00:00 +0800

事件說明：2026-10-26，在本機 macOS 的 OrbStack 2.2.5 建的兩台機器上實測（Arm 架構，核心是 OrbStack 自己的 7.2.12-orbstack）。一台是 Ubuntu 24.04.5：ufw 0.36.2、iptables 1.8.10（nf_tables 後端）、Podman 4.9.3 與 netavark 1.4.0、slirp4netns 1.2.1、Docker CE 29.9.2 加 docker-ce-rootless-extras。另一台是 Oracle Linux 10.2：firewalld 2.4.3（nftables 後端）、Podman 5.8.2（netavark）、Docker CE 29.9.2。測試容器是 busybox:1.37。

這篇記錄 Docker 以外的兩種容器執行方式發佈連接埠時，主機防火牆管不管得到：rootful Podman（以 root 執行、用 netavark 寫防火牆規則）在 Ubuntu 的 ufw 與 Oracle Linux 的 firewalld 上得到相反結果的原因、ufw 的 route 規則放行它的寫法；rootless Docker 與 rootless Podman（以一般使用者執行，核心的網路設定由使用者命名空間裡的程式代辦）發佈的連接埠由主機上的程式接收、受主機防火牆的入站規則管，以及代價：容器看到的來源位址不是真正的來源；最後是清理。以 root 執行的 Docker 在 ufw 主機上的行為見 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑，在 firewalld 主機上見源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS，只放行 CDN 位址的取捨見概念文章 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖。Kubernetes 的 NodePort 沒有測。

前置條件與測試來源

兩台主機：一台用 ufw 的 Ubuntu、一台用 firewalld 的 RHEL 系（這次是 Oracle Linux）。OrbStack 的建法是 orb create ubuntu:noble verify-ufw 與 orb create oracle:10 verify-fwd。兩台的 Docker 都照 Docker 官方套件庫的步驟裝，Podman 用發行版自己的套件（apt-get install podman、dnf install podman），所以兩台的 Podman 版本不同（4.9.3 與 5.8.2）。下文 rootful Podman 在兩台的結果不同，成因可能是防火牆、也可能是 Podman 的版本，這次沒有拿同一個版本在兩種防火牆上比較來分開兩者。
兩個測試來源：每台都照 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑的〈共用的函式與兩個測試來源〉建 verify-cf（173.245.48.10，在 Cloudflare 範圍內）與 verify-other（203.0.113.10，範圍外）兩個 network namespace，用同一個 probe <連接埠> 函式從兩個來源各連一次。rc=0 200 是連上，rc=7 是立即回拒，rc=28 000 是逾時（兩種失敗的分辨見 Connection Refused vs. Timeout（連線被拒與逾時））。
網頁檔：/var/tmp/verify-fw/www/index.html，內容隨意（mkdir -p /var/tmp/verify-fw/www; echo ok > /var/tmp/verify-fw/www/index.html）。
起始狀態：Ubuntu 那一台從 ufw 那一篇的〈DOCKER-USER 規則的效果…〉之前的狀態接著做：ufw 已經啟用（ufw default deny incoming、ufw --force enable；雲端主機先 ufw allow 22/tcp），Docker 的 verify-web 發佈著 8081（下文比較 Docker 與 Podman 時用到）。從一台新機器開始時，照那一篇的〈共用的函式與兩個測試來源〉與〈ufw 的入站規則與 route 規則對發佈連接埠的效果〉的前兩個區塊做到這個狀態。Oracle Linux 那一台只要 firewalld 執行中、public zone 是預設值。

rootful Podman 在 ufw 上：netavark 的轉送鏈、ufw 的預設 routed 政策、route 規則與 DOCKER-USER

ufw 已經啟用、預設拒絕入站，default routed 是 Ubuntu 預設的 deny（ufw default deny routed），沒有任何一條規則提到 8082：

1podman run -d --name verify-pod-web -p 8082:80 -v /var/tmp/verify-fw/www:/www:ro \
2  docker.io/library/busybox:1.37 httpd -f -p 80 -h /www
3probe 8082
4ss -ltnp | grep 8082
5iptables -t nat -S | grep 'dport 8082 -j DNAT'
6iptables -S NETAVARK_FORWARD

1  verify-cf     -> :8082  rc=28  000
2  verify-other  -> :8082  rc=28  000
3LISTEN 0  4096   0.0.0.0:8082   0.0.0.0:*   users:(("conmon",pid=2929,fd=5))
4-A NETAVARK-DN-1D8721804F16F -p tcp -m tcp --dport 8082 -j DNAT --to-destination 10.88.0.2:80
5-A NETAVARK_FORWARD -d 10.88.0.0/16 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
6-A NETAVARK_FORWARD -s 10.88.0.0/16 -j ACCEPT

Podman 用全名 docker.io/library/busybox:1.37，因為它不像 Docker 預設到 Docker Hub 找短名稱的映像。netavark 跟 Docker 一樣用 DNAT 把 8082 改寫成容器的 80，封包走轉送路徑。差別在轉送鏈：netavark 的 NETAVARK_FORWARD 只放行「送往容器網路的回程」與「容器送出的」，新的入站連線不在其中，封包往下落到 ufw 的鏈，最後被 FORWARD 的預設政策 DROP 丟掉，兩個來源都逾時。conmon（Podman 監看容器的程式）聽著 0.0.0.0:8082，它只是佔住這個連接埠，連線不經過它。

實測的順序跟上面相反：容器建好時這台的 routed 是 allow（FORWARD 的預設政策是 ACCEPT），第一次 probe 8082 兩個來源都拿到 200；改成 deny routed 之後才量到上面的兩個逾時。所以 routed 政策是 allow 時兩個來源都連得到，是 deny 時都連不到。

要只放行 Cloudflare，用 ufw 的 route 規則寫在轉送路徑上，目的地寫容器的位址與容器內的連接埠（位址轉換之後的值）：

1ufw default deny routed
2ufw route allow proto tcp from 173.245.48.0/20 to 10.88.0.2 port 80
3probe 8082

1  verify-cf     -> :8082  rc=0  200
2  verify-other  -> :8082  rc=28  000

只有範圍內的來源連得到。10.88.0.2 是容器的位址，取自上面那條 DNAT 規則的 --to-destination；容器重建之後位址可能變，規則要跟著改，這是 route 規則寫在位址轉換之後的代價。同一台主機上 Docker 的 8081 在 deny routed 下照樣對兩個來源開放（Docker 的 DOCKER-FORWARD 排在 ufw 的鏈之前、先接受了），所以同一台主機上 Docker 與 Podman 對同一條 ufw 設定的結果相反。

主機上也裝了 Docker 時，Podman 的轉送封包也經過 DOCKER-USER。為了只看 DOCKER-USER 的效果，先把 route 規則與 8082 的容器拿掉、routed 改回 allow（否則 FORWARD 的 DROP 會先把兩個來源都擋下），再發佈一個 8089 並看跳轉順序：

1podman rm -f verify-pod-web
2ufw route delete allow proto tcp from 173.245.48.0/20 to 10.88.0.2 port 80
3ufw default allow routed
4podman run -d --name verify-pod-web -p 8089:80 -v /var/tmp/verify-fw/www:/www:ro \
5  docker.io/library/busybox:1.37 httpd -f -v -p 80 -h /www
6iptables -S FORWARD | grep -- '-j' | head -3
7iptables -I DOCKER-USER -p tcp -m conntrack --ctorigdstport 8089 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP
8probe 8089
9iptables -D DOCKER-USER -p tcp -m conntrack --ctorigdstport 8089 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP

1-A FORWARD -m comment --comment "netavark firewall plugin rules" -j NETAVARK_FORWARD
2-A FORWARD -j DOCKER-USER
3-A FORWARD -j DOCKER-FORWARD
4  verify-cf     -> :8089  rc=0  200
5  verify-other  -> :8089  rc=28  000

FORWARD 先跳 NETAVARK_FORWARD，那裡不接受新的入站連線，封包回到 FORWARD 往下走，接著跳 Docker 的 DOCKER-USER；這一條跳轉沒有比對條件，所有轉送的封包都會進去。所以同一條比對原始目的連接埠的規則，對 Podman 發佈的連接埠一樣有效，範圍外的來源被擋。主機上沒有裝 Docker 時沒有 DOCKER-USER 這條鏈，這個寫法用不了（依鏈的建立者推論，沒有在沒裝 Docker 的主機上實跑）。量完以 ufw default deny routed 改回 routed 政策。

rootful Podman 在 firewalld 上：netavark 的 nftables 表、trusted zone 與 firewalld 的轉送鏈

Oracle Linux 那一台的 public zone 沒有任何規則提到 8089：

1podman run -d --name verify-pod-web -p 8089:80 -v /var/tmp/verify-fw/www:/www:ro,Z \
2  docker.io/library/busybox:1.37 httpd -f -p 80 -h /www
3probe 8089
4nft list tables
5firewall-cmd --get-active-zones
6nft list chain inet netavark FORWARD
7nft list chain inet firewalld filter_FORWARD | sed -n 2,5p
8iptables -S FORWARD | head -1

 1  verify-cf     -> :8089  rc=0  200
 2  verify-other  -> :8089  rc=0  200
 3table ip nat
 4table ip filter
 5table ip6 nat
 6table ip6 filter
 7table ip raw
 8table inet firewalld
 9table inet netavark
10docker
11  interfaces: docker0
12public (default)
13  interfaces: eth0
14trusted
15  sources: 10.88.0.0/16
16	chain FORWARD {
17		type filter hook forward priority filter; policy accept;
18		jump NETAVARK-ISOLATION-1
19		ip daddr 10.88.0.0/16 ct state established,related accept
20		ip saddr 10.88.0.0/16 accept
21	}
22		type filter hook forward priority filter + 10; policy accept;
23		ct state { established, related } accept
24		ct status dnat accept
25		iifname "lo" accept
26-P FORWARD ACCEPT

-v 的 :Z 讓 Podman 替掛進去的目錄改 SELinux 標籤（Oracle Linux 預設啟用 SELinux）；Ubuntu 沒有 SELinux，不需要。兩個來源都連得到。Podman 5.8.2 的 netavark 在這台用 nftables 寫自己的表 inet netavark，並把容器網路 10.88.0.0/16 加進 firewalld 的 trusted zone 的來源。一個轉送的封包要通過每一張表接在 forward hook 上的鏈，三張都放它過去：netavark 的 FORWARD 鏈預設政策是 accept、iptables 的 FORWARD 鏈（這台裝了 Docker，表是 Docker 經由 iptables-nft 建的）預設政策是 ACCEPT、firewalld 的轉送鏈有 ct status dnat accept。

Ubuntu 那一台被擋，是因為 ufw 把 iptables 的 FORWARD 預設政策設成 DROP；這一台的 firewalld 對經過位址轉換的連線一律接受。兩台的 Podman 版本也不同（見〈前置條件與測試來源〉），版本與防火牆的影響沒有分開。限制的寫法依同樣的路徑推論跟 Docker 在 firewalld 上的相同（自己的 nftables 表掛在位址轉換之前、雲端防火牆），沒有對 Podman 實跑。這台也裝了 Docker，iptables 的 FORWARD 鏈有跳到 DOCKER-USER 的那一條，依 Ubuntu 那一台的結果推論 DOCKER-USER 的規則同樣管得到 Podman 的轉送封包，在這一台沒有實跑。firewalld 的 StrictForwardPorts=yes 對 Podman 的效果沒有測。

從兩個帶 IPv6 位址的來源對主機的 IPv6 位址連 8089（namespace 加 IPv6 位址的做法同 ufw 那一篇的〈IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果〉），兩個都立即被回拒：ss -ltnp 裡 conmon 只聽 0.0.0.0:8089，Podman 沒有替 IPv6 發佈這個連接埠，連線落到 public zone 的回拒。

rootless Docker：rootlesskit 的接收路徑、ufw 入站規則與容器看到的來源位址

rootless 模式的 dockerd 以一般使用者執行，它不能改主機的 iptables，發佈連接埠改由 RootlessKit（rootless 模式替 dockerd 代辦網路的程式，屬於 Userland Proxy 這一類）在主機上聽那個連接埠、收下連線再轉進容器。安裝與啟動（以 root 建使用者、以那個使用者執行設定工具）：

 1apt-get install -y docker-ce-rootless-extras uidmap
 2useradd -m -s /bin/bash verifyrl
 3loginctl enable-linger verifyrl             # 讓這個使用者的 systemd user 服務在沒有登入時也執行
 4U=verifyrl; X=/run/user/$(id -u $U)
 5cd /tmp                                     # 一般使用者讀不了 /root，原因寫在指令之後
 6sudo -u $U XDG_RUNTIME_DIR=$X DBUS_SESSION_BUS_ADDRESS=unix:path=$X/bus dockerd-rootless-setuptool.sh install
 7sudo -u $U XDG_RUNTIME_DIR=$X DOCKER_HOST=unix://$X/docker.sock bash -lc 'cd ~; mkdir -p www; echo ok > www/index.html;
 8  docker run -d --name verify-rl-web -p 8083:80 -v ~/www:/www:ro busybox:1.37 httpd -f -v -p 80 -h /www'
 9probe 8083
10ss -ltnp | grep 8083; iptables -t nat -S | grep -c 8083

verifyrl 是這次建的測試使用者，換成實際要跑 rootless Docker 的帳號。XDG_RUNTIME_DIR 與 DBUS_SESSION_BUS_ADDRESS 指向那個使用者的 systemd user 執行環境，設定工具要用它們建立 user 服務；DOCKER_HOST 指到 rootless dockerd 的 socket，否則 docker 指令會去連 root 的那一個。httpd 的 -v 讓它逐筆印存取紀錄，下面用它看容器收到的來源位址。這台 OrbStack 的核心沒有 AppArmor（aa-status 回 apparmor not present），所以碰不到 Ubuntu 24.04 對非特權 user namespace 的限制；Docker 的〈Rootless mode troubleshooting〉寫明，在 Ubuntu 24.04 以後的發行版核心上，以 deb 套件裝 docker-ce-rootless-extras 時 rootlesskit 的 AppArmor profile 已經隨 apparmor 套件附上（這台的 /etc/apparmor.d/ 也有 rootlesskit 這個檔），改用安裝腳本裝時要照那一頁手動加 profile，在發行版核心上沒有實跑。

1  verify-cf     -> :8083  rc=28  000
2  verify-other  -> :8083  rc=28  000
3LISTEN 0  4096   0.0.0.0:8083   0.0.0.0:*   users:(("rootlesskit",pid=4085,fd=13))
4LISTEN 0  4096      [::]:8083      [::]:*   users:(("rootlesskit",pid=4085,fd=15))
50

nat 表裡沒有 8083 的位址轉換（0），聽 8083 的是主機上的 rootlesskit。連線送到主機上的程式，走的是 input 路徑，ufw 的預設拒絕入站擋下兩個來源。加一條入站規則：

1ufw allow from 173.245.48.0/20 to any port 8083 proto tcp
2probe 8083
3sudo -u verifyrl XDG_RUNTIME_DIR=/run/user/$(id -u verifyrl) DOCKER_HOST=unix:///run/user/$(id -u verifyrl)/docker.sock \
4  bash -lc 'docker logs verify-rl-web 2>&1 | tail -1'

1  verify-cf     -> :8083  rc=0  200
2  verify-other  -> :8083  rc=28  000
3[::ffff:172.17.0.1]:54596: response:200

ufw 的入站規則對 rootless Docker 發佈的連接埠有效。IPv6 那一份也由 rootlesskit 聽著（[::]:8083），依同一條路徑推論受 ufw 的 IPv6 入站規則管，沒有實跑。代價在最後一行：busybox httpd 記下的連線來源是 172.17.0.1（rootless dockerd 自己網路裡的閘道），不是 173.245.48.10。預設設定下來源位址沒有保留，容器裡的網站程式依來源位址做的事（存取紀錄、速率限制、只信任來自 CDN 的 CF-Connecting-IP）都拿不到真正的來源。Docker 的〈Rootless mode troubleshooting〉列了保留來源位址的做法，這次都沒有實跑：RootlessKit v3.0 以後，預設的 builtin 連接埠轉送在 ~/.config/docker/daemon.json 寫 {"userland-proxy": false} 並重啟之後保留來源位址（文件寫明可能還要載入 br_netfilter 模組）；更早的版本改用 slirp4netns 轉送方式（環境變數 DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=slirp4netns），或 pasta 網路加 implicit 轉送方式（DOCKERD_ROOTLESS_ROOTLESSKIT_NET=pasta、DOCKERD_ROOTLESS_ROOTLESSKIT_PORT_DRIVER=implicit，文件標為實驗性、吞吐量比 slirp4netns 好）。環境變數寫在 ~/.config/systemd/user/docker.service.d/override.conf 的 [Service] 底下。

rootless Podman：rootlessport 的接收路徑、ufw 入站規則與容器看到的來源位址

網頁檔沿用〈rootless Docker：rootlesskit 的接收路徑、ufw 入站規則與容器看到的來源位址〉在 verifyrl 家目錄建的 ~/www；跳過那一節時，在 cd ~; 之後先 mkdir -p www; echo ok > www/index.html。

1cd /tmp
2sudo -u verifyrl XDG_RUNTIME_DIR=/run/user/$(id -u verifyrl) bash -lc 'cd ~;
3  podman run -d --name verify-rlp-web -p 8084:80 -v ~/www:/www:ro docker.io/library/busybox:1.37 httpd -f -v -p 80 -h /www'
4probe 8084; ss -ltnp | grep 8084
5ufw allow from 173.245.48.0/20 to any port 8084 proto tcp; probe 8084
6sudo -u verifyrl XDG_RUNTIME_DIR=/run/user/$(id -u verifyrl) bash -lc 'cd ~; podman logs verify-rlp-web 2>&1 | tail -1'

1  verify-cf     -> :8084  rc=28  000
2  verify-other  -> :8084  rc=28  000
3LISTEN 0  4096   *:8084   *:*   users:(("rootlessport",pid=4921,fd=11))
4  verify-cf     -> :8084  rc=0  200
5  verify-other  -> :8084  rc=28  000
6[::ffff:10.0.2.100]:59274: response:200

podman logs 印出的存取紀錄裡，來源是 10.0.2.100（::ffff: 是 IPv4 位址寫成 IPv6 格式時的前綴，httpd 聽的是 IPv6 的 socket）。那是 slirp4netns（Podman 4.9 文件寫的 rootless 預設網路）在 rootless 網路命名空間裡那張 tap 介面的位址，rootlessport 從這個位址把連線轉進容器。這台的 podman info 取不出 rootless 網路的種類，預設是 slirp4netns 是依文件，不是從輸出確認的。跟 rootless Docker 一樣，ufw 的入站規則管得到，容器看不到真正的來源。Podman 5 的 rootless 預設網路改成 pasta，pasta 預設保留來源位址（Podman 5.0 的發行說明），沒有實跑。

兩個 rootless 的指令都先 cd /tmp、在使用者的 shell 裡再 cd ~：在 /root 底下以 sudo -u 執行時，第一次跑 rootless Podman 得到 cannot chdir to /root: Permission denied 與 Error: setting up the process，容器沒有啟動。原因是一般使用者讀不了 /root，而 Podman 在這個使用者的身分下要用目前的工作目錄。

清理：兩台主機上的容器、測試使用者、ufw 規則、namespace 與暫存目錄

Ubuntu 那一台：

 1podman rm -f verify-pod-web
 2cd /tmp
 3sudo -u verifyrl XDG_RUNTIME_DIR=/run/user/$(id -u verifyrl) bash -lc 'cd ~; podman rm -f verify-rlp-web;
 4  DOCKER_HOST=unix:///run/user/$(id -u)/docker.sock docker rm -f verify-rl-web;
 5  dockerd-rootless-setuptool.sh uninstall'
 6loginctl disable-linger verifyrl
 7while pgrep -u verifyrl >/dev/null; do sleep 1; done      # 等 systemd 停掉這個使用者的程序
 8userdel -r verifyrl
 9ufw delete allow from 173.245.48.0/20 to any port 8083 proto tcp
10ufw delete allow from 173.245.48.0/20 to any port 8084 proto tcp

8082 的 route 規則已經在 8089 那一步刪掉。namespace、verify-web、/var/tmp/verify-fw 與其他 ufw 設定，照 ufw 那一篇的〈清理：容器、ufw 規則、after.rules、namespace 與暫存目錄〉清。Oracle Linux 那一台這一篇只建了 verify-pod-web 與兩個 namespace：

1podman rm -f verify-pod-web
2firewall-cmd --zone=trusted --list-sources                 # 還列得出 10.88.0.0/16 時接下一行
3firewall-cmd --zone=trusted --remove-source=10.88.0.0/16   # 只移除執行中的設定；沒有實跑
4ip link del vcf-h; ip link del voth-h; ip netns del verify-cf; ip netns del verify-other
5rm -rf /var/tmp/verify-fw

firewalld 那一篇的清理段刪的是那一篇自己建的資源（靜態的 dockerd、ipset、nftables 表、/var/lib/docker），不要照它整段跑。這兩段清理指令跟實測時的順序不同：實測時兩台的清理分在幾次跑，沒有照這兩段一次跑完。

disable-linger 之後，systemd 要過一會兒才停掉那個使用者的 user 服務；實測緊接著跑 userdel 時回 userdel: user verifyrl is currently used by process 2749、使用者沒有刪掉，所以中間等到 pgrep -u verifyrl 沒有輸出。dockerd-rootless-setuptool.sh uninstall 只移除 user 服務，印出的提示寫明不刪 Docker 的資料；userdel -r 刪掉家目錄時，那些資料（~/.local/share/docker）一起刪掉。

firewalld 那一台的 trusted zone 裡 10.88.0.0/16 的來源由 netavark 在容器網路存在時加入，最後一個用到預設網路的容器刪掉之後是否移除沒有確認。留著的影響是之後任何從 10.88.0.0/16 來的連線都由 trusted zone 處理、一律放行；這段位址只在主機內部的 Podman 網路上，外部來源用不到它。OrbStack 的機器整台刪掉時兩台一起刪：orb delete verify-ufw verify-fwd。

rootful 與 rootless 的 Docker、Podman：接收路徑、入站規則與容器看到的來源位址

執行方式	接收連線的路徑	主機防火牆的入站規則是否管得到	容器看到的來源位址
rootful Docker（參考，見 ufw 與 firewalld 那兩篇）	IPv4 位址轉換後轉送；IPv6 由 docker-proxy 接收（容器網路沒開 IPv6、userland-proxy 預設開著時）	IPv4 管不到；IPv6 管得到（ufw 與 firewalld 都量過）	IPv4 是真正的來源；IPv6 是預設網路的閘道 `172.17.0.1`（ufw 那一篇量的）
rootful Podman 4.9.3，ufw	位址轉換後轉送；routed 是 deny 時被 FORWARD 的 DROP 擋下，是 allow 時放行	管不到；ufw route 規則管得到，主機也裝了 Docker 時 `DOCKER-USER` 也管得到	沒有記錄
rootful Podman 5.8.2，firewalld	位址轉換後轉送，firewalld 接受	管不到	沒有記錄
rootless Docker 29.9.2	主機上的 `rootlesskit`	管得到	`172.17.0.1`
rootless Podman 4.9.3	主機上的 `rootlessport`	管得到	`10.0.2.100`

判斷一種執行方式落在哪一列，先查有沒有規則把那個連接埠的目的地改寫掉，再看誰在聽。改寫規則用 nft list ruleset | grep 'dport <連接埠>' 查：它同時列出經由 iptables-nft 寫的表（Docker、Podman 4.9 的 netavark）與原生 nftables 的表（Podman 5.8.2 的 inet netavark）。只看 iptables -t nat -S 會漏掉後一種：在 Oracle Linux 那一台另發佈一個 8090，iptables -t nat -S | grep -c 8090 回 0，nft list ruleset 列得出 tcp dport 8090 dnat ip to 10.88.0.3:80，同時 ss -ltnp 顯示 conmon 聽著 8090。查到改寫規則時，就是轉送路徑，結果取決於轉送鏈上每一張表的預設政策，聽著那個連接埠的程式（conmon、docker-proxy 的 IPv4 那一份）只是佔住連接埠，不算數；IPv6 的改寫規則（ip6 nat 或 inet 表裡帶 ip6 的那幾條）另外判一次。查不到改寫規則、由一個轉送程式聽著時（rootlesskit、rootlessport、rootful Docker 的 IPv6 那一份聽著的 docker-proxy），才是 input 路徑，入站規則管得到。查表的結果是預測，最終以範圍外的來源實際連一次為準（probe <連接埠>）；Kubernetes 的 NodePort 這類多跳改寫沒有測。

Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠

Mon, 26 Oct 2026 00:00:00 +0800

事件說明：2026-10-25 到 26 日，用 Cloudflare 免費方案的帳號與一個已經加進 Cloudflare 的網域（原本只有郵件路由的紀錄），源站是 Oracle Cloud ap-batam-1 區域新建的一台 A1 主機（Arm、Oracle Linux 10.2、1 OCPU、6 GB），放在新建的公開子網路、有公開 IPv4，VCN 沒有開 IPv6。nginx 1.26.3（Oracle Linux 的套件），cloudflared 2026.10.3（Cloudflare 在 GitHub 發佈的 RPM），wrangler 4.152.0（以 npx 執行）。

這篇記錄把一台源站（實際跑網站程式的主機）接到 Cloudflare 後面、實際讓 Cloudflare 回源（CDN 從自己的機房連回源站取回應）時量到的結果：Oracle Cloud 的 NSG（network security group，套在網卡上的一組放行規則，跟 AWS 的 Security Group 是同一類）只放行 Cloudflare 的 IPv4 清單，以及 NSG 的規則數上限與每次 API 呼叫能加的規則數、GCP 與 AWS 文件寫的上限；源站的 nginx 設定與從 Cloudflare 範圍外直連的結果；網域的 DNS 紀錄經由 Cloudflare 代理之後，回源連線實際的來源位址與它們落在公布清單的哪一段；Authenticated Origin Pulls（AOP，Cloudflare 回源時出示用戶端憑證，也就是 TLS / mTLS 的雙向驗證）在 nginx 上的驗證與拒絕沒有憑證的連線；Cloudflare Worker 從 Cloudflare 的位址連到源站、並在請求裡偽造 CF-Connecting-IP 時源站收到什麼（用的是自己的帳號，連一個不屬於任何 Cloudflare 網域的主機名稱）；Cloudflare Tunnel 的 quick tunnel 在源站沒有任何入站放行時的連線方式、預設的協定，以及出站擋掉 UDP 7844、TCP 7844 之後的結果；清理與 Cloudflare 設定的還原。這些限制各自擋得住什麼、要放在雲端防火牆、主機防火牆還是 Cloudflare 端，寫在概念文章 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖；主機防火牆上只放行 Cloudflare 位址的寫法在源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS。

前置條件：Cloudflare 的網域、有公開 IP 的源站與本機的工具

一個加進 Cloudflare 的網域：免費方案就夠。實測只新增一筆子網域的 A 紀錄（下文的 verify-origin.<網域>），網域原有的紀錄不動；SSL/TLS 模式與 AOP 是整個網域的設定，改之前先記下原值，測完照原值還原（〈清理與 Cloudflare 設定的還原〉）。網域上有正在服務的網站時，改 SSL/TLS 模式會影響它，要另外評估或用一個沒有在用的網域。
一台有公開 IP、能連外的主機：Cloudflare 回源要連得到源站，Tunnel 要源站連得出去，所以主機要在有 internet gateway 的公開子網路。只有 service gateway 的私有子網路（例如 Oracle Cloud 建立主機的實測紀錄：建立前的檢查、前置網路、主控台各分頁的 Always Free 設定值、等效的 CLI 指令、容量不足的重送、Bastion 工作階段逾時、Run Command 補公鑰的嘗試與重建後經由 port forwarding 登入建的那一種）兩件事都做不到，下文在一個既有的 VCN 裡另建公開子網路與一台新主機。原本想用永久免費的 VM.Standard.E2.1.Micro：oci limits resource-availability get 回 available: 2，但 oci compute shape list --availability-domain 列出的 shape 裡沒有它（是 availability domain 的名稱，oci iam availability-domain list 查得到），ap-batam-1 不提供這個 shape，改用同樣在免費額度內的 A1（VM.Standard.A1.Flex，1 OCPU、6 GB）。
本機的工具：OCI CLI（以 session token 登入，做法見從本機用 OCI CLI 操作 Oracle Cloud：session token 登入、時效與 API 簽章金鑰）、npx（Node.js 附的，執行 wrangler 用），以及 SSH 金鑰。
wrangler 登入與 workers.dev 子網域：npx wrangler login 會開瀏覽器做 OAuth 授權，由帳號的擁有者自己按。Worker 要部署到 *.workers.dev 之前，帳號要先有一個 workers.dev 子網域；這次的帳號還沒有，wrangler deploy 回 Could not automatically register "worker" as your workers.dev subdomain because the name is unavailable，它給的註冊網址（/workers/onboarding）在主控台回 404。打開主控台的 Workers & Pages 頁面之後，頁面的 Account details 列出了一個以帳號名稱建的子網域，再 wrangler deploy 就成功了；子網域是打開頁面時自動建的，還是更早就有，沒有分辨。

公開子網路、只放行 Cloudflare 的 NSG 與它的規則數上限

這一步在 VCN 裡建出一條對外的路：internet gateway、預設路由指向它的 route table、只放行管理者自己 SSH 的 security list、公開子網路，以及一個只放行 Cloudflare IPv4 到 80 與 443 的 NSG。、是 compartment 與 VCN 的 OCID，<管理者的公開 IP> 是自己這台電腦連外時的公開位址（curl -s https://ifconfig.me 查得到）：

 1export OCI_CLI_AUTH=security_token
 2IGW=$(oci network internet-gateway create -c  --vcn-id  --is-enabled true --display-name verify-igw \
 3  --wait-for-state AVAILABLE --query data.id --raw-output)
 4RTP=$(oci network route-table create -c  --vcn-id  --display-name verify-public-rt \
 5  --route-rules "[{\"destination\":\"0.0.0.0/0\",\"destinationType\":\"CIDR_BLOCK\",\"networkEntityId\":\"$IGW\"}]" \
 6  --wait-for-state AVAILABLE --query data.id --raw-output)
 7SLP=$(oci network security-list create -c  --vcn-id  --display-name verify-public-sl \
 8  --ingress-security-rules '[{"protocol":"6","source":"<管理者的公開 IP>/32","tcpOptions":{"destinationPortRange":{"min":22,"max":22}}}]' \
 9  --egress-security-rules '[{"protocol":"all","destination":"0.0.0.0/0"}]' \
10  --wait-for-state AVAILABLE --query data.id --raw-output)
11SNP=$(oci network subnet create -c  --vcn-id  --cidr-block 10.0.2.0/24 --display-name verify-public-subnet \
12  --dns-label pub --prohibit-public-ip-on-vnic false --route-table-id "$RTP" --security-list-ids "[\"$SLP\"]" \
13  --wait-for-state AVAILABLE --query data.id --raw-output)
14NSG=$(oci network nsg create -c  --vcn-id  --display-name verify-origin-cf \
15  --wait-for-state AVAILABLE --query data.id --raw-output)

五個變數存著新建資源的 OCID，後面的 NSG、主機與清理都用到它們；只存在這個 shell 裡，換了 shell（實測橫跨兩天）時用顯示名稱查回來，例如 NSG=$(oci network nsg list -c --display-name verify-origin-cf --query 'data[0].id' --raw-output)，其餘四種資源的 list 子命令同樣接受 --display-name（這幾行查詢沒有實跑）。session token 預設一小時過期，過期之後照從本機用 OCI CLI 操作 Oracle Cloud：session token 登入、時效與 API 簽章金鑰的〈Session token 的時效與 refresh〉延長或重新登入。10.0.2.0/24 是 VCN 的 10.0.0.0/16 裡一段還沒用過的位址，換成自己 VCN 裡沒有被其他子網路佔用的一段。security list 套在整個子網路上，這裡只放 SSH；網站的 80 與 443 放在 NSG，NSG 只套在指定的網卡上，同一個子網路裡別的主機不會因此對 Cloudflare 開放。出站全放行，cloudflared 與套件安裝要用。

NSG 的規則每一條只放一段來源與一個連接埠範圍，Cloudflare 的 15 段 IPv4 對 80 與 443 各一條，是 30 條，每 25 條分一批送：

 1curl -s https://www.cloudflare.com/ips-v4 | python3 -c '
 2import sys, json
 3nets = sys.stdin.read().split()
 4rules = [{"direction":"INGRESS","protocol":"6","source":n,"sourceType":"CIDR_BLOCK",
 5  "tcpOptions":{"destinationPortRange":{"min":p,"max":p}},"description":"cloudflare"} for n in nets for p in (80,443)]
 6for i in range(0, len(rules), 25):
 7    open(f"/tmp/verify-nsg-batch{i//25}.json","w").write(json.dumps(rules[i:i+25]))'
 8for f in /tmp/verify-nsg-batch*.json; do
 9  oci network nsg rules add --nsg-id "$NSG" --security-rules "file://$f" --query 'length(data."security-rules")'
10done
11oci network nsg rules list --nsg-id "$NSG" --all --query 'length(data)'

125
25
330

一次送出 30 條時 API 回 InvalidParameter：Count of security rules to add: 30 cannot be greater than 25。每一次 nsg rules add 最多 25 條，所以 Python 把規則每 25 條寫成一個檔，迴圈逐檔加。/tmp/verify-nsg-batch*.json 是本機的暫存檔，加完以 rm /tmp/verify-nsg-batch*.json 刪掉。Cloudflare 的清單會變（2026-10-25 是 15 段 IPv4、7 段 IPv6），每次重抓。

NSG 的總規則數另有上限。另建一個空的 NSG（建法同上面的 nsg create，顯示名稱用 verify-limit），每次加 25 條、目的連接埠 443、來源是 198.18.x.y/32 的假位址（198.18.0.0/15 是保留給網路設備效能測試的位址段，不會出現在網際網路上），直到被拒：

動作	回應	加完的總數
第 1 到 4 批，每批 25 條入站	成功	100
第 5 批 25 條	`Total security rules count 125 cannot be greater than 120`	100
1 條出站	成功	101
19 條入站	成功	120
再 1 條入站	`Total security rules count 121 cannot be greater than 120`	120

一個 NSG 最多 120 條，入站與出站合計，跟 Oracle〈Security Rules〉的限制表相同；超過時整批被拒，不是加到滿為止。只放行 Cloudflare 的 IPv4 到 80 與 443 要 30 條，再加 IPv6 的 7 段是 44 條，一個 NSG 放得下；要放行更多連接埠時，條數是「段數 × 連接埠數」，一張網卡最多套 5 個 NSG。security list 的上限是入站 200 條、出站 200 條（同一份文件，不能申請調高），沒有實測。測試用的 NSG 測完以 oci network nsg delete --nsg-id --force 刪掉。

GCP 與 AWS 只查了文件，沒有實測：

業者	規則的形狀	上限（文件）	放 Cloudflare 清單的條數
Oracle Cloud NSG	一條一段來源、一個連接埠範圍	120 條（入站加出站），實測相同	IPv4 30 條，加 IPv6 共 44 條
AWS security group	一條一段來源、一個連接埠範圍	入站 60 條（IPv4 與 IPv6 分開計算，可申請調高；乘上每張網卡的 security group 數不超過 1000）〔Amazon VPC quotas〕	IPv4 30 條、IPv6 14 條，各自在 60 之內
GCP VPC 防火牆規則	一條可放多段來源與多個連接埠	每條最多 5000 段來源，不能調高；一條規則只能是 IPv4 或只能是 IPv6〔Cloud NGFW quotas〕	IPv4、IPv6 各 1 條

AWS 的 managed prefix list 被 security group 引用時，以 prefix list 的「最大項數」計入規則數，不是實際的項數（同一份 quotas 文件）。清單的更新三家都要有人或程式去改：Oracle 一條規則只放一段，每次更新是逐條增刪；AWS 規則直接寫位址段時也是逐條增刪，改用自建的 customer-managed prefix list 時更新的是 list 的項目，security group 的規則不動（依文件，沒有實跑）；GCP 改的是那一條規則的來源清單。

源站主機：建立、nginx 與從範圍外直連的結果

主機建在公開子網路，帶公開 IP，網卡套上那個 NSG：

1INST=$(oci compute instance launch -c  --availability-domain  --display-name verify-origin \
2  --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' \
3  --image-id 10 aarch64 映像的 OCID> --subnet-id "$SNP" --assign-public-ip true --nsg-ids "[\"$NSG\"]" \
4  --ssh-authorized-keys-file <公鑰檔> --wait-for-state RUNNING --max-wait-seconds 900 --query data.id --raw-output)

A1 回容量不足（Out of host capacity）時要重送，做法見 Oracle Cloud 建立主機的實測紀錄：建立前的檢查、前置網路、主控台各分頁的 Always Free 設定值、等效的 CLI 指令、容量不足的重送、Bastion 工作階段逾時、Run Command 補公鑰的嘗試與重建後經由 port forwarding 登入的〈重送建立請求：CLI 自己的重送、限流門檻與重送腳本〉；這次第一次送出就建成了。映像的 OCID 用 oci compute image list -c --operating-system "Oracle Linux" --shape VM.Standard.A1.Flex --sort-by TIMECREATED 查，第一筆是最新的；這次是 Oracle-Linux-10.2-aarch64-2026.10.16-0。主機進入 RUNNING 之後，oci compute instance list-vnics --instance-id "$INST" 列出公開 IP，SSH 以 opc 登入，再 sudo -i 進 root shell：下面在源站上跑的區塊都在這個 root shell 裡（cat > /etc/… 的重導向要 root 權限）。

nginx 開兩個服務：80 給一般回源；443 用自簽憑證，之後測 AOP。存取紀錄記下 TCP 連線的來源位址（$remote_addr）、Cloudflare 帶來的 CF-Connecting-IP 標頭與用戶端憑證的驗證結果：

 1dnf -y install nginx openssl
 2mkdir -p /etc/nginx/verify
 3openssl req -x509 -newkey rsa:2048 -nodes -days 7 -subj "/CN=verify-origin" \
 4  -keyout /etc/nginx/verify/self.key -out /etc/nginx/verify/self.crt
 5curl -sSf https://developers.cloudflare.com/ssl/static/authenticated_origin_pull_ca.pem -o /etc/nginx/verify/cf-origin-pull-ca.pem
 6cat > /etc/nginx/conf.d/verify.conf <<'EOF'
 7log_format verify '$remote_addr cfip=$http_cf_connecting_ip host=$host ssl_client_verify=$ssl_client_verify "$request" $status';
 8server {
 9    listen 80 default_server;
10    server_name _;
11    access_log /var/log/nginx/verify.log verify;
12    location / { default_type text/plain; return 200 "verify-origin http from $remote_addr\n"; }
13}
14server {
15    listen 443 ssl default_server;
16    server_name _;
17    ssl_certificate     /etc/nginx/verify/self.crt;
18    ssl_certificate_key /etc/nginx/verify/self.key;
19    ssl_client_certificate /etc/nginx/verify/cf-origin-pull-ca.pem;
20    ssl_verify_client optional;
21    access_log /var/log/nginx/verify.log verify;
22    location / { default_type text/plain; return 200 "verify-origin https from $remote_addr client_verify=$ssl_client_verify\n"; }
23}
24EOF
25sed -i 's/listen       80 default_server;/listen       80;/; s/listen       \[::\]:80 default_server;/listen       [::]:80;/' /etc/nginx/nginx.conf
26nginx -t && systemctl enable --now nginx
27firewall-cmd --permanent --zone=public --add-service=http --add-service=https; firewall-cmd --reload

authenticated_origin_pull_ca.pem 是 Cloudflare 用來簽 AOP 共用用戶端憑證的 CA，ssl_client_certificate 指向它，nginx 才驗得出那張憑證。ssl_verify_client optional 先只記錄驗證結果、不拒絕，後面改成 on。Oracle Linux 套件附的 nginx.conf 自帶一個 listen 80 default_server 的 server 區塊，跟 verify.conf 的 default_server 重複時 nginx -t 會失敗，所以 sed 拿掉原檔的 default_server；拿掉之後 nginx -t 仍印 conflicting server name "_" on 0.0.0.0:80, ignored 的警告，兩個區塊都用 _ 當 server_name，不影響結果。主機防火牆開 http 與 https 是因為這次的來源限制放在 NSG；主機防火牆再疊一層只放行 Cloudflare 的寫法見源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS。

從本機（位址不在 Cloudflare 範圍）直接連源站的公開 IP：

1curl -sS -m 8 -o /dev/null -w '%{http_code}\n' http://<源站的公開 IP>/
2curl -sSk -m 8 -o /dev/null -w '%{http_code}\n' https://<源站的公開 IP>/

兩條都在 8 秒後逾時，印 000：NSG 沒有放行本機的位址，封包在 Oracle 的網路上就被丟掉，主機收不到。管理者的 SSH 走 security list 放行的 22，不受影響。

DNS 紀錄經由 Cloudflare 代理之後，回源的來源位址

在 Cloudflare 主控台的 DNS → Records 新增一筆紀錄：類型 A、名稱 verify-origin、IPv4 位址填源站的公開 IP、Proxy status 是 Proxied（橘色雲朵）、TTL 自動（用預設值，沒有比較其他值；依 Cloudflare 的 DNS 文件，Proxied 的紀錄 TTL 由 Cloudflare 決定）。Proxy status 改成 DNS only（灰色雲朵）時，網域直接解析到源站的公開 IP，訪客直連源站，被 NSG 擋下，這次沒有實跑。存好之後從本機連：

1dig +short verify-origin.<網域> A; dig +short verify-origin.<網域> AAAA
2for i in $(seq 10); do
3  curl -s -m 10 -o /dev/null -w "http %{http_code}\n" http://verify-origin.<網域>/
4  curl -s -m 10 -o /dev/null -w "https %{http_code}\n" https://verify-origin.<網域>/
5done | sort | uniq -c
6curl -s https://verify-origin.<網域>/

1
2
3  10 http 200
4  10 https 200
5verify-origin http from 172.69.134.32

網域解析到 Cloudflare 的位址（104.21.0.0/16、172.67.0.0/16 與 2606:4700::/32 裡各兩個，每個網域分到的位址不同），Proxied 的紀錄另外有 AAAA，即使源站只填了 IPv4。https 的回應內容寫著 http from：這個網域的 SSL/TLS 是自動模式，當時實際套用的是 Flexible（彈性），訪客到 Cloudflare 用 https，Cloudflare 回源用 http 的 80。

連了幾輪之後，把源站的存取紀錄拿回本機，逐筆比對來源位址在不在 Cloudflare 公布的清單裡：

1python3 - verify.log ips-v4.txt <<'EOF'
2import sys, ipaddress, collections
3nets = [ipaddress.ip_network(n) for n in open(sys.argv[2]).read().split()]
4c = collections.Counter(l.split()[0] for l in open(sys.argv[1]) if not l.startswith('127.'))
5for ip, n in sorted(c.items()):
6    hit = [str(x) for x in nets if ipaddress.ip_address(ip) in x]
7    print(f"{ip:16} {n:3}  {hit[0] if hit else '範圍外'}")
8EOF

verify.log 是源站的 /var/log/nginx/verify.log，ips-v4.txt 是 https://www.cloudflare.com/ips-v4 的內容。這次全部測試結束時的結果：

 1104.22.17.208      3  104.16.0.0/13
 2104.22.17.80       2  104.16.0.0/13
 3104.22.20.232      6  104.16.0.0/13
 4104.22.20.233      3  104.16.0.0/13
 5108.162.246.209    2  108.162.192.0/18
 6162.158.167.47     1  162.158.0.0/15
 7162.158.167.48     4  162.158.0.0/15
 8172.69.134.32      5  172.64.0.0/13
 9172.69.23.187      3  172.64.0.0/13
10172.71.154.190     1  172.64.0.0/13
11172.71.158.118     5  172.64.0.0/13
12172.71.158.119     2  172.64.0.0/13

37 筆來自 12 個位址，全部落在公布的四段裡，沒有一筆在範圍外；回源用哪些位址依訪客連到的 Cloudflare 機房與時間而變，自己量時清單會不同。cfip= 的分布：33 筆是本機的公開 IP（下文的輸出以 <管理者的公開 IP> 代替），2 筆是下文 Worker 的請求（- 與偽造的 198.51.100.77 各 1 筆），另外 2 筆來自 108.162.246.209、連的是經由代理的 verify-origin.<網域>、AOP 驗證 SUCCESS，cfip 是 2a06:98c0:3600::103，跟下文 Worker 出站時的位址相同。這 2 筆出現在 Tunnel 那一節之後，這次部署的 Worker 程式沒有連這個主機名稱，送出它們的是什麼沒有查明。VCN 沒有開 IPv6、源站只有 A 紀錄，所以回源全部經由 IPv4；源站有 IPv6 時 Cloudflare 是否改用 IPv6 回源，沒有測。

SSL/TLS 模式「完整」與 Authenticated Origin Pulls

AOP 是 TLS 的用戶端憑證驗證，要求 Cloudflare 用 https 回源，所以先在主控台的 SSL/TLS → Configure 把加密模式從 Automatic 改成 Full（完整：回源用 https，不驗證源站憑證，接受自簽的）。Full (strict) 會驗證源站憑證，自簽的會失敗，要換成 Cloudflare 的 Origin CA 憑證或公開 CA 簽的憑證（依 Cloudflare 文件，沒有實跑）。改完之後回源改到 443，nginx 記到的驗證結果是 NONE（沒有出示用戶端憑證）：

1172.71.158.118 cfip=<管理者的公開 IP> host=verify-origin.<網域> ssl_client_verify=NONE "GET /?aop=before HTTP/1.1" 200

查詢字串 ?aop=before 只是用來在紀錄裡分辨這一批請求；在 zsh 裡網址要加引號，否則 ? 被當成萬用字元，zsh 回 no matches found、curl 沒有執行。接著在 SSL/TLS → Origin Server → Authenticated Origin Pulls 打開 Global（全域：使用 Cloudflare 共用的用戶端憑證）的開關，再連：

1verify-origin https from 172.69.23.187 client_verify=SUCCESS
2verify-origin https from 104.22.20.233 client_verify=SUCCESS

打開開關之後再連的那一批請求都出示了憑證，驗證成功（開關生效要多久沒有量）。再把 nginx 的 ssl_verify_client optional; 改成 on;（沒有有效用戶端憑證的連線一律拒絕），systemctl reload nginx，各連一次：

1curl -sk https://127.0.0.1/ | grep -o '[^<]*'</span>                            <span class="c1"># 在源站上直連，沒有用戶端憑證</span>
</span></span><span class="line"><span class="ln">2</span><span class="cl">curl -s -w <span class="s1">' [%{http_code}]\n'</span> <span class="s1">'https://verify-origin.<網域>/?aop=global-on'</span>       <span class="c1"># 在本機，經由 Cloudflare</span></span></span></code></pre></div>




<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl"><title>400 No required SSL certificate was sent
</span></span><span class="line"><span class="ln">2</span><span class="cl">verify-origin https from 172.69.23.187 client_verify=SUCCESS
</span></span><span class="line"><span class="ln">3</span><span class="cl"> [200]</span></span></code></pre></div><p>沒有用戶端憑證的直連被 nginx 回 400，經由 Cloudflare 的照常。從源站自己直連是因為 NSG 擋住了所有非 Cloudflare 的外部來源，外面的直連在 nginx 之前就到不了；這一步量的是 NSG 被拿掉或設錯時，nginx 這一層還擋不擋得住。</p>
<p>Global 用的是所有 Cloudflare 客戶共用的同一張憑證。Cloudflare 的〈Protect your origin server〉寫明，共用憑證只證明請求來自 Cloudflare 的網路：別人用自己的 Cloudflare 帳號把一個網域指向這台源站、也打開 Global 時，那些請求出示的是同一張憑證，nginx 同樣驗證成功。要分辨請求是否由自己的網域送來，就在 Zone-level（區域層級）或 Per-hostname（每個主機名稱）上傳自己的用戶端憑證，nginx 的 <code>ssl_client_certificate</code> 改成簽那張憑證的 CA。這兩種沒有實跑，「別人的帳號開 Global 也會通過」是依文件的說法，沒有用第二個帳號實測。</p>
<h2 id="cloudflare-worker-送出的請求出站位址只放行-cloudflare-的-nsg-與自己寫的-cf-connecting-ip">Cloudflare Worker 送出的請求：出站位址、只放行 Cloudflare 的 NSG 與自己寫的 CF-Connecting-IP</h2>
<p>Cloudflare Workers 是跑在 Cloudflare 邊緣的程式，它對外送出的請求從 Cloudflare 的位址出去。任何人都能用免費帳號部署一個 Worker，對任意主機名稱送請求，所以它可以代表「經由別的 Cloudflare 帳號送來的請求」；這次部署在自己的帳號，換成別的帳號時的結果寫在本節最後。Worker 要連一個主機名稱，這次沒有試直接 fetch IP 位址，用的是 <code>nip.io</code> 這個公開的 DNS 服務：<code><源站 IP 以連字號分隔>.nip.io</code> 解析到那個 IP。Worker 做三件事：問 <code>api.ipify.org</code> 自己出站的位址、連源站、帶著偽造的 <code>CF-Connecting-IP</code> 與 <code>X-Forwarded-For</code> 再連一次：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-javascript" data-lang="javascript"><span class="line"><span class="ln"> 1</span><span class="cl"><span class="c1">// index.js
</span></span></span><span class="line"><span class="ln"> 2</span><span class="cl"><span class="c1"></span><span class="kr">export</span> <span class="k">default</span> <span class="p">{</span>
</span></span><span class="line"><span class="ln"> 3</span><span class="cl">  <span class="kr">async</span> <span class="nx">fetch</span><span class="p">(</span><span class="nx">request</span><span class="p">)</span> <span class="p">{</span>
</span></span><span class="line"><span class="ln"> 4</span><span class="cl">    <span class="kr">const</span> <span class="nx">out</span> <span class="o">=</span> <span class="p">{};</span>
</span></span><span class="line"><span class="ln"> 5</span><span class="cl">    <span class="kr">const</span> <span class="nx">t</span> <span class="o">=</span> <span class="kr">async</span> <span class="p">(</span><span class="nx">label</span><span class="p">,</span> <span class="nx">url</span><span class="p">,</span> <span class="nx">init</span><span class="p">)</span> <span class="p">=></span> <span class="p">{</span>
</span></span><span class="line"><span class="ln"> 6</span><span class="cl">      <span class="k">try</span> <span class="p">{</span> <span class="kr">const</span> <span class="nx">r</span> <span class="o">=</span> <span class="kr">await</span> <span class="nx">fetch</span><span class="p">(</span><span class="nx">url</span><span class="p">,</span> <span class="nx">init</span><span class="p">);</span> <span class="nx">out</span><span class="p">[</span><span class="nx">label</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span> <span class="nx">status</span><span class="o">:</span> <span class="nx">r</span><span class="p">.</span><span class="nx">status</span><span class="p">,</span> <span class="nx">body</span><span class="o">:</span> <span class="p">(</span><span class="kr">await</span> <span class="nx">r</span><span class="p">.</span><span class="nx">text</span><span class="p">()).</span><span class="nx">slice</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="mi">200</span><span class="p">)</span> <span class="p">};</span> <span class="p">}</span>
</span></span><span class="line"><span class="ln"> 7</span><span class="cl">      <span class="k">catch</span> <span class="p">(</span><span class="nx">e</span><span class="p">)</span> <span class="p">{</span> <span class="nx">out</span><span class="p">[</span><span class="nx">label</span><span class="p">]</span> <span class="o">=</span> <span class="p">{</span> <span class="nx">error</span><span class="o">:</span> <span class="nb">String</span><span class="p">(</span><span class="nx">e</span><span class="p">)</span> <span class="p">};</span> <span class="p">}</span>
</span></span><span class="line"><span class="ln"> 8</span><span class="cl">    <span class="p">};</span>
</span></span><span class="line"><span class="ln"> 9</span><span class="cl">    <span class="kr">await</span> <span class="nx">t</span><span class="p">(</span><span class="s2">"egress_ipify"</span><span class="p">,</span> <span class="s2">"https://api.ipify.org?format=json"</span><span class="p">);</span>
</span></span><span class="line"><span class="ln">10</span><span class="cl">    <span class="kr">await</span> <span class="nx">t</span><span class="p">(</span><span class="s2">"origin_http"</span><span class="p">,</span> <span class="s2">"http://<源站 IP 以連字號分隔>.nip.io/"</span><span class="p">);</span>
</span></span><span class="line"><span class="ln">11</span><span class="cl">    <span class="kr">await</span> <span class="nx">t</span><span class="p">(</span><span class="s2">"origin_http_spoof"</span><span class="p">,</span> <span class="s2">"http://<源站 IP 以連字號分隔>.nip.io/spoof"</span><span class="p">,</span>
</span></span><span class="line"><span class="ln">12</span><span class="cl">      <span class="p">{</span> <span class="nx">headers</span><span class="o">:</span> <span class="p">{</span> <span class="s2">"CF-Connecting-IP"</span><span class="o">:</span> <span class="s2">"198.51.100.77"</span><span class="p">,</span> <span class="s2">"X-Forwarded-For"</span><span class="o">:</span> <span class="s2">"198.51.100.77"</span> <span class="p">}</span> <span class="p">});</span>
</span></span><span class="line"><span class="ln">13</span><span class="cl">    <span class="k">return</span> <span class="k">new</span> <span class="nx">Response</span><span class="p">(</span><span class="nx">JSON</span><span class="p">.</span><span class="nx">stringify</span><span class="p">(</span><span class="nx">out</span><span class="p">,</span> <span class="kc">null</span><span class="p">,</span> <span class="mi">2</span><span class="p">),</span> <span class="p">{</span> <span class="nx">headers</span><span class="o">:</span> <span class="p">{</span> <span class="s2">"content-type"</span><span class="o">:</span> <span class="s2">"application/json"</span> <span class="p">}</span> <span class="p">});</span>
</span></span><span class="line"><span class="ln">14</span><span class="cl">  <span class="p">},</span>
</span></span><span class="line"><span class="ln">15</span><span class="cl"><span class="p">};</span></span></span></code></pre></div>




<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-toml" data-lang="toml"><span class="line"><span class="ln">1</span><span class="cl"><span class="c"># wrangler.toml</span>
</span></span><span class="line"><span class="ln">2</span><span class="cl"><span class="nx">name</span> <span class="p">=</span> <span class="s2">"verify-origin-probe"</span>
</span></span><span class="line"><span class="ln">3</span><span class="cl"><span class="nx">main</span> <span class="p">=</span> <span class="s2">"index.js"</span>
</span></span><span class="line"><span class="ln">4</span><span class="cl"><span class="nx">compatibility_date</span> <span class="p">=</span> <span class="s2">"2026-10-01"</span>
</span></span><span class="line"><span class="ln">5</span><span class="cl"><span class="nx">workers_dev</span> <span class="p">=</span> <span class="kc">true</span></span></span></code></pre></div><p><code>compatibility_date</code> 決定 Worker 執行環境的行為版本，填部署當天或之前的日期；<code>workers_dev = true</code> 讓 Worker 部署到 <code>*.workers.dev</code> 網址，不用綁自己的網域。<code>198.51.100.77</code> 是文件保留位址，代表攻擊者想讓源站相信的訪客位址。部署並呼叫：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">npx wrangler deploy
</span></span><span class="line"><span class="ln">2</span><span class="cl">curl -s https://verify-origin-probe.<帳號的 workers.dev 子網域>.workers.dev/</span></span></code></pre></div><p>剛註冊 workers.dev 子網域之後的第一次呼叫，curl 回 <code>sslv3 alert handshake failure</code>：新子網域的憑證還沒發好；幾分鐘後再呼叫就正常了。</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">"egress_ipify": { "status": 200, "body": "{\"ip\":\"2a06:98c0:3600::103\"}" },
</span></span><span class="line"><span class="ln">2</span><span class="cl">"origin_http":  { "status": 200, "body": "verify-origin http from 104.22.17.80\n" },
</span></span><span class="line"><span class="ln">3</span><span class="cl">"origin_http_spoof": { "status": 200, "body": "verify-origin http from 104.22.17.80\n" }</span></span></code></pre></div><p>源站的存取紀錄：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">104.22.17.80 cfip=- host=<源站 IP 以連字號分隔>.nip.io ssl_client_verify=- "GET / HTTP/1.1" 200
</span></span><span class="line"><span class="ln">2</span><span class="cl">104.22.17.80 cfip=198.51.100.77 host=<源站 IP 以連字號分隔>.nip.io ssl_client_verify=- "GET /spoof HTTP/1.1" 200</span></span></code></pre></div><p>Worker 連 <code>api.ipify.org</code> 走的是 IPv6，出站位址 <code>2a06:98c0:3600::103</code> 落在 Cloudflare 公布的 <code>2a06:98c0::/29</code>；連只有 IPv4 的源站時用的是 <code>104.22.17.80</code>，落在 <code>104.16.0.0/13</code>。連源站的兩次請求都通過了只放行 Cloudflare IPv4 的 NSG。第二筆的 <code>cfip=198.51.100.77</code>：Worker 自己寫的 <code>CF-Connecting-IP</code> 原封不動送到源站，而連線的來源是 Cloudflare 的位址。</p>
<p>所以「只放行 Cloudflare 的位址之後，就能信任 <code>CF-Connecting-IP</code>」這個前提不成立：nginx 以 <code>set_real_ip_from <Cloudflare 的位址段></code> 加 <code>real_ip_header CF-Connecting-IP</code> 取訪客位址時，這一筆會被記成 <code>198.51.100.77</code>，依訪客位址做的存取紀錄、速率限制與封鎖都被騙過。擋下這一類要靠回源驗證：Zone-level 或 Per-hostname 的 AOP（Worker 對 http 的源站連線不帶用戶端憑證，對 https 的是否帶共用憑證沒有測），或改用 Tunnel、源站不收任何外部的入站連線。這次的 Worker 連的是 http 的 80；源站的 443 用自簽憑證，依推論 Worker 的 fetch 會驗證憑證而失敗，所以沒有測 Worker 對 443 的結果。</p>
<p>這次的 Worker 在自己的帳號裡，但它連的 <code>nip.io</code> 不屬於任何 Cloudflare 的網域，請求不經過自己網域的任何設定，依這條路徑推論，換成任何一個免費帳號結果都一樣；沒有用第二個帳號實測。測完刪掉 Worker：<code>npx wrangler delete --name verify-origin-probe --force</code>。</p>
<h2 id="cloudflare-tunnel源站不開入站以及出站要放行的連接埠">Cloudflare Tunnel：源站不開入站，以及出站要放行的連接埠</h2>
<p>Tunnel 由源站上的 cloudflared 主動往外連到 Cloudflare，請求經由這條連線送進來。quick tunnel 不需要帳號：cloudflared 向 Cloudflare 要一個隨機的 <code>*.trycloudflare.com</code> 網址，把它接到本機的一個服務。後端只聽本機位址：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln"> 1</span><span class="cl">dnf -y install https://github.com/cloudflare/cloudflared/releases/download/2026.10.3/cloudflared-linux-aarch64.rpm
</span></span><span class="line"><span class="ln"> 2</span><span class="cl">cat > /etc/nginx/conf.d/verify2-tunnel.conf <span class="s"><<'EOF'
</span></span></span><span class="line"><span class="ln"> 3</span><span class="cl"><span class="s">server {
</span></span></span><span class="line"><span class="ln"> 4</span><span class="cl"><span class="s">    listen 127.0.0.1:8080;
</span></span></span><span class="line"><span class="ln"> 5</span><span class="cl"><span class="s">    access_log /var/log/nginx/verify.log verify;
</span></span></span><span class="line"><span class="ln"> 6</span><span class="cl"><span class="s">    location / { default_type text/plain; return 200 "verify-origin tunnel backend, remote_addr=$remote_addr cfip=$http_cf_connecting_ip\n"; }
</span></span></span><span class="line"><span class="ln"> 7</span><span class="cl"><span class="s">}
</span></span></span><span class="line"><span class="ln"> 8</span><span class="cl"><span class="s">EOF</span>
</span></span><span class="line"><span class="ln"> 9</span><span class="cl">nginx -t <span class="o">&&</span> systemctl reload nginx
</span></span><span class="line"><span class="ln">10</span><span class="cl">nohup cloudflared tunnel --no-autoupdate --url http://127.0.0.1:8080 >/var/tmp/verify-tunnel.log 2><span class="p">&</span><span class="m">1</span> <span class="p">&</span>
</span></span><span class="line"><span class="ln">11</span><span class="cl">sleep <span class="m">10</span>                                    <span class="c1"># 等 cloudflared 拿到網址、寫進 log</span>
</span></span><span class="line"><span class="ln">12</span><span class="cl">grep -oE <span class="s1">'https://[a-z0-9-]+\.trycloudflare\.com'</span> /var/tmp/verify-tunnel.log
</span></span><span class="line"><span class="ln">13</span><span class="cl">grep -E <span class="s1">'Initial protocol|Registered tunnel connection'</span> /var/tmp/verify-tunnel.log</span></span></code></pre></div><p><code>2026.10.3</code> 是 2026-10-21 發佈的版本，x86 主機換成 <code>cloudflared-linux-x86_64.rpm</code>，照抄之前到 GitHub 的 releases 頁看最新版。設定檔叫 <code>verify2-tunnel.conf</code> 而不是 <code>verify-tunnel.conf</code>：<code>conf.d</code> 依檔名排序載入，<code>-</code>（0x2D）排在 <code>.</code>（0x2E）前面，<code>verify-tunnel.conf</code> 會先於 <code>verify.conf</code> 載入，它用到的 <code>log_format verify</code> 還沒定義，<code>nginx -t</code> 失敗。</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">INF Initial protocol quic
</span></span><span class="line"><span class="ln">2</span><span class="cl">INF Registered tunnel connection connIndex=0 ... ip=198.41.200.13 location=sin22 protocol=quic</span></span></code></pre></div><p>從本機連印出來的網址，三次都回 200，後端記到的 <code>remote_addr</code> 是 <code>127.0.0.1</code>（cloudflared 從本機連進來），<code>cfip</code> 是本機的公開 IP。後端只聽 <code>127.0.0.1:8080</code>，NSG 與主機防火牆都沒有放行 8080：Tunnel 的請求不經過任何入站規則。cloudflared 預設用 QUIC（UDP）連 Cloudflare 的邊緣，連到 <code>198.41.200.13</code>，位置是新加坡（<code>sin22</code>）。</p>
<p>接著在源站上建一張自己的 nftables 表擋出站，分三步收緊，每一步都要重新啟動 cloudflared、等它試完再量。<code>--no-autoupdate</code> 讓 cloudflared 不在測試中途自己更新並重啟。先擋 UDP 7844、協定照預設：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">nft add table inet verify_tunnel
</span></span><span class="line"><span class="ln">2</span><span class="cl">nft add chain inet verify_tunnel output <span class="s1">'{ type filter hook output priority filter; policy accept; }'</span>
</span></span><span class="line"><span class="ln">3</span><span class="cl">nft add rule inet verify_tunnel output udp dport <span class="m">7844</span> drop
</span></span><span class="line"><span class="ln">4</span><span class="cl">pkill -x cloudflared<span class="p">;</span> sleep 1<span class="p">;</span> nohup cloudflared tunnel --no-autoupdate --url http://127.0.0.1:8080 >/var/tmp/verify-tunnel.log 2><span class="p">&</span><span class="m">1</span> <span class="p">&</span>
</span></span><span class="line"><span class="ln">5</span><span class="cl">sleep 10<span class="p">;</span> grep -oE <span class="s1">'https://[a-z0-9-]+\.trycloudflare\.com'</span> /var/tmp/verify-tunnel.log
</span></span><span class="line"><span class="ln">6</span><span class="cl">grep -c <span class="s1">'Failed to dial a quic connection'</span> /var/tmp/verify-tunnel.log   <span class="c1"># 隔幾分鐘再看一次，數字一直增加</span></span></span></code></pre></div><p>從本機連新的網址。實測等了 7 分鐘，失敗計數到 28 次，網址一直回 530。實測用的是一支包著這些指令的腳本；這三個區塊裡的 <code>grep</code> 依那次 log 的訊息原文寫成，沒有照這個形式逐條跑過。接著改成 http2、UDP 仍擋著：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">pkill -x cloudflared<span class="p">;</span> sleep 1<span class="p">;</span> nohup cloudflared tunnel --no-autoupdate --protocol http2 --url http://127.0.0.1:8080 >/var/tmp/verify-tunnel.log 2><span class="p">&</span><span class="m">1</span> <span class="p">&</span>
</span></span><span class="line"><span class="ln">2</span><span class="cl">sleep 10<span class="p">;</span> grep -oE <span class="s1">'https://[a-z0-9-]+\.trycloudflare\.com'</span> /var/tmp/verify-tunnel.log
</span></span><span class="line"><span class="ln">3</span><span class="cl">grep -E <span class="s1">'Registered tunnel connection'</span> /var/tmp/verify-tunnel.log</span></span></code></pre></div><p>最後把 TCP 7844 也擋掉，協定仍是 http2：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">nft add rule inet verify_tunnel output tcp dport <span class="m">7844</span> drop
</span></span><span class="line"><span class="ln">2</span><span class="cl">pkill -x cloudflared<span class="p">;</span> sleep 1<span class="p">;</span> nohup cloudflared tunnel --no-autoupdate --protocol http2 --url http://127.0.0.1:8080 >/var/tmp/verify-tunnel.log 2><span class="p">&</span><span class="m">1</span> <span class="p">&</span>
</span></span><span class="line"><span class="ln">3</span><span class="cl">sleep 30<span class="p">;</span> grep -oE <span class="s1">'https://[a-z0-9-]+\.trycloudflare\.com'</span> /var/tmp/verify-tunnel.log<span class="p">;</span> grep -E <span class="s1">'i/o timeout'</span> /var/tmp/verify-tunnel.log <span class="p">|</span> tail -1</span></span></code></pre></div><p>quick tunnel 每次啟動都拿到不同的網址，每一步都從本機連那一步印出的網址。</p>
<table>
  <thead>
      <tr>
          <th>出站限制</th>
          <th>cloudflared 的啟動參數</th>
          <th>結果</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>沒有限制</td>
          <td>預設</td>
          <td>QUIC 連上，網址回 200</td>
      </tr>
      <tr>
          <td>擋 UDP 7844</td>
          <td>預設</td>
          <td>QUIC 一直失敗（<code>sendmsg: operation not permitted</code>），等了 7 分鐘、失敗 28 次，沒有改用 http2；網址回 530（Cloudflare 錯誤 1033）</td>
      </tr>
      <tr>
          <td>擋 UDP 7844</td>
          <td><code>--protocol http2</code></td>
          <td>經由 TCP 連到 <code>198.41.192.37:7844</code>，網址回 200</td>
      </tr>
      <tr>
          <td>擋 UDP 與 TCP 7844</td>
          <td><code>--protocol http2</code></td>
          <td><code>dial tcp …:7844: i/o timeout</code>，沒有連線；網址回 530</td>
      </tr>
  </tbody>
</table>
<p>擋掉 UDP 時，cloudflared 的預先檢查印出 <code>suggested_protocol=http2</code>，但 quick tunnel 的設定是 <code>protocol:quic</code>，它照樣只重試 QUIC。所以出站只放行清單的主機上，cloudflared 要的是 7844：UDP 給 QUIC，TCP 給 http2；只開 TCP 時要明確指定 <code>--protocol http2</code>（或在設定檔寫 <code>protocol: http2</code>）。具名的 tunnel（綁在帳號上、由主控台或設定檔管理）的預設協定是否同樣不自動改用 http2，沒有測。兩個 7844 都擋時，quick tunnel 照樣拿到網址；只擋 UDP 的那兩次，<code>ss -tanp | grep cloudflared</code> 列得出取網址那一步的連線是 <code>104.16.230.132:443</code>，所以取網址走 443，後續的連線註冊才走 7844。</p>
<p>這一節的限制寫在自建的 nftables 表上，不經過 firewalld，測完 <code>nft delete table inet verify_tunnel</code> 拿掉。</p>
<h2 id="清理與-cloudflare-設定的還原">清理與 Cloudflare 設定的還原</h2>
<p>Cloudflare 那一側照建立的反方向還原，每一步看主控台的頁面或查詢結果確認：</p>
<ol>
<li><strong>Worker</strong>：<code>npx wrangler delete --name verify-origin-probe --force</code>，回 <code>Successfully deleted verify-origin-probe</code>。帳號的 workers.dev 子網域留著，它沒有費用，是否刪除由帳號擁有者決定。</li>
<li><strong>AOP</strong>：Authenticated Origin Pulls 的 Global 開關關掉。</li>
<li><strong>SSL/TLS 模式</strong>：改回 Automatic SSL/TLS。改回之後頁面顯示「Current encryption mode: Full」：自動模式沿用最後一次的模式，要等下一次自動掃描（頁面寫著下次掃描的日期）才重新判斷，原本實際套用的 Flexible 沒有立刻回來。改回之前網域上沒有其他經過代理的網站紀錄時，這個差別不影響任何流量。</li>
<li><strong>DNS 紀錄</strong>：刪掉 <code>verify-origin</code> 那一筆。<code>dig @<網域的權威 nameserver> verify-origin.<網域> A</code> 回 <code>NXDOMAIN</code>，網域原有的紀錄還在。</li>
</ol>
<p>Oracle Cloud 那一側，主機要先終止，NSG、子網路、security list、route table、internet gateway 才刪得掉，順序跟建立相反：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">oci compute instance terminate --instance-id <span class="s2">"</span><span class="nv">$INST</span><span class="s2">"</span> --preserve-boot-volume <span class="nb">false</span> --force
</span></span><span class="line"><span class="ln">2</span><span class="cl">oci compute instance get --instance-id <span class="s2">"</span><span class="nv">$INST</span><span class="s2">"</span> --query <span class="s1">'data."lifecycle-state"'</span> --raw-output   <span class="c1"># 重複查，直到回 TERMINATED</span>
</span></span><span class="line"><span class="ln">3</span><span class="cl">oci network nsg delete --nsg-id <span class="s2">"</span><span class="nv">$NSG</span><span class="s2">"</span> --force --wait-for-state TERMINATED
</span></span><span class="line"><span class="ln">4</span><span class="cl">oci network subnet delete --subnet-id <span class="s2">"</span><span class="nv">$SNP</span><span class="s2">"</span> --force --wait-for-state TERMINATED
</span></span><span class="line"><span class="ln">5</span><span class="cl">oci network security-list delete --security-list-id <span class="s2">"</span><span class="nv">$SLP</span><span class="s2">"</span> --force --wait-for-state TERMINATED
</span></span><span class="line"><span class="ln">6</span><span class="cl">oci network route-table delete --rt-id <span class="s2">"</span><span class="nv">$RTP</span><span class="s2">"</span> --force --wait-for-state TERMINATED
</span></span><span class="line"><span class="ln">7</span><span class="cl">oci network internet-gateway delete --ig-id <span class="s2">"</span><span class="nv">$IGW</span><span class="s2">"</span> --force --wait-for-state TERMINATED</span></span></code></pre></div><p>主機還在時刪其他資源，各自回的錯誤指出是誰還在引用它：NSG 回 <code>PreconditionFailed</code>（<code>cannot be deleted since it still has vnics attached to it</code>），子網路回 <code>Conflict</code>（<code>references the VNIC</code>），security list 與 route table 回 <code>IncorrectState</code>（<code>associated with … that is in use</code>），internet gateway 回 <code>Conflict</code>（<code>The Route Table … references the Internet Gateway</code>）。這次第一次的終止指令寫在腳本裡、帶 <code>--wait-for-state TERMINATED</code> 且輸出被導到 <code>/dev/null</code>，執行之後主機還是 RUNNING，後面每一步都回上面的錯誤。原因推定是 <code>terminate</code> 的 <code>--wait-for-state</code> 只收 work request 的狀態（<code>ACCEPTED</code>、<code>IN_PROGRESS</code>、<code>FAILED</code>、<code>SUCCEEDED</code>），不收主機的 <code>TERMINATED</code>：2026-10-27 用同一個 CLI 版本（3.95.1）同樣寫成 <code>TERMINATED</code> 時，CLI 印 <code>Invalid value for '--wait-for-state': invalid choice: TERMINATED.</code>、以 2 結束，請求沒有送出（實跑）；第一次清理時的 stderr 沒有留下，所以那一次的原因是從這次重現推回去的。那支腳本沒有檢查這一條的結束碼，照樣往下跑。要等它刪完，寫成 <code>--wait-for-state SUCCEEDED --wait-for-state FAILED</code>（同一天實跑，66 秒 <code>SUCCEEDED</code>，見 <a href="/blog/devops/infra/cloud-providers/oracle-cloud/hands-on/suspend-resume-drill/" data-link-title="Oracle Cloud 主機的暫停與恢復上線實測紀錄：暫停前的基準、收窄入口、停止主機、停止期間的計費與 Cloudflare 的回應、恢復上線的每一步與耗時，以及收尾時 DNS 紀錄與主機的刪除順序" data-link-desc="要讓 Oracle Cloud 上一台放在 Cloudflare 後面的主機停機一段時間再恢復上線、想知道停止之後公開 IP 留不留、停止期間 A1 與開機磁碟怎麼計費、Cloudflare 回什麼錯誤、恢復時每一步要多久，或服務要收掉時 DNS 紀錄與主機的刪除順序時，查實際跑過的指令、輸出與量到的時間">Oracle Cloud 主機的暫停與恢復上線實測紀錄：暫停前的基準、收窄入口、停止主機、停止期間的計費與 Cloudflare 的回應、恢復上線的每一步與耗時，以及收尾時 DNS 紀錄與主機的刪除順序</a>〈收尾：DNS 紀錄、主機與網路資源的刪除順序〉）。單獨再下一次不帶等待的終止指令，回應裡帶 <code>opc-work-request-id</code>，主機進入 TERMINATING。<code>--preserve-boot-volume false</code> 讓開機磁碟一起刪掉，免費額度的區塊儲存才會釋放。刪完之後每一個 <code>get</code> 都回 <code>NotAuthorizedOrNotFound</code>，主機、子網路與 Cloudflare 上的測試設定都已刪除或還原。</p>
<h2 id="nsg回源位址aopworker-與-quick-tunnel-的量測結果">NSG、回源位址、AOP、Worker 與 quick tunnel 的量測結果</h2>
<table>
  <thead>
      <tr>
          <th>項目</th>
          <th>結果</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>NSG 的規則數</td>
          <td>每次 API 呼叫最多 25 條；一個 NSG 最多 120 條（入站加出站），超過時整批被拒</td>
      </tr>
      <tr>
          <td>從 Cloudflare 範圍外直連源站</td>
          <td>NSG 只放行 Cloudflare 的 IPv4 時逾時</td>
      </tr>
      <tr>
          <td>回源的來源位址</td>
          <td>37 筆、12 個位址，全部在公布的 IPv4 清單裡；Flexible 模式回源走 http 的 80</td>
      </tr>
      <tr>
          <td>AOP 的 Global</td>
          <td>開啟後回源出示憑證、驗證 <code>SUCCESS</code>；nginx <code>ssl_verify_client on</code> 時沒有憑證的直連回 400；共用憑證只證明請求來自 Cloudflare 的網路（依文件）</td>
      </tr>
      <tr>
          <td>Worker（自己的帳號，連不屬於 Cloudflare 網域的主機名稱）</td>
          <td>出站位址在公布的清單裡，穿過只放行 Cloudflare 的 NSG；它寫的 <code>CF-Connecting-IP</code> 原樣送到源站；換成別的帳號依路徑推論相同</td>
      </tr>
      <tr>
          <td>quick tunnel</td>
          <td>後端只聽 127.0.0.1、沒有入站放行也連得到；預設 QUIC（UDP 7844），擋掉 UDP 時不自動改用 http2；<code>--protocol http2</code> 用 TCP 7844</td>
      </tr>
  </tbody>
</table>

</article>
<article>
<h1>CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖</h1>
<p>Sun, 25 Oct 2026 00:00:00 +0800</p>
<p>這篇整理網站放在 <a href="/blog/devops/infra/knowledge-cards/cdn/" data-link-title="CDN（內容遞送網路）" data-link-desc="網站要放到 Cloudflare 這類服務後面、看到回應標頭帶著 CDN 的標記、或要判斷源站看到的來源位址是誰時，查 CDN 代替源站接收連線的方式、回源與它對源站防火牆的影響">CDN</a>（內容遞送網路，content delivery network：代替源站接收使用者連線、在邊緣做快取與過濾的服務，例如 Cloudflare）後面時，源站主機的防火牆要限制什麼、限制放在哪裡：請求避開 CDN 直接連到源站的成因（源站位址從 DNS 歷史紀錄、憑證透明度紀錄與其他記錄外洩）、來源限制放在雲端防火牆、主機防火牆或 CDN 端驗證時各自擋得住什麼、只放行 CDN 位址的規則什麼時候套上去、管理通道與同一台主機上不經 CDN 的服務怎麼處理、Docker 發佈的連接埠為什麼不受 <code>ufw</code> 與 <code>firewalld</code> 的一般規則約束、Podman 與 rootless 模式的容器在這一點上的差異，以及不發佈、只發佈在本機位址、<a href="/blog/devops/infra/knowledge-cards/docker-user/" data-link-title="DOCKER-USER（Docker 留給使用者的轉送規則鏈）" data-link-desc="要在 Docker 發佈的連接埠上加來源限制、寫進 DOCKER-USER 的規則在防火牆重新載入或重開機之後不見、或規則擋到了容器自己往外的連線時，查這條鏈在轉送路徑上的位置、比對原始連接埠的寫法與規則的存續條件"><code>DOCKER-USER</code></a> 鏈、firewalld 的 <code>StrictForwardPorts</code>、掛在位址轉換之前的 nftables 表、雲端防火牆與 Cloudflare Tunnel 這幾種做法、出站的 DNS 只准送往指定解析器擋得住與擋不住的部分，以及地理封鎖放在 CDN 邊緣的理由。</p>
<p>機制以 Linux 主機、Cloudflare 與以 root 執行的 Docker（預設的 iptables 後端；compose 發佈連接埠的方式與 <code>docker run -p</code> 相同）說明。其他 CDN 對應的是它公佈的、連回源站時使用的位址清單與它的回源驗證功能。Podman 與 rootless 模式的 Docker 轉送連接埠的方式不同，判斷的依據相同（容器執行環境有沒有在主機防火牆之前改寫封包的目的地），各自量到的結果見〈Docker 發佈的連接埠：封包路徑與限制的寫法〉裡 Docker 以外的容器執行方式那一段；Kubernetes 的 NodePort 沒有驗證。</p>
<p>指令與輸出逐步記在下列實測紀錄，下文寫「實測」的地方都出自它們：<a href="/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a> 在 Oracle Linux 10 的 firewalld 2.4.3 與 Docker 29.9.2 上，用一個位址落在 Cloudflare 範圍內、一個落在範圍外的兩個測試來源，量了每一種限制寫法擋不擋得住，以及規則在 firewalld 重新載入、dockerd 重啟與重開機之後還在不在；<a href="/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a> 在 Ubuntu 的 ufw 上量同一組問題；<a href="/blog/devops/infra/03-network-foundation/hands-on/podman-rootless-ports-walkthrough/" data-link-title="Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址" data-link-desc="用 Podman 或 rootless 模式的 Docker 發佈連接埠、想知道 ufw 或 firewalld 的規則管不管得到、或想在容器裡拿到連線的真實來源位址時，查 rootful Podman 在 ufw 與 firewalld 上的不同結果、rootless 模式接收連線的路徑，以及容器看到的來源位址">Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址</a> 換成其他容器執行方式；<a href="/blog/devops/infra/03-network-foundation/hands-on/cloudflare-origin-pull-walkthrough/" data-link-title="Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠" data-link-desc="源站要放在 Cloudflare 後面、想確認只放行 Cloudflare 位址的雲端防火牆放不放得下整份清單、回源實際用哪些位址、Authenticated Origin Pulls 怎麼驗證、Cloudflare Worker 能不能穿過這道防火牆並偽造 CF-Connecting-IP、或 Tunnel 要開哪些出站連接埠時，查 Oracle Cloud 與 Cloudflare 免費方案上實際跑過的指令與輸出">Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠</a> 接上實際的 Cloudflare 帳號，讓 Cloudflare 回源到一台 Oracle Cloud 主機。管理員登入主機那條通道的設計另見 <a href="/blog/devops/infra/03-network-foundation/management-access-channel/" data-link-title="伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口" data-link-desc="與雲端廠商無關、適用於雲端 VM、地端主機與 VPS 的管理員登入通道設計：拆成網路可達性、通道授權與主機登入驗證的模型，各層的做法（來源白名單、跳板機、VPN、身分感知代理、代理程式反向連線、SSH 憑證）、更換 port 與 fail2ban 改不了的部分，依存取者身分、連線送達方式、收回方式選擇組合的依據，以及移除公開 IP 之後的出站路徑、切換順序、救援入口、組織護欄與稽核">伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口</a>，請求從 DNS 到應用經過哪幾層見 <a href="/blog/devops/infra/03-network-foundation/traffic-entry-layer/" data-link-title="流量入口層 — 請求怎麼從使用者到達應用" data-link-desc="自管環境要決定請求從使用者到應用經過哪幾層入口、每層承擔什麼——TLS 終結的位置、動靜分離、單機 reverse proxy 與雲端負載平衡器的選擇">流量入口層 — 請求怎麼從使用者到達應用</a>，CDN 本身的分發責任見 <a href="/blog/backend/05-deployment-platform/edge-cdn-static-distribution/" data-link-title="5.9 邊緣分發與靜態資源（CDN / Origin Protection）" data-link-desc="整理 CDN 與 edge cache 在部署平台中的責任邊界、origin protection、purge 與 invalidation 策略">5.9 邊緣分發與靜態資源（CDN / Origin Protection）</a>（那一篇的 origin protection 指的是快取未命中時保護源站的負載，跟這篇的安全限制是兩件事）。</p>
<h2 id="主機前面有-cdn-時連到源站的路徑經由-cdn直連公開-ip-與管理通道">主機前面有 CDN 時連到源站的路徑：經由 CDN、直連公開 IP 與管理通道</h2>
<p>源站（origin server）是實際跑網站程式的主機，CDN 收到使用者的請求之後，從自己的機房連回源站取回應，這個動作叫回源。網域的 DNS 記錄設成經由 CDN 代理時，使用者解析網域拿到的是 CDN 的位址，請求先到 CDN，CDN 再用它自己的位址連到源站。這時連得到源站的路徑有三條：</p>
<ul>
<li><strong>經由 CDN 回源</strong>：使用者連 CDN，CDN 連源站的 80 或 443。源站看到的來源位址是 CDN 機房的位址，使用者真正的位址放在 CDN 加上的 HTTP 標頭裡（Cloudflare 是 <code>CF-Connecting-IP</code>）。</li>
<li><strong>直連源站的公開 IP</strong>：知道源站位址的人跳過 CDN，直接對源站的 80、443 或其他對外的連接埠送請求。CDN 上設定的 <a href="/blog/backend/knowledge-cards/waf/" data-link-title="WAF" data-link-desc="說明 Web Application Firewall 如何在入口層過濾常見攻擊與濫用">WAF</a>（Web 應用程式防火牆：依規則檢查 HTTP 請求內容並攔下可疑請求的元件）規則、速率限制與地理封鎖都在 CDN 那一端執行，這條路徑上沒有任何一條會作用。</li>
<li><strong>管理通道</strong>：管理員登入主機的 SSH，或經由雲端業者的代理（Oracle Cloud 的 Bastion、GCP 的 IAP）。這條路徑跟網站流量無關，CDN 也不經手。</li>
</ul>
<p>CDN 帶來的保護只對經由 CDN 回源那條路徑成立。一個漏洞公開之後，掃描程式會對網際網路上的主機送出探測請求；源站主機的防火牆對全網開放 80 與 443 時，這些請求可以走直連公開 IP 那條路徑送到源站，CDN 上為這個漏洞加的每一條規則都碰不到它們。直連那條路徑開著還有一個影響：直連的人可以自己在請求裡寫一個假的 <code>CF-Connecting-IP</code>，源站的存取記錄、速率限制與依國家的判斷照這個標頭做時都會被騙。反向代理的設定裡只信任來自 CDN 位址段的這個標頭（nginx 是 <code>set_real_ip_from</code> 加 <code>real_ip_header</code>），擋下的是不經過 CDN 的直連；從 CDN 位址送來的請求不一定是 CDN 替這個網域轉送的：實測用一個 Cloudflare Worker（任何帳號都能部署、從 Cloudflare 的位址對外連線的程式）連到只放行 Cloudflare 位址的源站，Worker 自己寫的 <code>CF-Connecting-IP</code> 原封不動送到了源站。這個標頭要能信任，源站還要能確認請求是 CDN 替自己的網域送來的，做法在〈限制放在哪一層：雲端防火牆、主機防火牆與 CDN 端的驗證〉。</p>
<h2 id="讓請求避開-cdn-的成因源站位址從哪裡外洩">讓請求避開 CDN 的成因：源站位址從哪裡外洩</h2>
<p>直連源站要先知道源站的位址，而這個位址的來源比網域的 A 記錄多。Cloudflare 的〈Protect your origin server〉列出的外洩來源有：接上 CDN 之前的 DNS 歷史紀錄（DNS 歷史查詢服務保留了網域過去解析到的位址，接上 CDN 之後舊記錄仍查得到）、沒有經由 CDN 代理的記錄（<code>mail</code>、<code>ftp</code> 這類子網域的 A 記錄，以及寫著 IP 的 SPF、TXT 記錄；SPF 是寫在 TXT 記錄裡、列出允許替這個網域寄信的主機的設定），以及跟網站同一台主機收發郵件時，退信會帶出主機的位址。Cloudflare 那一頁沒有列、但同樣公開的另一個來源是憑證透明度紀錄（certificate transparency log）：每一張公開簽發的 TLS 憑證都記在公開的日誌裡，源站曾經用自己的位址對外提供 HTTPS 時，掃描服務把憑證上的網域與當時回應的位址對起來。另外，網際網路上的掃描程式不必先知道網域：它們對整段 IP 位址逐一連 80 與 443，碰到回應的主機就送出探測請求，所以位址從未外洩的源站一樣會被掃到。</p>
<p>源站的位址因此要當成已經公開，防護要直接寫在源站能被連到的位置上：只有經由 CDN 的請求連得進來，直連公開 IP 那條路徑才會關上。Cloudflare 那一頁另外建議接上 CDN 之後更換源站的 IP，讓歷史紀錄裡的位址失效。</p>
<h2 id="限制放在哪一層雲端防火牆主機防火牆與-cdn-端的驗證">限制放在哪一層：雲端防火牆、主機防火牆與 CDN 端的驗證</h2>
<p>「只讓 CDN 連進來」可以寫在三個位置，它們擋的範圍與失效的方式不同：</p>
<ul>
<li><strong>雲端防火牆</strong>（Oracle Cloud 的 security list 與 NSG（network security group，套在網卡上的一組放行規則）、AWS 的 <a href="/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">security group</a>、GCP 的 VPC 防火牆規則，位置與合併方式見 <a href="/blog/devops/infra/cloud-providers/vm-options/networking/" data-link-title="網路：subnet、私有 IP、公開 IP 與防火牆規則" data-link-desc="雲端主機建立頁網路區塊的選項：主機放進哪個虛擬網路與 subnet、私有 IP 與公開 IP 各自的用途與生命週期、防火牆規則掛在 subnet、網卡與作業系統哪一個位置以及各家怎麼合併，以及主控台新建的網路預設對外開放了什麼">網路：subnet、私有 IP、公開 IP 與防火牆規則</a> 的〈防火牆規則的位置與合併方式〉）：規則在業者的網路上執行，被擋的封包到不了主機，主機上跑什麼程式、程式怎麼改寫主機的防火牆都不影響它。要評估的是規則數：Cloudflare 在 2026-10-25 公佈的是 15 段 IPv4 與 7 段 IPv6，一條規則能放幾段來源、一組規則能放幾條，每一家業者的配額不同。Oracle Cloud 的 NSG 與 AWS 的 security group 一條規則只放一段來源，條數是「段數 × 要放行的連接埠數」：只放行 80 與 443 時 IPv4 是 30 條、加上 IPv6 是 44 條，實測 Oracle 的 NSG 上限是入站加出站合計 120 條，AWS 的 security group 文件寫的預設上限是入站 60 條、IPv4 與 IPv6 分開算，兩家都放得下；GCP 的 VPC 防火牆規則一條可以放 5000 段來源，IPv4 與 IPv6 各一條就放下了（GCP 與 AWS 依文件，沒有實測）。清單變動時也要有人改規則：一條規則只放一段時，每次更新是逐條增刪；AWS 可以改用自建的 prefix list，更新的是 list 的項目，security group 的規則不動，而 prefix list 被引用時以它設定的最大項數計入規則數（依文件，沒有實測）。</li>
<li><strong>主機防火牆</strong>（<code>firewalld</code>、<code>ufw</code>、<code>nftables</code>）：在主機的核心裡執行，可以用 ipset（核心裡的一個位址集合，一條規則比對整個集合）一次放進整份清單，也能寫出只對某個連接埠生效的規則。它管不到的是在它之前就改寫封包目的地的程式，Docker 是最常見的一個，機制見〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。</li>
<li><strong>CDN 端的驗證</strong>：源站確認請求是 CDN 替這個網域送來的，而不只是來自 CDN 的位址。Cloudflare 的做法有兩種：Authenticated Origin Pulls 讓 Cloudflare 回源時出示用戶端憑證，源站的 TLS 設定只接受帶這張憑證的連線；Cloudflare Tunnel 由源站上的 <code>cloudflared</code> 主動往外連到 Cloudflare，請求經由這條往外建好的連線送進來（<a href="/blog/backend/knowledge-cards/outbound-tunnel/" data-link-title="Outbound Tunnel" data-link-desc="反向隧道把出站連線轉成可達入口、與傳統 port-forward 的責任倒轉">outbound tunnel</a> 的一種）。Authenticated Origin Pulls 用 Cloudflare 預設的共用憑證（主控台的 Global 開關）時，〈Protect your origin server〉寫明它只保證請求來自 Cloudflare 的網路；要分辨請求是否由自己的網域送來，要改用自己上傳的用戶端憑證（設在 Cloudflare 的 zone 層級，也就是一個網域的設定單位，或每個主機名稱各一張）。實測打開 Global 之後，Cloudflare 回源時出示憑證、nginx 驗證成功，nginx 設成必須有憑證時，沒有憑證的直連被回 400（nginx 的設定與輸出在 <a href="/blog/devops/infra/03-network-foundation/hands-on/cloudflare-origin-pull-walkthrough/" data-link-title="Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠" data-link-desc="源站要放在 Cloudflare 後面、想確認只放行 Cloudflare 位址的雲端防火牆放不放得下整份清單、回源實際用哪些位址、Authenticated Origin Pulls 怎麼驗證、Cloudflare Worker 能不能穿過這道防火牆並偽造 CF-Connecting-IP、或 Tunnel 要開哪些出站連接埠時，查 Oracle Cloud 與 Cloudflare 免費方案上實際跑過的指令與輸出">Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠</a> 的〈SSL/TLS 模式「完整」與 Authenticated Origin Pulls〉）；自己上傳憑證的那兩種沒有實跑。</li>
</ul>
<p>雲端防火牆與主機防火牆比對的是來源位址，而 CDN 的位址由所有客戶共用。別人也可以用自己的 Cloudflare 帳號，把一個網域指向這台源站的位址，或部署一個 Worker 直接對源站送請求；這些請求同樣從 Cloudflare 的位址送來，通過只放行 CDN 位址的規則，而源站擁有者在自己帳號上設的 WAF 規則管不到別人帳號送來的請求。Worker 這一條實測過，用的是自己帳號的 Worker，連一個不屬於任何 Cloudflare 網域的主機名稱：Worker 出站的位址落在 Cloudflare 公布的清單裡，穿過了只放行 Cloudflare 位址的 Oracle Cloud NSG，它在請求裡寫的 <code>CF-Connecting-IP</code> 也原樣送到源站。下面兩條是推論，都沒有用第二個帳號實測：Worker 這條路徑不經過帳號裡任何網域的設定，所以換成別人的帳號結果相同；別人把自己帳號裡的網域指向這台源站時，回源請求同樣從共用的 Cloudflare 位址送來，所以同樣通過只放行位址的規則。把這一類稱為<strong>經由別的 CDN 帳號送來的請求</strong>：只放行位址的規則擋不住它；共用憑證的 Authenticated Origin Pulls 擋不住別人帳號裡同樣打開 Global 的網域（依文件），Worker 對 https 源站的請求會不會帶這張共用憑證沒有測；擋住整類要用自己上傳憑證的 Authenticated Origin Pulls 或 Tunnel。只放行位址的規則擋下的是不經過 CDN 的直連，漏洞公開後對整段位址的掃描就屬於這一類。自己上傳憑證的 Authenticated Origin Pulls 以外，還有幾種讓源站分辨請求屬於自己網域的做法，這次都沒有實跑：在自己的 zone 用 Cloudflare 的規則替回源請求加一個只有自己知道的標頭、源站驗證它；或用 Cloudflare Access 的 service token。三個位置可以疊加，例如雲端防火牆只放行 CDN 位址到 443，源站的 TLS 設定再驗證自己上傳的用戶端憑證，主機防火牆則管住雲端防火牆碰不到的出站流量與主機上的其他連接埠。用戶端憑證只在 TLS 上驗證，80 上的 http 請求不帶憑證：80 也放行時，依 <code>CF-Connecting-IP</code> 做判斷的設定只能放在驗證憑證的那一個 server 區塊，80 只做轉址到 https、不採信這個標頭；實測的 Worker 偽造標頭走的正是 80。</p>
<h2 id="只放行-cdn-位址的套用時機範圍與清單的維護">只放行 CDN 位址的套用時機、範圍與清單的維護</h2>
<p>只放行 CDN 位址的規則一套上去，不經過 CDN 的連線全部連不進來。規則的效果與失效的方式，依它在什麼時候套上、套在哪些連接埠而不同：</p>
<ul>
<li><strong>時機：網域的 DNS 記錄已經經由 CDN 代理，舊記錄的快取也過期了</strong>。還沒接上 CDN、或記錄設成只做 DNS 解析（Cloudflare 的 DNS only）時，使用者直接連源站，規則一套上，所有訪客都連不進網站：規則寫在雲端防火牆或丟棄封包的規則上時，瀏覽器等到連線逾時；寫在 firewalld 的 zone 上時，firewalld 以 ICMP 回拒，瀏覽器立即顯示連線失敗（兩種結果的分辨見 <a href="/blog/linux/dotfile/knowledge-cards/connection-refused-vs-timeout/" data-link-title="Connection Refused vs. Timeout（連線被拒與逾時）" data-link-desc="遠端連不上、要判斷是封包到不了還是服務拒絕、決定往網路層還是服務層除錯時回來讀">Connection Refused vs. Timeout（連線被拒與逾時）</a>）。網站回應的標頭帶著 CDN 的標記（Cloudflare 會加 <code>cf-ray</code>），只代表管理員自己這一次的請求經過了 CDN；其他訪客的解析器可能還快取著舊的 A 記錄（指向源站），換成 Cloudflare 的 nameserver 時，舊的 NS 記錄也有快取（2026-10-25 查 <code>.com</code> 上層伺服器回的 NS 記錄，TTL 是 172800 秒，也就是兩天；<code>dig +noall +authority <網域> @a.gtld-servers.net</code> 查得到自己網域的值）。所以套規則的時間點在舊記錄的快取全部過期之後：只改了 A 記錄時，等舊 A 記錄的 TTL；換了 nameserver、而舊的 DNS 業者還保留著這個網域的資料時，快取著舊 NS 的解析器在那份快取到期前一刻向舊業者查 A，又會拿到一份新的舊 A 記錄，所以要等舊 NS 的 TTL 加上舊 A 的 TTL；舊 NS 的 TTL 取上層伺服器回的值與舊業者自己回的值之中較大的那一個（解析器常採用後者）。舊業者已經刪掉這個網域時，等兩者之中較長的那一個就夠（依 DNS 快取的機制推論，沒有實測）。在那之前套上，快取著舊記錄的訪客連不進網站。</li>
<li><strong>接上 CDN 之前就能做的限制</strong>：管理通道改走白名單或代理、資料庫與內部服務的容器不發佈或只發佈在本機位址、關掉 80 與 443 以外對外開著的連接埠、出站 DNS 的限制，這幾項不依賴 DNS 記錄的狀態，可以先做。只放行 CDN 位址到 80 與 443 這一項，要等上一項的時機。</li>
<li><strong>範圍：管理通道不在這條規則裡</strong>。規則只套在網站的 80 與 443 上，SSH 走 <a href="/blog/devops/infra/03-network-foundation/management-access-channel/" data-link-title="伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口" data-link-desc="與雲端廠商無關、適用於雲端 VM、地端主機與 VPS 的管理員登入通道設計：拆成網路可達性、通道授權與主機登入驗證的模型，各層的做法（來源白名單、跳板機、VPN、身分感知代理、代理程式反向連線、SSH 憑證）、更換 port 與 fail2ban 改不了的部分，依存取者身分、連線送達方式、收回方式選擇組合的依據，以及移除公開 IP 之後的出站路徑、切換順序、救援入口、組織護欄與稽核">伺服器管理通道的設計</a> 裡的那一條（來源 IP 白名單、Bastion、IAP 或 VPN），兩者分開設定。把整台主機的入站都改成只放行 CDN 位址時，管理員自己的 SSH 會一起被擋在外面；Cloudflare 的 DNS 代理轉送的是網站的 HTTP 與 HTTPS，SSH 要經由 Cloudflare 時另外架 Tunnel。</li>
<li><strong>範圍：同一台主機上還有不經 CDN 的服務</strong>。例如網站經由 Cloudflare，而同一台主機的 443 也直接對外提供一個 API 子網域。防火牆只看位址與連接埠，分不出同一個連接埠上的兩個網域（那要看 TLS 的 SNI 或 HTTP 的 Host），所以對 443 套「只放行 CDN」，API 就斷線；不套，網站的直連路徑就開著，而 API 子網域的 A 記錄本身就公開了源站的位址。可行的分法有：API 也改經由 CDN 代理；API 改用另一個公開 IP 或另一個連接埠，各自套各自的規則；或在反向代理依網域分流，網站的網域只接受來自 CDN 位址的請求（這一種仍留著經由別的 CDN 帳號送來的請求）；或網站的網域用自己上傳的每個主機名稱一張的用戶端憑證，只在網站的 server 區塊驗證，API 的區塊不驗證。這幾種做法沒有實跑。</li>
</ul>
<p>規則寫在主機本身程式收連線的路徑上（firewalld 的 zone、ufw 的入站規則）時，寫成「放行 CDN 位址到 80 與 443」就夠：zone 的預設動作已經回拒未列出的連線（firewalld 的 <code>public</code> zone 是回拒，ufw 預設拒絕入站是丟棄），放行清單之外的來源自然被擋下。這個前提要先查：主機的預設 zone 不一定是 <code>public</code>（<code>firewall-cmd --get-default-zone</code>），有些發行版的預設 zone 本身就放行一段高連接埠，<code>firewall-cmd --list-all</code> 列得出它的 target 與開著的連接埠。zone 的預設回拒只作用在主機本身收連線的那條路徑上。Docker 發佈的連接埠走的是另一條路徑：封包的目的地先被改寫成容器，再由主機轉送過去，這條轉送路徑上沒有對應的預設拒絕，那裡的規則要寫成「來源不在 CDN 清單裡就丟棄」，寫法見〈Docker 發佈的連接埠：封包路徑與限制的寫法〉的 <code>DOCKER-USER</code> 與 nftables 表。</p>
<p>CDN 經由 IPv6 回源的條件，是管理員在 CDN 的 DNS 設定裡替源站填了 IPv6 位址（Cloudflare 的 AAAA 紀錄、內容是源站的 IPv6）。訪客查得到的 AAAA 不代表這件事：實測只填了源站 IPv4 的 Proxied 紀錄，網域照樣解析出 Cloudflare 的 IPv6 位址，而回源全部經由 IPv4；填了源站 IPv6 時 Cloudflare 會不會改用 IPv6 回源沒有測（依 Cloudflare 的 DNS 文件推論會）。沒有替源站填 IPv6 時，主機的 IPv6 只會收到直連的請求，主機防火牆照預設回拒就好。填了的話，漏寫 IPv6 的後果依規則的寫法而不同：</p>
<ul>
<li><strong>放行式</strong>（只放行清單，其餘交給預設回拒）只寫了 IPv4 的清單：CDN 經由 IPv6 回源的連線被預設回拒擋下，網站對 IPv6 回源失效。</li>
<li><strong>丟棄式</strong>（來源不在清單裡就丟棄）的比對只寫了 IPv4 位址（nftables 的 <code>ip saddr</code>、iptables）：IPv6 的連線不受這條規則限制，經由 IPv6 直連源站的路徑照舊開著。</li>
</ul>
<p>兩種寫法都要另寫一份 IPv6 清單（Cloudflare 的 <code>ips-v6</code>）。Docker 發佈的連接埠的 IPv6 那一份走的路徑跟 IPv4 那一份不同，寫在〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。</p>
<p>CDN 的位址清單會變動。Cloudflare 的〈Cloudflare IP addresses〉寫明清單不常變，新的位址段會先加進公佈的清單再投入使用，沒有寫會另外通知。規則裡的清單沒有跟著更新時，Cloudflare 從新位址段回源的請求會被擋下，所以清單要定期從 <code>https://www.cloudflare.com/ips-v4</code> 與 <code>ips-v6</code>（或 Cloudflare 的 API）取回、跟規則比對。規則用位址集合（firewalld 的 ipset、nftables 的 set）寫時，更新只換集合的內容，規則本身不動，排程一支取回清單、換掉集合內容的程式就能維護；這個做法沒有實跑。<code>DOCKER-USER</code> 的自建鏈、ufw 的 after.rules 與 ufw 的 IPv6 入站放行都是一段一條的規則，更新時整段重新產生（after.rules 的產生與對帳見 <a href="/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a> 的〈讓規則開機時載入：寫進 /etc/ufw/after.rules〉）。不論哪一種載體，Cloudflare 這兩份清單的最後一行沒有換行字元，逐行讀取的迴圈會漏掉最後一段而不報錯，所以寫進去的條數要跟清單的段數對帳。</p>
<h2 id="docker-發佈的連接埠封包路徑與限制的寫法">Docker 發佈的連接埠：封包路徑與限制的寫法</h2>
<p>容器用 <code>docker run -p 8081:80</code> 發佈連接埠時，Docker 在 iptables 的 nat 表寫一條目的位址轉換規則（<a href="/blog/devops/infra/knowledge-cards/dnat/" data-link-title="DNAT（目的位址轉換）" data-link-desc="容器發佈的連接埠沒被主機防火牆擋下、port forwarding 的限制規則要寫在位址轉換之前還是之後、或要比對位址轉換之前的連接埠時，查 DNAT 改寫封包目的地的時間點與它對防火牆規則的影響">DNAT</a>，destination NAT：把封包的目的地改寫成另一個位址與連接埠），在封包剛進主機的 prerouting 階段，就把目的地從「主機的 8081」改成「容器的 80」。改寫之後，核心判定這個封包要轉送給另一個網路介面（容器網路在主機上的 bridge 介面：預設網路是 docker0，compose 建的自訂網路是 <code>br-</code> 開頭的介面，容器接在它後面），它走的是轉送（forward）路徑，不經過管主機本身入站連線的 input 路徑。</p>
<p>主機防火牆的一般規則寫在 input 路徑上，所以對發佈的連接埠沒有作用，<code>ufw status</code> 與 <code>firewall-cmd --list-all</code> 也都列不出這些連接埠（要用 <code>docker ps</code> 或 <code>ss -ltnp</code> 查）：</p>
<ul>
<li><strong>ufw</strong>：Docker 的〈Packet filtering and firewalls〉寫明，送往發佈連接埠的流量在經過 ufw 的規則之前就被轉走，ufw 的設定對它等於不存在。網路上常見的解法是在 Docker 的設定裡關掉它的 iptables 管理（<code>"iptables": false</code>），同一頁寫明這樣做多半會讓容器的網路失效，發佈的連接埠也會變成區網內連得到。</li>
<li><strong>firewalld</strong>：firewalld 把網路介面分到 zone（一組介面共用一套入站規則，例如 <code>public</code>），zone 與 zone 之間轉送的流量由 policy 管（一條 policy 指定從哪些 zone 轉送到哪些 zone、帶一個優先序與預設動作）。Docker 啟動時建一個 target 為 ACCEPT 的 <code>docker</code> zone，把它的 bridge 介面放進去，再建一條 <code>docker-forwarding</code> policy，放行任何 zone 轉送到 <code>docker</code> zone 的流量。實測在 <code>public</code> zone 只開了 <code>ssh</code> 與 <code>dhcpv6-client</code>、沒有任何一條規則提到 8081 的主機上，位址落在 Cloudflare 範圍外的測試來源照樣拿到容器的回應。firewalld 的轉送鏈開頭還有一條 <code>ct status dnat accept</code>：在預設的 <code>StrictForwardPorts=no</code> 下，所有經過目的位址轉換的連線在任何 policy 之前就被接受，所以自己加一條「<code>public</code> 轉送到 <code>docker</code> 只放行 CDN 位址」的 policy 也擋不住，實測加上之後範圍外的來源仍然連得到。</li>
</ul>
<p>經過位址轉換的那一份，Docker 保留封包原本的來源位址，容器裡的程式看到的是真正的連線來源（實測容器的存取記錄裡，兩個經由 IPv4 連的測試來源位址都原樣出現），所以來源限制在技術上做得到。</p>
<p><code>-p 8080:80</code> 同時發佈在 IPv4 與 IPv6，而兩份走的路徑不同。容器所在的網路沒有開 IPv6（Docker 預設的 bridge 網路就是），而 Docker 的 <code>userland-proxy</code> 是預設的開著時，IPv6 那一份由 docker-proxy 這個主機上的程式（<a href="/blog/devops/infra/knowledge-cards/userland-proxy/" data-link-title="Userland Proxy（使用者空間的連接埠轉送程式）" data-link-desc="ss 列出 docker-proxy、rootlesskit 或 rootlessport 聽著容器發佈的連接埠、主機防火牆的入站規則對容器的連接埠有效、或容器的存取紀錄只看得到閘道位址而沒有真實來源時，查這類轉送程式接收連線的路徑與它換掉來源位址的代價">Userland Proxy</a> 的一種）接聽、再自己連到容器的 IPv4 位址，連線走 input 路徑：實測在 ufw 與 firewalld 上，沒有放行規則時經由 IPv6 連發佈的連接埠都被擋下，加了 IPv6 的放行規則之後才連得到，跟 IPv4 那一份正好相反，所以 IPv6 這一份照放行式寫在主機防火牆的入站規則上。代價是來源位址：docker-proxy 自己連進容器，實測容器記到的 IPv6 那一筆來源是預設網路的閘道 <code>172.17.0.1</code>（compose 建的自訂網路閘道是別的位址，<code>docker network inspect <網路名></code> 的 <code>Gateway</code> 欄查得到），容器裡的反向代理依來源位址做的判斷（只信任 CDN 位址段送來的 <code>CF-Connecting-IP</code>、存取紀錄）對經由 IPv6 回源的請求都不成立。Docker 的 <code>userland-proxy</code> 設成 <code>false</code> 時，實測在 ufw 主機上 IPv6 那一份根本沒有發佈：<code>docker ps</code> 只列 <code>0.0.0.0</code> 的那一份、ip6tables 沒有轉換規則，經由 IPv6 連都被拒。網路建立時帶 <code>--ipv6</code>、容器有 IPv6 位址時，依 Docker〈Port publishing〉的說明，IPv6 那一份改由 ip6tables 的位址轉換送進容器，走轉送路徑，規則要寫在 ip6tables 的 <code>DOCKER-USER</code> 或 nftables 的 <code>ip6 saddr</code>；這一種沒有實跑。</p>
<p>限制發佈連接埠的做法，從「讓連接埠不對外」到「在主機之外擋」依序是：</p>
<ul>
<li>
<p><strong>不發佈</strong>：同一個 compose 專案或同一個 Docker 網路裡的容器，以服務名稱互相連線，不需要發佈連接埠。資料庫、快取這類只給其他容器用的服務不寫 <code>ports</code>，主機外面就連不到它們；主機上的工具要連時，才發佈在本機位址。</p>
</li>
<li>
<p><strong>只發佈在本機位址</strong>（<code>-p 127.0.0.1:8082:80</code>）：外部來源連不到這個連接埠，實測兩個外部來源都被拒、主機本機連得到。這個結果有版本條件：Docker 的〈Port publishing〉寫明 28.0.0 以前，跟主機在同一個 L2 網段的其他主機連得到發佈在 127.0.0.1 的連接埠（實測用的是 29.9.2，<code>docker version</code> 查得到版本），共用網段的 VPS 或區網裡要先確認版本。對外改由反向代理（nginx、Caddy）收 80 與 443 再轉給容器；反向代理以主機上的程式或 host network 模式的容器執行時，它收連線走 input 路徑，主機防火牆的放行式規則對它有效，這是用 ufw、又沒有雲端防火牆可設的主機上規則最少的組合。反向代理自己也用 <code>-p 80:80 -p 443:443</code> 發佈時，它跟其他發佈的連接埠一樣走轉送路徑，要照下面幾種寫法限制。預設的發佈位址可以在 Docker 的設定裡改：實測 daemon 設定的 <code>ip</code> 設成 <code>127.0.0.1</code> 之後，預設 bridge 網路上的容器發佈在 <code>127.0.0.1</code>，而接在自訂網路上的容器照樣發佈在 <code>0.0.0.0</code> 與 <code>[::]</code>，外部來源連得到；自訂網路建立時帶網路選項 <code>com.docker.network.bridge.host_binding_ipv4=127.0.0.1</code>，那個網路上的容器才發佈在 <code>127.0.0.1</code>。compose 的自訂網路在 <code>driver_opts</code> 寫同一個選項，或用 daemon 設定的 <code>default-network-opts</code> 套到之後新建的每一個 bridge 網路（已經建好的網路不受影響），這兩種沒有實跑。</p>
</li>
<li>
<p><strong><code>DOCKER-USER</code> 鏈</strong>：Docker 在 iptables 的 FORWARD 鏈最前面跳到這條鏈，裡面的規則由使用者自己寫，Docker 啟動與重啟時不清掉它（實測只重啟 dockerd 之後規則還在、照樣擋得住）。封包到這裡時目的地已經改寫成容器的位址與連接埠，所以要用連線追蹤（<a href="/blog/devops/infra/knowledge-cards/conntrack/" data-link-title="conntrack（連線追蹤）" data-link-desc="防火牆規則寫了 established、related 或 ctorigdstport、有狀態防火牆為什麼不必寫回程規則、改了規則卻像沒生效、或位址轉換之後要比對原本的位址時，查 Linux 核心記錄連線狀態的表與它在規則裡的用法">conntrack</a>：核心記錄每一條連線的狀態與它原本的位址、連接埠的表）記下的原始目的連接埠比對（<code>-m conntrack --ctstate DNAT --ctorigdstport 443 --ctdir ORIGINAL</code>）。<code>--ctstate DNAT</code> 限定只比對經過位址轉換的連線：容器自己往外連 443、容器之間連 80 的封包也經過這條鏈、原始目的連接埠一樣是 443 或 80，實測少了這個條件時兩者都被丟掉，加上之後恢復，而範圍外的來源仍被擋（實測時發佈的連接埠是 8081，正式設定換成 80 與 443 時才會撞到這兩種流量）。<code>--ctdir ORIGINAL</code> 讓規則只比對發起方向的封包；容器回覆的封包也帶著同一個原始目的連接埠，少了這個條件時這些回覆封包會被拿去比對來源而丟掉（依連線追蹤的機制推論，沒有拿掉這個條件實測）。實測範圍外的來源被擋下（連線逾時），範圍內的照常。它的弱點在規則的存續：防火牆重新載入、dockerd 重啟與重開機之後規則還在不在。用 iptables 指令加的規則只存在執行中的核心裡，各種主機上的結果如下：</p>
<ul>
<li><strong>任何主機重開機</strong>：規則不在（ufw 主機上實測）。</li>
<li><strong>ufw 主機，after.rules 沒有宣告這條鏈</strong>：<code>ufw reload</code> 與關閉再開啟只重建 ufw 自己的鏈，規則還在（實測）。</li>
<li><strong>ufw 主機，規則寫進 <code>/etc/ufw/after.rules</code></strong>：這是 ufw 主機上讓規則留過重開機的做法（整份 Cloudflare 清單的寫法在 <a href="/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a> 的〈讓規則開機時載入：寫進 /etc/ufw/after.rules〉）。實測 reload、Docker 重啟與重開機之後都還在：開機時 ufw 先於 Docker 啟動，先建出這條鏈，Docker 沿用它。after.rules 宣告這條鏈時，每次 <code>ufw reload</code> 先清空它再寫入檔案裡的規則，實測另外用 <code>iptables -I</code> 加的規則在 reload 之後不在，所以同一台主機上的 <code>DOCKER-USER</code> 規則要全部寫在 after.rules 裡。</li>
<li><strong>firewalld 主機，nftables 後端</strong>：<code>firewall-cmd --reload</code> 在有 direct 設定時清掉規則與自建的鏈，沒有時規則還在（<code>FlushAllOnReload</code> 設成 <code>yes</code> 或 <code>no</code> 都一樣）；direct 設定有 direct rule 與 passthrough 兩種，實測各加一條都會觸發，查的時候 <code>firewall-cmd --direct --get-all-rules</code> 與 <code>--get-all-passthroughs</code> 兩個都要跑，前一個列不出 passthrough。實測的 Oracle Cloud 主機（2026.10.16 的 Oracle Linux 10.2 平台映像，nftables 後端）自帶一組保護執行個體中繼資料服務的 passthrough，reload 清掉了規則，那一組的內容記在 <a href="/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a> 的〈DOCKER-USER 鏈的限制效果與規則的存續〉。direct 設定也會在之後被別的軟體加進來（例如 fail2ban 的 firewalld 動作，依它的設定推論），所以這是主機當下的狀態，不是固定的屬性。</li>
<li><strong>firewalld 主機，iptables 後端</strong>（<code>/etc/firewalld/firewalld.conf</code> 的 <code>FirewallBackend</code>）：沒有任何 direct 設定，reload 也清掉了規則，因為那時 iptables 的表由 firewalld 管、reload 整張重建（實測）。</li>
<li>用<a href="/blog/devops/infra/knowledge-cards/configuration-management/" data-link-title="Configuration Management（組態管理）" data-link-desc="要讓好幾台主機的套件、設定檔與服務維持同一個狀態、讀到 Ansible 的 inventory 與 group_vars、或要判斷主機上的設定該交給 Ansible 這類工具還是 Terraform 這類 IaC 管理時">組態管理</a>工具定期 reload 的主機上，規則會被清掉的那幾種情形，每一次 reload 之後直連就重新開著，沒有任何告警。<code>systemctl restart firewalld</code>，以及 iptables-services 或 netfilter-persistent 的開機載入，都沒有實跑。</li>
</ul>
<p>另外，Docker 改用實驗性的 nftables 後端時，〈firewall-nftables〉寫明沒有 <code>DOCKER-USER</code> 這條鏈，自訂規則要寫在自己的 nftables 表裡，也就是下面「自己的 nftables 表」那一種。</p>
</li>
<li>
<p><strong>firewalld 的 <code>StrictForwardPorts=yes</code></strong>：設定檔 <code>/etc/firewalld/firewalld.conf</code> 的這個選項（這次的 firewalld 2.4.3 有；它是 2024 年 11 月 firewalld 官方部落格〈Strict Forward Ports〉介紹的新功能，較舊的 firewalld 沒有）把轉送鏈開頭的 <code>ct status dnat accept</code> 換成只接受 firewalld 明確放行的連接埠。〈firewalld.conf〉與那篇部落格寫明，設成 <code>yes</code> 之後發佈的連接埠要用 firewalld 的 forward-port（firewalld 自己做的目的位址轉換規則）明確放行。實測它管得到「哪些發佈的連接埠可以從外面連」：設成 <code>yes</code> 之後兩個測試來源都被回拒，加了 forward-port 之後又都連得到；它管不到「誰可以連」：即使 forward-port 寫在限定來源的 rich rule（firewalld 可以同時寫來源、連接埠與動作的規則）裡，firewalld 在轉送鏈產生的放行規則也只比對原始目的連接埠（連線追蹤記下的、位址轉換之前的連接埠），沒有帶上來源條件，範圍外的來源也連得到。forward-port 改寫在 policy 上時，轉送鏈裡沒有產生任何放行，範圍內的來源也連不到。規則存在 firewalld 的永久設定裡，reload 與 dockerd 重啟之後都在。</p>
</li>
<li>
<p><strong>自己的 nftables 表，掛在目的位址轉換之前</strong>：在 nftables 建一張自己的表，鏈接在 prerouting 這個 hook（核心處理封包的流程上，讓規則掛上去執行的固定位置；prerouting 是封包剛進主機、還沒決定路由的那一個）上、優先序排在目的位址轉換之前（<code>priority dstnat - 10</code>），封包還沒被改寫時就用原本的目的連接埠比對來源，來源不在 CDN 清單裡就丟棄。規則要限定目的地是主機自己的位址（<code>fib daddr type local</code>）：容器往外連 443 與容器之間連 80 的封包也從 docker0 進 prerouting，實測少了這個條件時兩者都被丟掉。實測範圍外的來源被擋下，<code>firewall-cmd --reload</code>、dockerd 重啟之後規則都還在；把表寫進 <code>nftables.service</code> 開機時載入的設定檔（RHEL 系是 <code>/etc/sysconfig/nftables.conf</code>，其他發行版看 <code>systemctl cat nftables</code> 的 <code>ExecStart</code>）並啟用這個服務之後，重開機也還在。代價有兩個。一是規則不在 firewalld 的管理介面裡，<code>firewall-cmd --list-all</code> 看不到它，接手的人要知道還有這一張表。二是 <code>nftables.service</code> 會清掉整個 nftables 規則集：RHEL 系的 unit 在停止、重新啟動與重新載入時執行 <code>nft flush ruleset</code>，而 Debian 系的預設設定檔第一行就是 <code>flush ruleset</code>（這一點沒有核對各版本），被清掉的包括 firewalld 的表，以及 Docker 經由 iptables-nft 寫的位址轉換與轉送規則；之後自建的表又被載回來，主機只剩這一張表，其他連接埠失去預設回拒、發佈的連接埠與容器的出站都斷線，要依序重新啟動 firewalld 與 dockerd 才會重建（依 unit 檔的內容推論，沒有實跑）。避開這個風險的做法是不經過 <code>nftables.service</code>，改用一個開機時只執行 <code>nft -f</code> 載入這一張表的 systemd unit。</p>
</li>
<li>
<p><strong>雲端防火牆</strong>：規則在主機之外執行，Docker 改寫的是主機自己的防火牆，碰不到它。只放行 CDN 位址到 80 與 443、其他連接埠一律不開時，主機上誤發佈的任何連接埠都連不進來。</p>
</li>
<li>
<p><strong>Cloudflare Tunnel</strong>：源站不需要任何入站放行。這個效果要管理員自己做到：移除雲端防火牆與主機防火牆上 80、443 的入站放行，網站容器不發佈連接埠（或只發佈在本機位址），讓 <code>cloudflared</code> 經由同一個 Docker 網路或本機位址連到網站；網站容器還用 <code>-p 80:80</code> 發佈時，直連路徑照樣開著。代價是 <code>cloudflared</code> 要常駐、主機要能出站連到 Cloudflare，而且網站的入口綁在 Cloudflare 一家。實測用不需要帳號的 quick tunnel：後端只聽 <code>127.0.0.1</code>、沒有任何入站放行也連得到；quick tunnel 的 <code>cloudflared</code> 用 QUIC 連 Cloudflare 的 UDP 7844，出站擋掉 UDP 7844、TCP 7844 開著時，它一直重試 QUIC、沒有自動改用 http2，網站回 Cloudflare 的 530；指定 <code>--protocol http2</code> 之後改用 TCP 7844 連上。取得 quick tunnel 網址的那一步另外連出站的 443。所以出站只放行一份清單的主機上，quick tunnel 要的是 UDP 與 TCP 的 7844（各給 QUIC 與 http2）與取網址用的 443；清單只有 TCP 7844 而協定留在預設時，quick tunnel 停在重試 QUIC、網站回 530，協定設成 http2 時才改走 TCP 7844。每一種出站限制的結果記在 <a href="/blog/devops/infra/03-network-foundation/hands-on/cloudflare-origin-pull-walkthrough/" data-link-title="Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠" data-link-desc="源站要放在 Cloudflare 後面、想確認只放行 Cloudflare 位址的雲端防火牆放不放得下整份清單、回源實際用哪些位址、Authenticated Origin Pulls 怎麼驗證、Cloudflare Worker 能不能穿過這道防火牆並偽造 CF-Connecting-IP、或 Tunnel 要開哪些出站連接埠時，查 Oracle Cloud 與 Cloudflare 免費方案上實際跑過的指令與輸出">Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠</a> 的〈Cloudflare Tunnel：源站不開入站，以及出站要放行的連接埠〉。具名的 tunnel（綁在帳號上的那種）預設的協定選擇沒有測。沒有出站路徑的主機（例如只有 service gateway 的私有 subnet 主機）用不了。</p>
</li>
</ul>
<p>Docker 以外的容器執行方式，發佈連接埠的路徑分成兩類：在主機防火牆之前改寫封包目的地的，連線走轉送路徑，結果取決於轉送路徑上每一張表的預設動作；由主機上一個轉送程式聽著那個連接埠、收下連線再轉進容器的，連線走 input 路徑，主機防火牆的入站規則管得到。分辨是哪一類，先查有沒有規則把那個連接埠的目的地改寫掉，再看誰在聽：改寫規則可能寫在經由 iptables-nft 管的表，也可能寫在原生 nftables 的表（實測 Podman 5.8.2 的 netavark 寫在 <code>inet netavark</code>，<code>iptables -t nat</code> 看不到），所以要用 <code>nft list ruleset</code> 查。查到改寫規則時就是前一類，<code>ss -ltnp</code> 裡聽著那個連接埠的程式（Podman 的 <code>conmon</code>、docker-proxy 的 IPv4 那一份）只是佔住連接埠；查不到時，聽著的轉送程式才是接收者。查表是預測，最終以範圍外的來源實際連一次為準。</p>
<p>以 root 執行的 Podman（用 netavark 寫規則）屬於前一類，跟 Docker 一樣用位址轉換。實測在 firewalld 上它跟 Docker 一樣繞過 zone，在 ufw 上卻被 ufw 預設的 <code>deny (routed)</code> 擋下，連 Cloudflare 位址都連不到，要用 ufw 的 route 規則放行到容器的位址與連接埠；ufw 那一台的差別在 netavark 的轉送鏈只放行回程，沒有 Docker 那樣接受新入站連線的 <code>DOCKER-FORWARD</code>。兩台的 Podman 版本也不同（ufw 那一台是 4.9.3、firewalld 那一台是 5.8.2），防火牆與版本的影響沒有分開。主機上同時裝了 Docker 時，Podman 的轉送封包也經過 <code>DOCKER-USER</code>：實測在 ufw 那一台，一條比對原始目的連接埠 8089、沒有帶 <code>--ctstate DNAT</code> 的規則，對 Podman 發佈的 8089 一樣擋得住範圍外的來源（換成 80、443 時照上面 <code>DOCKER-USER</code> 那一項加 <code>--ctstate DNAT</code>，這個組合沒有在 Podman 上實跑）。</p>
<p>rootless 模式的 Docker 與 Podman 屬於後一類：它們以一般使用者執行，不能改主機的防火牆，發佈的連接埠由主機上的轉送程式（<code>rootlesskit</code>、<code>rootlessport</code>）接聽，ufw 的入站規則實測管得到。代價是在預設設定下（RootlessKit 的預設轉送方式、Podman 4 的 slirp4netns），容器看到的來源是轉送程式那一端的位址（<code>172.17.0.1</code>、<code>10.0.2.100</code>），存取紀錄與依來源位址的判斷拿不到真正的來源；Podman 5 預設的 pasta 依它的發行說明保留來源位址，沒有實跑。另外，<code>--network host</code> 的容器沒有位址轉換也沒有轉送程式，聽著連接埠的是程式本身、走 input 路徑；macvlan、ipvlan 網路的容器有自己的位址，封包不經過主機的轉送與 input 路徑，主機防火牆的規則都碰不到它（依網路驅動的機制推論，沒有實跑）。Docker 文件列的保留來源位址做法這次沒有實跑，列在 <a href="/blog/devops/infra/03-network-foundation/hands-on/podman-rootless-ports-walkthrough/" data-link-title="Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址" data-link-desc="用 Podman 或 rootless 模式的 Docker 發佈連接埠、想知道 ufw 或 firewalld 的規則管不管得到、或想在容器裡拿到連線的真實來源位址時，查 rootful Podman 在 ufw 與 firewalld 上的不同結果、rootless 模式接收連線的路徑，以及容器看到的來源位址">Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址</a> 的 rootless Docker 那一節。</p>
<p>這些寫法可以疊加。業者的防火牆放得下整份 CDN 清單時，雲端防火牆加上不發佈或只發佈在本機位址的組合，不靠主機上任何一條會被重新載入或重開機清掉的規則：雲端防火牆擋住直連，不發佈與本機位址讓「某個容器不小心發佈在 <code>0.0.0.0</code>」這種錯誤不會變成對外開放。網站跑在主機上的程式（不是容器）時，雲端防火牆加上 firewalld zone 或 ufw 的放行式規則就夠，兩層各自擋一次直連。同一組規則要套在多台主機上時，雲端防火牆的規則可以套在一組網卡上共用（Oracle Cloud 的 NSG、AWS 的 security group），主機防火牆的寫法則要在每一台各自部署與維護。單台主機、網站流量、主機連得到外面時，Cloudflare Tunnel 可以取代入站的 CDN 位址清單：移除 80 與 443 的入站放行，而網站容器不發佈或只發佈在本機位址時，清單的維護與 Docker 繞過主機防火牆這兩件事都不必處理。</p>
<h2 id="出站的-dns-只准送往指定的解析器擋得到與擋不到的部分">出站的 DNS 只准送往指定的解析器：擋得到與擋不到的部分</h2>
<p>主機加固清單常見的一條是限制 DNS 只用 53，它有入站與出站兩種讀法。入站的讀法是主機有跑 DNS 伺服器時才開 53，沒有跑就不開；網站主機多半沒有跑 DNS 伺服器，所以入站的做法就是不把 53 放進放行清單。出站的讀法是主機與容器送出的 DNS 查詢只准送往指定的解析器（雲端業者的解析器，例如 Oracle Cloud 虛擬網路 VCN 裡的 <code>169.254.169.254</code>），送往其他位址的 53 一律拒絕。後一種的目的，是讓被植入的程式不能用自己指定的 DNS 伺服器查詢，查詢全部經過一個留有紀錄的解析器。它擋不住把資料編進查詢的網域名稱送出去：允許的解析器會遞迴解析任何公開的名稱，<code><編碼後的資料>.<攻擊者的網域></code> 照樣被它送到攻擊者的權威伺服器，這一種要靠解析器端的查詢紀錄或 DNS 防火牆偵測。「指定的解析器」指的是主機實際往外送查詢的上游：Ubuntu 預設的 systemd-resolved 讓 <code>/etc/resolv.conf</code> 寫 <code>127.0.0.53</code>，實際的上游要用 <code>resolvectl status</code> 查，規則照 <code>/etc/resolv.conf</code> 寫會擋掉 systemd-resolved 自己的查詢；容器拿到的伺服器用 <code>docker exec <容器> cat /etc/resolv.conf</code> 查。</p>
<p>出站限制在 firewalld 上寫成一條從 <code>HOST</code>（主機本身送出的流量）到 <code>ANY</code>（任何 zone）的 policy，裡面兩條 rich rule：放行送往指定解析器的 <code>dns</code> 服務那一條優先序較小、先比對，拒絕其餘 <code>dns</code> 的那一條排在它之後。實測它的效果與漏洞：</p>
<ul>
<li><strong>主機本身送出的查詢</strong>：送往指定解析器的照常解析，送往其他位址的 53 被拒絕（<code>dig</code> 回 <code>connection refused</code>），對方收不到任何封包。</li>
<li><strong>容器送出的查詢</strong>：實測的容器在預設的 bridge 網路上，它的 DNS 設定是主機 <code>/etc/resolv.conf</code> 的副本，查詢直接從容器送出、走轉送路徑，不經過 <code>HOST</code>，所以這條 policy 對它無效，容器照樣把查詢送到外部的 53。這些查詢要在 <code>DOCKER-USER</code> 另寫一條（從容器網路的 bridge 介面進來、目的連接埠 53、目的地不是指定解析器的拒絕；預設網路的介面是 docker0，compose 的自訂網路是 <code>br-</code> 開頭的介面，iptables 可以寫成 <code>-i br-+</code>），而它有 <code>DOCKER-USER</code> 規則存續的問題（用 iptables 指令加的規則，在用 iptables 後端、或用 nftables 後端而有 direct 設定的 firewalld 主機上 reload 就消失、在 ufw 主機上被 after.rules 宣告的鏈 reload 時清空、重開機之後都不在；寫進 after.rules 的那一份重開機之後還在），要一起處理。compose 的自訂網路上，容器先問 Docker 內建的解析器（<code>127.0.0.11</code>），內建解析器再往外查，而那一筆往外查的封包由主機送出：實測連線追蹤記到的原始來源是主機的 IP，不是容器的位址；主機的出站規則擋掉 53（ufw 主機上的 OUTPUT、firewalld 的 <code>HOST</code> policy）時，compose 容器經由 <code>127.0.0.11</code> 的查詢失敗，<code>DOCKER-USER</code> 的規則對它沒有作用。compose 容器自己指定別的 DNS 伺服器時，查詢又從容器的介面轉送出去，<code>DOCKER-USER</code> 擋得到。所以容器的 DNS 要兩個位置都限制：轉送路徑上的規則（<code>DOCKER-USER</code> 或自建 nftables 表的 forward 鏈，實測自建表在 <code>firewall-cmd --reload</code> 之後還在）擋容器直接送出的，主機的出站規則擋內建解析器替它送出的。</li>
<li><strong>不走 53 的 DNS</strong>：DNS over TLS 用專用的 853，再加一條拒絕出站 853 的規則就擋得下（沒有實跑）。DNS over HTTPS 把查詢包在送往 443 的 HTTPS 裡，連接埠的限制看不到它。實測時主機對外部 443 送出的一般 TCP 連線不受這條 policy 影響；沒有實際送 DNS over HTTPS 的查詢，它走同一個連接埠，結果依此推論。要擋這一種，出站就要改成只放行一份允許的目的地清單（套件庫、業者的 API），這在 443 上會連帶影響每一個需要連外的功能，成本遠高於限制 53。</li>
</ul>
<p>所以出站限制 53 擋下的是寫死了 DNS 伺服器位址、走 53 的程式，它讓主機與容器的名稱查詢集中到一個留有查詢紀錄的解析器；有意繞過的程式改走 443 就繞得過去。</p>
<h2 id="地理封鎖依國家比對來源的位置與-geoip-清單的成本">地理封鎖：依國家比對來源的位置與 GeoIP 清單的成本</h2>
<p>依國家封鎖連線，要先知道連線來自哪個國家，而源站在 CDN 後面時，源站看到的來源位址全是 CDN 機房的位址：主機防火牆照來源位址查國家，查到的是 CDN 機房所在的國家，不是使用者的。所以地理封鎖寫在 CDN 那一端（Cloudflare 的 WAF custom rule 依 <code>ip.src.country</code> 比對），那裡看得到使用者真正的位址；源站只需要擋掉不經過 CDN 的連線，只放行 CDN 位址的規則已經做到。源站要自己做時，由反向代理依 <code>CF-Connecting-IP</code> 查國家，前提是這個標頭可信。只放行 CDN 位址不足以讓它可信（任何帳號的 Worker 都從 CDN 的位址送出、標頭可以自己寫，見〈主機前面有 CDN 時連到源站的路徑：經由 CDN、直連公開 IP 與管理通道〉），可信要靠自己上傳憑證的 Authenticated Origin Pulls 或 Tunnel；防火牆這一層做不到，因為它看不到 HTTP 標頭。</p>
<p>主機防火牆做地理封鎖的機制跟只放行 CDN 位址相同（把一個國家的位址段放進 ipset），適用的情形是主機直接面對使用者、前面沒有 CDN，或同一台主機上不經 CDN 的服務。它的成本在清單：國家的位址段清單要從 GeoIP 資料庫（把 IP 位址段對應到國家的資料庫）取得並定期更新，資料庫對 VPN、行動網路與雲端業者的位址判斷常常不準，被誤擋的使用者只看到連線失敗（逾時或立即被拒，看規則是丟棄還是回拒），沒有任何頁面告訴他原因。CDN 端的封鎖可以回一個說明頁或改成驗證挑戰，誤判時使用者看得到發生了什麼。</p>
<h2 id="防火牆限制與修補的關係">防火牆限制與修補的關係</h2>
<p>只放行 CDN 位址、在 CDN 上加 WAF 規則，縮小的是能連到有漏洞程式的來源範圍，漏洞本身還在。源站已經修補時，直連的掃描請求送到也攻不破；源站還沒修補時，經由 CDN 送來的同一種請求只要沒有被 WAF 規則認出來，照樣會送到程式。防火牆限制與修補各自關掉一條路徑：限制擋住不經過 CDN 的請求，修補處理經過 CDN 也會送到的那些。漏洞公開到修補完成之間的暫時緩解（WAF 規則、關閉功能）見 <a href="/blog/backend/07-security-data-protection/entrypoint-and-server-protection/" data-link-title="7.3 入口治理與伺服器防護" data-link-desc="以問題驅動方式整理對外入口、管理平面與伺服器邊界">7.3 入口治理與伺服器防護</a> 的〈修補窗口期內的暫時緩解〉。單台主機上的修補依軟體的安裝管道分開處理：發行版與第三方套件庫的套件、容器映像檔、應用程式自己的更新、自己建置的程式與從上游下載的二進位檔，各自由不同的機制得知有修補、能不能交給排程也不同；裝上去之後，已經在執行的程序要重新啟動、核心要重開機，修補才生效。各條管道的做法見 <a href="/blog/devops/operations/09-host-lifecycle/long-running-host-maintenance/" data-link-title="長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算" data-link-desc="單台 Linux 主機（VPS、雲端主機）長期上線時，沒有人操作也會改變的狀態與維護對它們做的事：log 與資料的寫入者和清理機制（logrotate、journald、容器 log）、磁碟寫滿時各元件的反應、每份 log 要讀的欄位、入口在主機與雲端各層的盤點（ss）、各條更新管道的安全更新與重開機（dnf-automatic、unattended-upgrades、needs-restarting）、會到期與會改變的設定、檢查間隔的推算，以及接手一台已上線的主機時先處理哪幾項">長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算</a>〈會老化的軟體：各條更新管道與更新後的重開機〉。</p>
<h2 id="延伸閱讀實測紀錄入口層管理通道cdn-的分發與兩個網路之間的連線">延伸閱讀：實測紀錄、入口層、管理通道、CDN 的分發與兩個網路之間的連線</h2>
<ul>
<li><a href="/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a>：firewalld 的 ipset、rich rule 與 zone sources、Docker 發佈的連接埠繞過 firewalld、<code>DOCKER-USER</code> 在 dockerd 重啟後還在而 reload 後是否消失取決於 firewalld 的後端與 direct 設定、<code>StrictForwardPorts</code> 只管連接埠不管來源、nftables 表在 reload 與重開機之後的存續、出站 DNS 的 policy 對主機與容器的不同效果，每一步的指令與輸出</li>
<li><a href="/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a>：ufw 的入站與 route 規則對發佈連接埠沒有作用的原因、<code>DOCKER-USER</code> 寫進 <code>/etc/ufw/after.rules</code> 之後在重開機後的存續、IPv6 那一份由 docker-proxy 接收、compose 容器的 DNS 查詢由主機送出</li>
<li><a href="/blog/devops/infra/03-network-foundation/hands-on/podman-rootless-ports-walkthrough/" data-link-title="Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址" data-link-desc="用 Podman 或 rootless 模式的 Docker 發佈連接埠、想知道 ufw 或 firewalld 的規則管不管得到、或想在容器裡拿到連線的真實來源位址時，查 rootful Podman 在 ufw 與 firewalld 上的不同結果、rootless 模式接收連線的路徑，以及容器看到的來源位址">Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址</a>：同一條 ufw 設定對 Docker 與 Podman 結果相反的原因、rootless 模式由轉送程式接收連線的代價</li>
<li><a href="/blog/devops/infra/03-network-foundation/hands-on/cloudflare-origin-pull-walkthrough/" data-link-title="Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠" data-link-desc="源站要放在 Cloudflare 後面、想確認只放行 Cloudflare 位址的雲端防火牆放不放得下整份清單、回源實際用哪些位址、Authenticated Origin Pulls 怎麼驗證、Cloudflare Worker 能不能穿過這道防火牆並偽造 CF-Connecting-IP、或 Tunnel 要開哪些出站連接埠時，查 Oracle Cloud 與 Cloudflare 免費方案上實際跑過的指令與輸出">Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠</a>：NSG 的 120 條上限、回源位址與公布清單的比對、nginx 上的用戶端憑證驗證、Worker 穿過位址限制並偽造標頭、cloudflared 在 UDP 7844 被擋時的行為</li>
<li><a href="/blog/devops/infra/03-network-foundation/traffic-entry-layer/" data-link-title="流量入口層 — 請求怎麼從使用者到達應用" data-link-desc="自管環境要決定請求從使用者到應用經過哪幾層入口、每層承擔什麼——TLS 終結的位置、動靜分離、單機 reverse proxy 與雲端負載平衡器的選擇">流量入口層 — 請求怎麼從使用者到達應用</a>：DNS、負載平衡、反向代理與應用在責任鏈上的分工，TLS 終結放在哪一層，單機 nginx 與雲端負載平衡器的選擇條件</li>
<li><a href="/blog/devops/infra/03-network-foundation/management-access-channel/" data-link-title="伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口" data-link-desc="與雲端廠商無關、適用於雲端 VM、地端主機與 VPS 的管理員登入通道設計：拆成網路可達性、通道授權與主機登入驗證的模型，各層的做法（來源白名單、跳板機、VPN、身分感知代理、代理程式反向連線、SSH 憑證）、更換 port 與 fail2ban 改不了的部分，依存取者身分、連線送達方式、收回方式選擇組合的依據，以及移除公開 IP 之後的出站路徑、切換順序、救援入口、組織護欄與稽核">伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口</a>：只放行 CDN 位址之後，管理員登入主機的那條通道的做法與選擇</li>
<li><a href="/blog/backend/05-deployment-platform/edge-cdn-static-distribution/" data-link-title="5.9 邊緣分發與靜態資源（CDN / Origin Protection）" data-link-desc="整理 CDN 與 edge cache 在部署平台中的責任邊界、origin protection、purge 與 invalidation 策略">5.9 邊緣分發與靜態資源（CDN / Origin Protection）</a>：CDN 在分發與快取上的責任，以及它跟入口資安的交接</li>
<li><a href="/blog/backend/07-security-data-protection/cross-network-connection-security/" data-link-title="7.43 兩個網路之間的連線安全：可達範圍、連線方向與流入的資料、被入侵端改不到的限制、應用層認證、監控主機的位置、金鑰與控制平面、異地備份的寫入憑證與連線紀錄" data-link-desc="地端主機與雲端主機、或兩個雲端業者的主機以 VPN 或存取金鑰接起來之後的安全設計與評估：連線清單上各台連得到什麼、每一台各假設一次被入侵、限制要放在被入侵端沒有寫入路徑的地方、連線的發起方向與流入的資料、VPN 之內的應用層認證、監控主機與管理者裝置的位置、WireGuard 與 Tailscale 的金鑰與控制平面、異地備份的寫入憑證，以及連線本身的紀錄">7.43 兩個網路之間的連線安全：可達範圍、連線方向與流入的資料、被入侵端改不到的限制、應用層認證、監控主機的位置、金鑰與控制平面、異地備份的寫入憑證與連線紀錄</a>：VPN 隧道介面上的 <code>DOCKER-USER</code> 規則與只放行回應的連線追蹤規則</li>
</ul>

</article>
<article>
<h1>網路地基的實作紀錄</h1>
<p>Sun, 25 Oct 2026 00:00:00 +0800</p>
<p>這個資料夾收網路地基模組裡不綁在某一家雲端業者的操作紀錄：前置條件、每一步的指令與輸出、遇到的錯誤與除錯過程、量到的值。觀念與判斷依據寫在上一層的概念文章，這裡的文章連回去，不重寫。</p>
<h2 id="章節文章">章節文章</h2>
<table>
 <thead>
 <tr>
 <th>文章</th>
 <th>主題</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td><a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a></td>
 <td>用 network namespace 模擬 Cloudflare 位址範圍內與範圍外的來源、firewalld 的 ipset、rich rule 與 zone sources、Docker 發佈連接埠繞過 firewalld、DOCKER-USER 在 dockerd 重啟後還在而 reload 後是否消失取決於 firewalld 的後端與 direct 設定、firewalld policy 擋不到的原因、StrictForwardPorts 只管連接埠不管來源、掛在位址轉換之前的 nftables 表與它的開機載入、出站 DNS 的 policy 與 forward 鏈的 nftables 表對主機與容器的不同效果、清理</td>
 </tr>
 <tr>
 <td><a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a></td>
 <td>Ubuntu 的 ufw 入站與 route 規則對發佈連接埠沒有作用的原因、DOCKER-USER 在 ufw reload、Docker 重啟與重開機之後的存續、寫進 /etc/ufw/after.rules 與它的 ASCII 限制、IPv6 那一份由 docker-proxy 接收、compose 容器的 DNS 查詢由主機送出、清理</td>
 </tr>
 <tr>
 <td><a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/podman-rootless-ports-walkthrough/" data-link-title="Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址" data-link-desc="用 Podman 或 rootless 模式的 Docker 發佈連接埠、想知道 ufw 或 firewalld 的規則管不管得到、或想在容器裡拿到連線的真實來源位址時，查 rootful Podman 在 ufw 與 firewalld 上的不同結果、rootless 模式接收連線的路徑，以及容器看到的來源位址">Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址</a></td>
 <td>rootful Podman（netavark）在 ufw 上被擋、在 firewalld 上繞過 zone 的原因與 ufw route 規則的放行寫法、rootless Docker 的 rootlesskit 與 rootless Podman 的 rootlessport 接收連線、容器看到的來源位址、測試使用者的清理</td>
 </tr>
 <tr>
 <td><a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/cloudflare-origin-pull-walkthrough/" data-link-title="Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠" data-link-desc="源站要放在 Cloudflare 後面、想確認只放行 Cloudflare 位址的雲端防火牆放不放得下整份清單、回源實際用哪些位址、Authenticated Origin Pulls 怎麼驗證、Cloudflare Worker 能不能穿過這道防火牆並偽造 CF-Connecting-IP、或 Tunnel 要開哪些出站連接埠時，查 Oracle Cloud 與 Cloudflare 免費方案上實際跑過的指令與輸出">Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠</a></td>
 <td>Oracle Cloud 的公開子網路與 NSG、每次 API 呼叫 25 條與每個 NSG 120 條的上限、GCP 與 AWS 文件的上限、經由 Cloudflare 代理時回源的來源位址、SSL/TLS 模式與 nginx 上的 AOP、Worker 穿過位址限制並偽造 CF-Connecting-IP、quick tunnel 與出站 7844、清理與 Cloudflare 設定的還原</td>
 </tr>
 </tbody>
</table>
</article>
<article>
<h1>Network Tag（GCP 網路標籤）</h1>
<p>Fri, 23 Oct 2026 00:00:00 +0800</p>
<p>Network tag 是貼在 GCP VM 上的字串標籤，防火牆規則用它選出要套用的 VM：規則的 <code>--target-tags</code> 列出 tag，只有帶著其中一個 tag 的 VM 受這條規則影響（沒有 target 的規則套用到整個網路的 VM）。它是 VM 的屬性，<code>gcloud compute instances add-tags</code> 逐台加，或寫進 instance template 讓建出來的 VM 都帶著。AWS 沒有對應的標籤機制，對應的做法是把 instance 掛進 security group。可先對照 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">Security Group</a>。</p>
<h2 id="概念位置">概念位置</h2>
<p>tag 把「哪些 VM 要開這個 port」從防火牆規則裡拆出來，放到 VM 上：規則只寫一次，VM 加上 tag 就套用。代價是 tag 由誰都能改的 VM 屬性決定——有權限改 VM 的帳號加上一個 tag，那台 VM 就套用了那條規則；而一台 VM 被重建時，只有寫在 template 裡的 tag 會留下。這與 AWS 的 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">Security Group</a> 方向相反：Security Group 是把 instance 掛進規則集合。要讓授權更嚴格時，防火牆規則改用 <code>--target-service-accounts</code> 依 VM 的服務帳號選，換服務帳號需要的權限比改 tag 高。</p>
<h2 id="可觀察訊號">可觀察訊號</h2>
<ul>
<li><code>gcloud compute instances describe <vm> --format="value(tags.items)"</code> 列出這台 VM 的 tag</li>
<li>只放行 IAP 來源的規則存在、而某台 VM 經 IAP 連不上：先查這台 VM 有沒有那條規則的 target tag</li>
<li>由 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/managed-instance-group/" data-link-title="Managed Instance Group（MIG，代管執行個體群組）" data-link-desc="VM 被自動重建之後設定不見、要決定一組 VM 的設定該寫在哪裡，或要判斷一台 VM 能不能直接刪掉重建時，查 GCP 的 MIG 與 instance template 怎麼建立、修復與更新 VM">Managed Instance Group（MIG）</a> 自動重建或新建的 VM 少了手動加的 tag</li>
</ul>
<h2 id="設計責任">設計責任</h2>
<p>管理通道用的 tag（例如放行 IAP 來源連 22 port 的那一個）寫進 instance template 或 GKE node pool 的設定，不靠逐台 <code>add-tags</code>。改 template 或 node pool 的 tag 時，<code>--tags</code> 是整組指定，既有的 tag 要一起列進去。能改 VM tag 的權限等於能改那台 VM 套用哪些防火牆規則，授權時與防火牆規則的管理權一起考慮。</p>
<h2 id="鄰卡">鄰卡</h2>
<ul>
<li><a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">Security Group</a> — AWS 上用掛載而不是標籤決定規則套用範圍</li>
<li><a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/managed-instance-group/" data-link-title="Managed Instance Group（MIG，代管執行個體群組）" data-link-desc="VM 被自動重建之後設定不見、要決定一組 VM 的設定該寫在哪裡，或要判斷一台 VM 能不能直接刪掉重建時，查 GCP 的 MIG 與 instance template 怎麼建立、修復與更新 VM">Managed Instance Group（MIG）</a> — tag 寫在 template 裡才會留到重建後</li>
<li><a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/identity-aware-proxy/" data-link-title="Identity-Aware Proxy（身分感知代理）" data-link-desc="要讓管理員或使用者不經公開入口連到內部主機與服務、評估把存取控制從來源 IP 改成帳號身分時，查身分感知代理的連線路徑、前提與代價">Identity-Aware Proxy（身分感知代理）</a> — GCP 上放行 IAP 來源的防火牆規則用 tag 選 VM</li>
</ul>
</article>
<article>
<h1>DNAT（目的位址轉換）</h1>
<p>Sun, 25 Oct 2026 00:00:00 +0800</p>
<p><a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/nat/" data-link-title="NAT Gateway" data-link-desc="private subnet 或沒有外部 IP 的 VM 要主動對外連線、評估 NAT 的數量與出站成本、或在 AWS 與 GCP 之間對照出站做法時，查 NAT Gateway 的職責、部署模式與取捨">NAT Gateway</a> 改的是出站封包的來源位址（SNAT），讓內部主機借一個公開位址出去；DNAT（destination NAT，目的位址轉換）改的是入站封包的目的地，讓外面的連線送到指定的那一台：封包原本送往「主機的 8081」，改寫之後送往「容器的 80」。回程的封包由 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/conntrack/" data-link-title="conntrack（連線追蹤）" data-link-desc="防火牆規則寫了 established、related 或 ctorigdstport、有狀態防火牆為什麼不必寫回程規則、改了規則卻像沒生效、或位址轉換之後要比對原本的位址時，查 Linux 核心記錄連線狀態的表與它在規則裡的用法">conntrack（連線追蹤）</a> 記下的對應自動改回來，外面的連線方看到的始終是主機的位址與 8081。</p>
<h2 id="概念位置">概念位置</h2>
<p>Linux 處理封包的框架叫 netfilter，它在封包流程上留了幾個固定位置（hook）讓規則掛上去。DNAT 掛在 prerouting 這個 hook：封包剛進主機、核心還沒決定路由之前就改寫（iptables 寫在 nat 表的 PREROUTING 鏈，nftables 寫在 <code>type nat</code> 的鏈；主機本機發出的連線則在 OUTPUT 那一段改寫）。改寫之後，核心依新的目的地決定路由：目的地是容器或另一台主機時，封包走轉送（forward）路徑送給另一個介面，不經過管主機本身入站連線的 input 路徑；改寫成主機本機的位址或連接埠時（iptables 的 REDIRECT、firewalld 不帶目的位址的 forward-port），封包仍走 input 路徑。</p>
<p>Docker 用 <code>-p 8081:80</code> 發佈連接埠時，IPv4 那一份屬於目的地改成容器的那一種：寫在 input 路徑上的主機防火牆規則（ufw、firewalld 的 zone）管不到它（容器網路沒開 IPv6 時，IPv6 那一份不經 DNAT，由主機上的 docker-proxy 程式（<a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/userland-proxy/" data-link-title="Userland Proxy（使用者空間的連接埠轉送程式）" data-link-desc="ss 列出 docker-proxy、rootlesskit 或 rootlessport 聽著容器發佈的連接埠、主機防火牆的入站規則對容器的連接埠有效、或容器的存取紀錄只看得到閘道位址而沒有真實來源時，查這類轉送程式接收連線的路徑與它換掉來源位址的代價">Userland Proxy</a>）接收、走 input 路徑，見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a>），而轉送路徑上 Docker 與 firewalld 預設都放行經過位址轉換的連線（Docker 的 <code>DOCKER-FORWARD</code> 鏈、firewalld 的 <code>ct status dnat accept</code>），所以這些連接埠繞過了主機防火牆。雲端的 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">Security Group</a> 在封包到達主機、還沒被改寫之前就比對完，不受這個改寫影響。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<ul>
<li><strong><code>iptables -t nat -S DOCKER</code> 看得到規則</strong>：<code>-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8081 -j DNAT --to-destination 172.17.0.2:80</code> 就是 Docker 發佈 8081 時寫的那一條。</li>
<li><strong>防火牆清單看不到、外面卻連得到的連接埠</strong>：<code>firewall-cmd --list-all</code> 與 <code>ufw status</code> 都沒有列 8081，從外面連照樣拿到容器的回應；查發佈的連接埠要用 <code>docker ps</code> 或 <code>ss -ltnp</code>。</li>
<li><strong>規則比對不到改寫前的連接埠</strong>：寫在 FORWARD 鏈的 <code>--dport 8081</code> 比對不到任何封包，因為封包到那裡時目的連接埠已經是 80。</li>
</ul>
<h2 id="判讀方式">判讀方式</h2>
<p>限制規則寫在 DNAT 之前還是之後，決定它看得到哪一個連接埠：之前（prerouting、優先序比 dstnat 小）看得到原本的目的連接埠，直接用它比對；之後（FORWARD 鏈、Docker 的 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/docker-user/" data-link-title="DOCKER-USER（Docker 留給使用者的轉送規則鏈）" data-link-desc="要在 Docker 發佈的連接埠上加來源限制、寫進 DOCKER-USER 的規則在防火牆重新載入或重開機之後不見、或規則擋到了容器自己往外的連線時，查這條鏈在轉送路徑上的位置、比對原始連接埠的寫法與規則的存續條件"><code>DOCKER-USER</code></a>）看到的是改寫後的容器位址，要改用連線追蹤記下的原始值比對（iptables 的 <code>-m conntrack --ctorigdstport 8081</code>、nftables 的 <code>ct original proto-dst 8081</code>）。主機防火牆沒有放行、外面卻連得到的連接埠，多半是經過 DNAT 送給了容器或另一台主機，這時原因在規則的位置，不在規則的內容。Kubernetes 的 NodePort 在 kube-proxy 的 iptables 模式下也用 DNAT 送往 Pod，IPVS 模式的掛法不同，兩者都沒有在這個站上實測。Docker 的實測與各種限制寫法的比較見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a>。</p>
</article>
<article>
<h1>conntrack（連線追蹤）</h1>
<p>Sun, 25 Oct 2026 00:00:00 +0800</p>
<p>雲端的 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/security-group/" data-link-title="Security Group" data-link-desc="掛在資源網卡層級的有狀態防火牆，逐埠決定哪些來源能連進這個資源">Security Group</a> 放行一條入站連線之後，回程的封包不必另寫規則，因為它是「有狀態」的防火牆；Linux 主機上讓防火牆有狀態的元件是 conntrack（connection tracking，連線追蹤）。它是核心裡記錄每一條連線的表：兩端的位址與連接埠、協定、TCP 的連線階段（SYN_SENT、ESTABLISHED、TIME_WAIT 這類），以及經過位址轉換時原本與改寫後的兩組位址。防火牆規則比對的連線狀態（NEW、ESTABLISHED、RELATED、INVALID）是核心依這張表替每個封包推出來的。</p>
<h2 id="概念位置">概念位置</h2>
<p>iptables 的 <code>-m conntrack</code>、<code>-m state</code> 與 nftables 的 <code>ct</code> 都在讀這張表。它也是 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/dnat/" data-link-title="DNAT（目的位址轉換）" data-link-desc="容器發佈的連接埠沒被主機防火牆擋下、port forwarding 的限制規則要寫在位址轉換之前還是之後、或要比對位址轉換之前的連接埠時，查 DNAT 改寫封包目的地的時間點與它對防火牆規則的影響">DNAT</a> 與 SNAT（<a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/nat/" data-link-title="NAT Gateway" data-link-desc="private subnet 或沒有外部 IP 的 VM 要主動對外連線、評估 NAT 的數量與出站成本、或在 AWS 與 GCP 之間對照出站做法時，查 NAT Gateway 的職責、部署模式與取捨">NAT Gateway</a> 做的那一種）能運作的前提：核心在連線的第一個封包改寫位址時，把原本與改寫後的對應記進表裡，同一條連線之後的封包與回程封包都照這個對應改寫。規則要比對位址轉換之前的值時，讀的就是表裡記下的「原始方向」（original）。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<ul>
<li><strong>防火牆規則開頭的 <code>ct state { established, related } accept</code></strong>：實測時 firewalld 的轉送鏈就以這一條起手，已經放行的連線之後的封包直接通過，規則只需要描述新連線。</li>
<li><strong>firewalld 的 <code>ct status dnat accept</code></strong>：在 <code>StrictForwardPorts=no</code>（預設值）下，所有經過目的位址轉換的連線在任何 policy 之前就被接受，Docker 發佈的連接埠因此不受 firewalld policy 約束。</li>
<li><strong><a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/docker-user/" data-link-title="DOCKER-USER（Docker 留給使用者的轉送規則鏈）" data-link-desc="要在 Docker 發佈的連接埠上加來源限制、寫進 DOCKER-USER 的規則在防火牆重新載入或重開機之後不見、或規則擋到了容器自己往外的連線時，查這條鏈在轉送路徑上的位置、比對原始連接埠的寫法與規則的存續條件"><code>DOCKER-USER</code></a> 裡的 <code>-m conntrack --ctorigdstport 8081 --ctdir ORIGINAL</code></strong>：封包的目的地已經改成容器的 80，用表裡記下的原始目的連接埠 8081 比對；<code>--ctdir ORIGINAL</code> 只比對發起方向的封包，回程封包不進這條規則。</li>
<li><strong><code>conntrack -L</code></strong>（套件 conntrack-tools）或 <code>/proc/net/nf_conntrack</code>：列出表裡每一條連線，一行裡有協定、TCP 階段、<code>src=</code>/<code>dst=</code>/<code>sport=</code>/<code>dport=</code> 兩組（第一組是原始方向，第二組是回程方向；兩組對不上就是經過了位址轉換），以及 <code>ASSURED</code> 這類旗標。</li>
</ul>
<h2 id="判讀方式">判讀方式</h2>
<p>一條防火牆規則比對的是封包現在的欄位，或是表裡記下的原始值，兩者在位址轉換之後不同：寫在位址轉換之後的規則，要比對原本的位址或連接埠時要用 <code>ctorig*</code> 這類條件，用 <code>--dport</code> 只比對得到改寫後的值。規則改了卻像沒生效時，原因常在已經存在的連線：ESTABLISHED 的連線多半在規則前面就被放行，新規則只擋得到之後的新連線；要讓既有的連線也受新規則約束，用 <code>conntrack -D</code>（可加 <code>-p tcp --dport <連接埠></code> 縮小範圍）刪掉表裡那幾條，連線方重新連線時才會被新規則比對。表的容量有上限（<code>nf_conntrack_max</code>），連線數很大的主機表滿時會丟掉新連線，核心記錄裡會出現 <code>nf_conntrack: table full, dropping packet</code>。Docker 發佈的連接埠怎麼用它限制來源，見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/origin-host-firewall/" data-link-title="CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖" data-link-desc="網站放在 CDN（例如 Cloudflare）後面時，源站主機的入站與出站限制：請求避開 CDN 直連源站的成因、來源限制放在雲端防火牆、主機防火牆或 CDN 端驗證的差別、只放行 CDN 位址的套用時機、Docker 發佈的連接埠繞過 ufw 與 firewalld 的路徑與各種限制寫法、CDN 位址送來的請求為什麼不等於 CDN 替自己的網域轉送、出站 DNS 限制的效果與漏洞、地理封鎖放在 CDN 邊緣的理由">CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖</a>。</p>
</article>
<article>
<h1>DOCKER-USER（Docker 留給使用者的轉送規則鏈）</h1>
<p>Mon, 26 Oct 2026 00:00:00 +0800</p>
<p>DOCKER-USER 是 Docker 在 iptables 的 filter 表裡建的一條自訂鏈：FORWARD 鏈的第一條規則無條件跳到它，Docker 自己不在裡面寫任何規則，啟動與重啟時也不清它的內容，讓使用者在 Docker 放行容器流量之前插入自己的限制。它管的是轉送路徑：Docker 發佈的連接埠經過 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/dnat/" data-link-title="DNAT（目的位址轉換）" data-link-desc="容器發佈的連接埠沒被主機防火牆擋下、port forwarding 的限制規則要寫在位址轉換之前還是之後、或要比對位址轉換之前的連接埠時，查 DNAT 改寫封包目的地的時間點與它對防火牆規則的影響">DNAT（目的位址轉換）</a> 改寫成容器位址之後，封包由主機轉送給容器，寫在主機入站規則（ufw 的入站規則、firewalld 的 zone）上的限制碰不到它，DOCKER-USER 是這條路上第一個可以寫規則的位置。</p>
<h2 id="概念位置">概念位置</h2>
<p>FORWARD 鏈的跳轉順序是 DOCKER-USER、Docker 自己的 <code>DOCKER-FORWARD</code>、然後才是 ufw 的 <code>ufw-*</code> 鏈；<code>DOCKER-FORWARD</code> 接受送往發佈連接埠的連線，所以寫在 ufw route 規則裡的限制輪不到這些封包，寫在 DOCKER-USER 的輪得到。封包到這條鏈時目的地已經是容器的位址與連接埠，限制發佈的連接埠要用 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/conntrack/" data-link-title="conntrack（連線追蹤）" data-link-desc="防火牆規則寫了 established、related 或 ctorigdstport、有狀態防火牆為什麼不必寫回程規則、改了規則卻像沒生效、或位址轉換之後要比對原本的位址時，查 Linux 核心記錄連線狀態的表與它在規則裡的用法">conntrack（連線追蹤）</a> 記下的原始目的連接埠比對：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="ln">1</span><span class="cl">iptables -I DOCKER-USER -p tcp -m conntrack --ctstate DNAT --ctorigdstport <span class="m">443</span> --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP</span></span></code></pre></div><p>三個 conntrack 條件各管一件事：<code>--ctorigdstport 443</code> 比對位址轉換之前的連接埠；<code>--ctdir ORIGINAL</code> 只比對發起方向的封包，容器回覆的封包不拿來比對來源；<code>--ctstate DNAT</code> 只比對經過位址轉換的連線，也就是送往發佈連接埠的那些。少了最後一個時，容器自己往外連 443、同一台主機上容器之間連 80 的封包也進這條鏈、原始目的連接埠一樣是 443 或 80，一起被丟掉（2026-10-26 在 Ubuntu 24.04 與 Docker 29.9.2 上實測）。</p>
<p>這條鏈只存在 iptables 後端：Docker 改用 nftables 後端時沒有它（Docker 的〈firewall-nftables〉文件）。它也只管 IPv4 那一份發佈：容器網路沒開 IPv6 時，IPv6 那一份由主機上的 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/userland-proxy/" data-link-title="Userland Proxy（使用者空間的連接埠轉送程式）" data-link-desc="ss 列出 docker-proxy、rootlesskit 或 rootlessport 聽著容器發佈的連接埠、主機防火牆的入站規則對容器的連接埠有效、或容器的存取紀錄只看得到閘道位址而沒有真實來源時，查這類轉送程式接收連線的路徑與它換掉來源位址的代價">Userland Proxy（使用者空間的連接埠轉送程式）</a> 接收，不經過轉送路徑。主機上同時裝了 Docker 與以 root 執行的 Podman 時，Podman 的轉送封包也經過 DOCKER-USER（實測）。</p>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<ul>
<li><strong><code>iptables -S FORWARD</code> 的前兩行</strong>：<code>-A FORWARD -j DOCKER-USER</code>、<code>-A FORWARD -j DOCKER-FORWARD</code>。主機也裝了 Podman 時，最前面還有一條 <code>-j NETAVARK_FORWARD</code>。</li>
<li><strong>規則加了、從外面量過擋得住，過一陣子又失效</strong>：防火牆重新載入或重開機清掉了它，<code>iptables -S DOCKER-USER</code> 只剩 <code>-N DOCKER-USER</code> 這一行。</li>
<li><strong>加了限制之後容器呼叫外部 API 逾時</strong>：規則只比對原始目的連接埠，沒有 <code>--ctstate DNAT</code>，容器的出站連線也被丟掉。</li>
</ul>
<h2 id="判讀方式">判讀方式</h2>
<p>DOCKER-USER 的弱點在規則的存續，用 iptables 指令加的規則只存在執行中的核心裡，各種情形下的結果不同（2026-10-25 到 26 日在 Ubuntu 24.04 的 ufw 0.36.2、Oracle Linux 10.2 的 firewalld 2.4.3 上實測）：</p>
<table>
 <thead>
 <tr>
 <th>情形</th>
 <th>規則</th>
 </tr>
 </thead>
 <tbody>
 <tr>
 <td>任何主機重開機</td>
 <td>不在</td>
 </tr>
 <tr>
 <td><code>systemctl restart docker</code></td>
 <td>還在</td>
 </tr>
 <tr>
 <td>ufw 的 <code>ufw reload</code>，after.rules 沒有宣告這條鏈</td>
 <td>還在</td>
 </tr>
 <tr>
 <td>ufw 的 after.rules 宣告這條鏈</td>
 <td>每次 reload 先清空、再寫入檔案裡的規則；用 iptables 指令另外加的不在</td>
 </tr>
 <tr>
 <td>firewalld 的 reload，nftables 後端、沒有 direct 設定</td>
 <td>還在</td>
 </tr>
 <tr>
 <td>firewalld 的 reload，nftables 後端、有 direct rule 或 passthrough</td>
 <td>不在（Oracle Cloud 的 Oracle Linux 平台映像自帶 passthrough）</td>
 </tr>
 <tr>
 <td>firewalld 的 reload，iptables 後端</td>
 <td>不在</td>
 </tr>
 </tbody>
</table>
<p>要讓規則留過重開機，ufw 主機把它寫進 <code>/etc/ufw/after.rules</code>，同一台主機上的 DOCKER-USER 規則都要寫在那裡；firewalld 主機上改用掛在位址轉換之前的自建 nftables 表，或把限制放在雲端防火牆。direct 設定是主機當下的狀態，之後裝的軟體可能再加進來，用<a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/configuration-management/" data-link-title="Configuration Management（組態管理）" data-link-desc="要讓好幾台主機的套件、設定檔與服務維持同一個狀態、讀到 Ansible 的 inventory 與 group_vars、或要判斷主機上的設定該交給 Ansible 這類工具還是 Terraform 這類 IaC 管理時">組態管理</a>工具定期 reload 的主機上，規則被清掉之後直連就重新開著而沒有告警。實測的指令、輸出與 after.rules 的整份清單寫法見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a> 與 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/origin-firewall-walkthrough/" data-link-title="源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS" data-link-desc="要在 Linux 主機上設定只放行 Cloudflare 位址的防火牆、確認 Docker 發佈的連接埠有沒有繞過 firewalld、在 DOCKER-USER、StrictForwardPorts 與 nftables 表之間選一種限制容器的來源、或限制出站 DNS 時，查 Oracle Linux 10 上實際跑過的指令、輸出，以及規則在重新載入、dockerd 重啟與重開機之後還在不在">源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS</a>；各種限制寫法的取捨見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/origin-host-firewall/" data-link-title="CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖" data-link-desc="網站放在 CDN（例如 Cloudflare）後面時，源站主機的入站與出站限制：請求避開 CDN 直連源站的成因、來源限制放在雲端防火牆、主機防火牆或 CDN 端驗證的差別、只放行 CDN 位址的套用時機、Docker 發佈的連接埠繞過 ufw 與 firewalld 的路徑與各種限制寫法、CDN 位址送來的請求為什麼不等於 CDN 替自己的網域轉送、出站 DNS 限制的效果與漏洞、地理封鎖放在 CDN 邊緣的理由">CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖</a> 的〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。</p>
</article>
<article>
<h1>Userland Proxy（使用者空間的連接埠轉送程式）</h1>
<p>Mon, 26 Oct 2026 00:00:00 +0800</p>
<p>把連線送進容器有兩種做法。<a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/dnat/" data-link-title="DNAT（目的位址轉換）" data-link-desc="容器發佈的連接埠沒被主機防火牆擋下、port forwarding 的限制規則要寫在位址轉換之前還是之後、或要比對位址轉換之前的連接埠時，查 DNAT 改寫封包目的地的時間點與它對防火牆規則的影響">DNAT（目的位址轉換）</a> 是核心在封包剛進主機時改寫目的地，封包本身被轉送給容器；userland proxy 是一個在主機上執行的使用者空間程式聽著那個連接埠，收下連線之後自己再開一條連線到容器，把兩條連線之間的資料來回搬。常見的三個是 Docker 的 docker-proxy、rootless Docker 的 rootlesskit，以及 rootless Podman 的 rootlessport。</p>
<h2 id="概念位置">概念位置</h2>
<p>連線的終點是主機上的一個程式，所以封包走的是 input 路徑（目的地是主機本身程式的那一條），主機防火牆的入站規則（ufw 的入站規則、firewalld 的 zone）管得到它，跟 DNAT 那一類正好相反。代價在容器看到的來源：容器收到的連線是轉送程式開的，來源位址是轉送程式那一端的位址，不是外面的真實來源。這跟 <a href="https://tarrragon.github.io/blog/devops/infra/knowledge-cards/reverse-proxy/" data-link-title="Reverse Proxy" data-link-desc="代替後端服務接收外部請求、再轉發到內部服務的中介層，承擔 TLS 終結、負載平衡與路由分流">Reverse Proxy（反向代理）</a> 換掉來源位址的道理相同，差別在反向代理常用 HTTP 標頭（<code>X-Forwarded-For</code>）把原本的來源帶過去，這幾個轉送程式在 TCP 這一層搬資料，什麼都不帶。</p>
<p>三個程式各在什麼時候出現：</p>
<ul>
<li><strong>docker-proxy</strong>：以 root 執行的 Docker 用 <code>-p</code> 發佈時，主機上 IPv4 與 IPv6 各有一份；IPv4 那一份從外面來的封包在 prerouting 就被 DNAT 改寫、到不了它，IPv6 那一份在容器網路沒開 IPv6 時由它接收。Docker 的 <code>userland-proxy</code> 設成 <code>false</code> 時它不啟動，IPv6 那一份也就沒有發佈（2026-10-26 在 Docker 29.9.2 上實測）。</li>
<li><strong>rootlesskit</strong>：rootless Docker 的 dockerd 以一般使用者執行、不能改主機的 iptables，發佈的連接埠全部由它接聽。</li>
<li><strong>rootlessport</strong>：rootless Podman 的對應程式，網路由 slirp4netns（Podman 4）或 pasta（Podman 5 的預設）提供。</li>
</ul>
<h2 id="可觀察訊號與例子">可觀察訊號與例子</h2>
<ul>
<li><strong><code>ss -ltnp</code> 列出這幾個程式聽著發佈的連接埠，nat 表裡沒有對應的 DNAT</strong>：<code>users:(("rootlesskit",pid=4085,fd=13))</code> 聽著 <code>0.0.0.0:8083</code>，<code>iptables -t nat -S | grep -c 8083</code> 回 0。</li>
<li><strong>容器的存取紀錄只有閘道位址</strong>：2026-10-26 的實測裡，經由 docker-proxy 的 IPv6 連線與 rootless Docker 的連線，容器記到的來源都是 <code>172.17.0.1</code>；rootless Podman 4.9 記到的是 slirp4netns 那張 tap 介面的 <code>10.0.2.100</code>。</li>
<li><strong>主機防火牆的入站規則對容器的連接埠有效</strong>：ufw 預設拒絕入站時兩個測試來源都連不到 rootless 容器的連接埠，加一條入站放行之後只有被放行的那個連得到。</li>
</ul>
<h2 id="判讀方式">判讀方式</h2>
<p>判斷一個發佈的連接埠屬於哪一類，先查有沒有規則把它的目的地改寫掉，再看誰在聽：<code>nft list ruleset | grep 'dport <連接埠>'</code> 同時列得出經由 iptables-nft 寫的與原生 nftables 寫的改寫規則。查到改寫規則時是 DNAT 那一類，聽著連接埠的程式只是佔住它（Podman 的 <code>conmon</code>、docker-proxy 的 IPv4 那一份），不算數；查不到時，聽著的轉送程式才是接收者。查表是預測，最終以從範圍外的來源實際連一次為準。屬於這一類時，限制寫在主機防火牆的入站規則上就有效，而容器裡依來源位址做的判斷（存取紀錄、速率限制、只信任來自 CDN 位址段的 <code>CF-Connecting-IP</code>）都拿不到真正的來源；Docker 文件列的保留來源位址做法（RootlessKit v3 的 <code>builtin</code> 加 <code>userland-proxy: false</code>、slirp4netns 轉送方式、pasta 加 <code>implicit</code>）這個站上沒有實跑。實測見 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/podman-rootless-ports-walkthrough/" data-link-title="Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址" data-link-desc="用 Podman 或 rootless 模式的 Docker 發佈連接埠、想知道 ufw 或 firewalld 的規則管不管得到、或想在容器裡拿到連線的真實來源位址時，查 rootful Podman 在 ufw 與 firewalld 上的不同結果、rootless 模式接收連線的路徑，以及容器看到的來源位址">Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址</a> 與 <a href="https://tarrragon.github.io/blog/devops/infra/03-network-foundation/hands-on/ufw-docker-walkthrough/" data-link-title="ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑" data-link-desc="在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出">ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑</a> 的〈IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果〉。</p>
</article>
</main></body></html>

Firewall on Tarragon

GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點、救援入口、IAP 規則與 IAM、停用舊規則驗證、OS Login 啟用與移除外部 IP

切換前的盤點：依賴舊規則的連線

準備救援入口：Serial Console 與本機救援帳號

啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則

授予開通道的 IAM 權限

停用舊規則，用 IAP 驗證新規則

刪除對外開放的規則

收斂 default-allow-internal 與 default-allow-icmp

啟用 OS Login：先授角色、單台先行、再做專案層級

建 Cloud NAT 並移除外部 IP

源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS

前置條件：主機、登入方式與測試檔案

共用的變數與函式

用 network namespace 模擬 Cloudflare 與其他來源

firewalld 以 ipset 只放行 Cloudflare 位址到主機本身的程式

Docker 發佈的連接埠與 firewalld 的規則

DOCKER-USER 鏈的限制效果與規則的存續

firewalld policy 對發佈連接埠的效果與轉送鏈的順序

StrictForwardPorts=yes：轉送鏈的變化與 forward-port 規則的比對條件

自己的 nftables 表：掛在目的位址轉換之前

出站的 DNS 只准送往 VCN 解析器：主機與容器的差別

清理：容器、dockerd、防火牆設定與暫存檔

各種寫法在重新載入、dockerd 重啟與重開機之後的結果

GCP VM 的 SSH 與 RDP 管理通道：從預設的全開規則改走 IAP TCP forwarding

預設網路自帶的防火牆規則

IAP TCP forwarding 的連線路徑與來源範圍

切換到 IAP 的順序

IAP 通道連不上時的依層判讀

IAP 的 IAM 授權範圍：誰拿得到通道

SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件

拿掉外部 IP 之後的出站路徑：Cloud NAT 與 Private Google Access

組織層級的護欄：Organization Policy 與階層式防火牆

稽核與偵測：firewall log、Cloud Audit Logs 與 Security Command Center

延伸閱讀：逐步的實作、與廠商無關的設計模型與 VPC 的分層規則

ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑

前置條件：Ubuntu 主機、ufw 與 Docker

共用的函式與兩個測試來源

ufw 的入站規則與 route 規則對發佈連接埠的效果

DOCKER-USER 規則的效果，以及它在 ufw reload、Docker 重啟與重開機之後的存續

讓規則開機時載入：寫進 /etc/ufw/after.rules

整份 Cloudflare 清單：IPv4 寫進 after.rules、IPv6 用 ufw 的入站規則

IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果

compose 自訂網路的容器經由 127.0.0.11 查詢時，DNS 封包從哪裡送出

清理：容器、ufw 規則、after.rules、namespace 與暫存目錄

各寫法在 ufw 主機上的結果

Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址

前置條件與測試來源

rootful Podman 在 ufw 上：netavark 的轉送鏈、ufw 的預設 routed 政策、route 規則與 DOCKER-USER

rootful Podman 在 firewalld 上：netavark 的 nftables 表、trusted zone 與 firewalld 的轉送鏈

rootless Docker：rootlesskit 的接收路徑、ufw 入站規則與容器看到的來源位址

rootless Podman：rootlessport 的接收路徑、ufw 入站規則與容器看到的來源位址

清理：兩台主機上的容器、測試使用者、ufw 規則、namespace 與暫存目錄

rootful 與 rootless 的 Docker、Podman：接收路徑、入站規則與容器看到的來源位址

Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠

前置條件：Cloudflare 的網域、有公開 IP 的源站與本機的工具

公開子網路、只放行 Cloudflare 的 NSG 與它的規則數上限

源站主機：建立、nginx 與從範圍外直連的結果

DNS 紀錄經由 Cloudflare 代理之後，回源的來源位址

SSL/TLS 模式「完整」與 Authenticated Origin Pulls