事件說明：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 <ssh 設定檔> <主機的 Host 名稱> 'mkdir -p /tmp/verify-fw'
  5scp -F <ssh 設定檔> 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/ 目錄裡最新的版本，照抄之前先打開那個目錄看一次。<ssh 設定檔> 是寫了 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 會留下一個只有 <direct> 空元素的檔，刪掉再 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 '<passthrough' /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 <<EOF
 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 <<EOF
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（各節的說明）。

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

事件說明：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：接收路徑、入站規則與容器看到的來源位址

判斷一種執行方式落在哪一列，先查有沒有規則把那個連接埠的目的地改寫掉，再看誰在聽。改寫規則用 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 這類多跳改寫沒有測。