事件說明：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

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。

右欄的兩格「沒有量」：加了 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（最後一列經由 IPv6）連發佈的連接埠的結果；後三欄是做完那個動作之後規則還在不在。「沒有單獨測」是那個動作做過、但這條規則不是當時要量的對象（例如量 DOCKER-USER 時順帶 reload 過），沒有記錄它的狀態；「沒有測」是沒有做那個動作。

事件說明：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 這類多跳改寫沒有測。