Publish port — DNAT và docker -p

TL;DR: docker run -p 8080:80 không “mở firewall ma thuật” — nó map gói tới host:8080 thành container_ip:80. Kernel đổi đích bằng DNAT trên nat PREROUTING (sớm, trước routing đầy đủ), rồi gói forward qua bridge/veth vào netns app. Reply nhờ conntrack reverse-NAT. Path: client → host:port → DNAT → FORWARD → bridge → container. Pitfall kinh điển: publish chỉ 127.0.0.1:8080 (demo localhost OK, LAN/WAN chết) hoặc có DNAT mà FORWARD DROP (counter nat tăng, gói vẫn không vào container).

Staging smoke: junior docker run -d -p 8080:80 my-api, curl localhost:8080 trên máy dev xanh. PM cầm laptop cùng Wi‑Fi, gõ http://<IP-LAN-máy-dev>:8080 — timeout. Junior soi ufw status và bảo “firewall chặn”. Bạn hỏi: “docker port / ss -lntp | grep 8080 listen địa chỉ nào?” · “iptables -t nat -L -n -v rule DNAT match 127.0.0.1 hay 0.0.0.0?” · “gói từ laptop đi PREROUTING + FORWARD, không phải INPUT tới process host.” App trong container sống; publish bind loopback hoặc thiếu path forward — không phải “API chưa start”.

Khái niệm DNAT/port forward đã có ở Foundations — NAT; hook/chain ở M1 — iptables. Bài 04 SNAT là chiều ra (đổi nguồn POSTROUTING). Bài này trace + implement chiều vào — đúng mapping docker -p.

Bài này faded: lab worked dựng DNAT PREROUTING + FORWARD; bạn tự điền rule khi chỉ có DNAT mà FORWARD DROP, và tự chọn bind 127.0.0.1 vs 0.0.0.0 trước khi đối chiếu.

1. Analogy — Chuông ngoài toà → phòng cụ thể

Nhớ netns = căn hộ, bridge = switch hành lang, SNAT = tem số toà khi ra đường. Publish port là chiều khách gõ cửa từ ngoài:

1. Khách chỉ biết số toà + nhánh chuông (host:8080) — không biết số phòng nội bộ (10.10.0.10:80).
2. Lễ tân đổi đích trên sổ: “nhánh 8080 → phòng 10, cổng trong 80” — đúng DNAT.
3. Đổi sổ lúc khách vừa bước vào sảnh — PREROUTING (sớm), không đợi xong mới đoán “có phải thư cho host process không”.
4. Bảo vệ đi kèm: cho phép đi xuyên hành lang tới phòng (FORWARD), không chỉ “mở quầy lễ tân” (INPUT).

2. Đường gói inbound: client → host:port → DNAT → container

2.1 Topology giả định (tiếp SNAT / mini-challenge)

flowchart LR
    subgraph EXT["Client / netns ext"]
        CURL["curl host:8080"]
    end
    subgraph HOST["Init / host netns"]
        IN["iface in"]
        PRE["nat PREROUTING DNAT"]
        FW["filter FORWARD"]
        BR["br0"]
        V["veth-c1"]
    end
    subgraph C1["Netns c1"]
        ETH["c1-eth0 10.10.0.10"]
        APP["app :80"]
    end
    CURL --> IN
    IN --> PRE
    PRE -->|"dst becomes 10.10.0.10:80"| FW
    FW --> BR
    BR --> V
    V --> ETH
    ETH --> APP

2.2 Từng bước L3 (request)

1. Client gửi TCP tới host_publish_ip:8080 (trên lab: 192.0.2.1:8080).
2. nat PREROUTING: rule DNAT đổi destination thành 10.10.0.10:80. Conntrack ghi mapping.
3. Routing host: đích giờ là IP trên bridge domain → không local-delivery thuần cho process host trên :8080 → path forward ra br0 / veth.
4. filter FORWARD: policy/rule phải ACCEPT path vào container (và reply RELATED,ESTABLISHED). DROP ở đây = timeout dù DNAT “đúng trên giấy”.
5. Bridge + veth: frame vào netns c1; app accept trên :80 (trong netns container, không phải ss trên host — bài 01).
6. Reply: conntrack un-DNAT (client vẫn thấy src là host:8080, không thấy tự nói chuyện với 10.10.0.10).

Vì sao “mở INPUT 8080” không đủ?
Sau DNAT, gói không còn là “traffic tới daemon host listen 8080” theo mental model firewall cổ điển. Path chính là PREROUTING (nat) → FORWARD (filter) → bridge. UFW/rule chỉ soi INPUT dễ mù publish Docker — đã map ở M1 iptables §4.4.

2.3 SNAT vs DNAT — một bảng chốt

3. docker -p 8080:80 map rule gì?

3.1 Cú pháp publish (đủ dùng hằng ngày)

Survey trên host có Docker (đọc, đừng xoá mù):

# What did Engine publish?
docker port <container>
ss -lntp | grep -E '8080|docker-proxy' || true

# NAT: DNAT / chain DOCKER thường sống ở đây
sudo iptables -t nat -L PREROUTING -n -v
sudo iptables -t nat -L DOCKER -n -v 2>/dev/null || true

# Filter path vào container
sudo iptables -L FORWARD -n -v
sudo iptables -L DOCKER -n -v 2>/dev/null || true

3.2 Mapping mental model → object Engine

3.3 Vì sao phải DNAT sớm (PREROUTING)?

Routing decision sau PREROUTING tách: gói cho local process vs forward. Publish cần client gõ IP host + port host, nhưng app chỉ listen IP container. Đổi đích sớm → routing thấy 10.10.0.10 → forward vào bridge. Nếu chỉ “mở port” trên host mà không DNAT, không có process host accept :8080 (trừ docker-proxy) — hoặc process host khác ăn nhầm port.

4. Worked lab — port forward tay (không Docker)

Chạy trên Linux có netns + iptables + sudo (+ python3 cho HTTP nhỏ). macOS/Docker Desktop không cùng view ip netns.

4.1 Skeleton: container netns + bridge + client “ngoài”

# --- cleanup leftovers ---
sudo ip netns del c1 2>/dev/null || true
sudo ip netns del ext 2>/dev/null || true
sudo ip link del br0 2>/dev/null || true
sudo ip link del veth-ext 2>/dev/null || true

# --- bridge + "container" c1 ---
sudo ip netns add c1
sudo ip link add br0 type bridge
sudo ip link set br0 up
sudo ip addr add 10.10.0.1/24 dev br0

sudo ip link add veth-c1 type veth peer name c1-eth0
sudo ip link set c1-eth0 netns c1
sudo ip link set veth-c1 master br0
sudo ip link set veth-c1 up

sudo ip netns exec c1 ip link set lo up
sudo ip netns exec c1 ip link set c1-eth0 up
sudo ip netns exec c1 ip addr add 10.10.0.10/24 dev c1-eth0
sudo ip netns exec c1 ip route add default via 10.10.0.1

# --- "external" client on another L3 leg (hits PREROUTING on host) ---
sudo ip netns add ext
sudo ip link add veth-ext type veth peer name ext0
sudo ip link set ext0 netns ext
sudo ip link set veth-ext up
sudo ip addr add 192.0.2.1/24 dev veth-ext

sudo ip netns exec ext ip link set lo up
sudo ip netns exec ext ip link set ext0 up
sudo ip netns exec ext ip addr add 192.0.2.2/24 dev ext0

# Sanity: LAN container + gateway
sudo ip netns exec c1 ping -c 1 10.10.0.1

4.2 App listen trong container

# HTTP on :80 inside c1 (background). Bind all addresses in THAT netns.
sudo ip netns exec c1 python3 -m http.server 80 --bind 0.0.0.0 >/tmp/c1-http.log 2>&1 &
sleep 0.5

# Control: host reaches container IP directly (gateway path — NOT testing publish yet)
curl -sS -o /dev/null -w "direct:%{http_code}\n" --connect-timeout 3 http://10.10.0.10:80/ || true

4.3 Predict — trước DNAT

# Expect fail (connection refused / timeout) before publish rules
sudo ip netns exec ext curl -sS -o /dev/null -w "before:%{http_code}\n" \
  --connect-timeout 3 http://192.0.2.1:8080/ || echo "before:fail"

4.4 Bật forward + DNAT + FORWARD path

sudo sysctl -w net.ipv4.ip_forward=1

# DNAT: packets to host:8080 on the "uplink" -> container:80
sudo iptables -t nat -A PREROUTING -i veth-ext -p tcp --dport 8080 \
  -j DNAT --to-destination 10.10.0.10:80

# Forward path into / out of container (lab-simple)
sudo iptables -A FORWARD -i veth-ext -o br0 -p tcp -d 10.10.0.10 --dport 80 -j ACCEPT
sudo iptables -A FORWARD -i br0 -o veth-ext -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Verify rules + counters later
sudo iptables -t nat -L PREROUTING -n -v
sudo iptables -L FORWARD -n -v

Thử lại từ client “ngoài”:

sudo ip netns exec ext curl -sS -o /dev/null -w "after:%{http_code}\n" \
  --connect-timeout 3 http://192.0.2.1:8080/
# Expect HTTP 200 from python http.server

# Counters should move on DNAT + FORWARD lines
sudo iptables -t nat -L PREROUTING -n -v
sudo iptables -L FORWARD -n -v

Đọc chứng cứ: pkts trên rule DNAT tăng khi curl từ ext = gói khớp publish. curl trực tiếp 10.10.0.10:80 từ host không cần DNAT — đừng nhầm hai path.

5. Fade — FORWARD DROP và bind loopback

5.1 Tự chẩn: chỉ DNAT, FORWARD chết

sudo iptables -P FORWARD DROP
# (giả sử xoá hết rule FORWARD lab; DNAT PREROUTING vẫn còn)
sudo iptables -D FORWARD -i veth-ext -o br0 -p tcp -d 10.10.0.10 --dport 80 -j ACCEPT 2>/dev/null || true
sudo iptables -D FORWARD -i br0 -o veth-ext -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || true

Đáp án fade (đối chiếu):

1. filter FORWARD — DNAT đổi đích xong gói vẫn phải forward vào br0; policy DROP + không ACCEPT khớp = chết. Nat table còn ≠ traffic vào app.
2. Khôi phục lab: ACCEPT veth-ext → br0 dport 80 tới 10.10.0.10; ACCEPT br0 → veth-ext RELATED,ESTABLISHED. Rồi curl lại từ ext.

sudo iptables -A FORWARD -i veth-ext -o br0 -p tcp -d 10.10.0.10 --dport 80 -j ACCEPT
sudo iptables -A FORWARD -i br0 -o veth-ext -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo ip netns exec ext curl -sS -o /dev/null -w "recovered:%{http_code}\n" \
  --connect-timeout 3 http://192.0.2.1:8080/

5.2 Tự chọn: 127.0.0.1 hay 0.0.0.0?

Tương đương lab (ý tưởng, không bắt buộc gõ hết): DNAT match thêm -d 127.0.0.1 chỉ bắt loopback; match không giới hạn dest IP (hoặc -d IP LAN) = publish “mặt tiền”. Docker: -p 127.0.0.1:8080:80 vs -p 8080:80.

6. Pitfall tổng hợp + map Docker

❌ Nhầm 1: “curl localhost xanh ⇒ publish OK cho cả team.”
✅ Localhost chỉ chứng minh path loopback / proxy host. Client LAN/WAN cần bind 0.0.0.0 (hoặc IP đúng iface) + path PREROUTING + FORWARD.

❌ Nhầm 2: “Chỉ cần DNAT, không cần FORWARD.”
✅ Sau DNAT gói forward vào netns. FORWARD DROP / mất rule DOCKER* = publish chết; counter nat có thể vẫn tăng.

❌ Nhầm 3: “Soi ss trên host thấy app listen :80.”
✅ App listen trong netns container. Host thấy docker-proxy / rule nat, không phải PID app (trừ host network mode).

❌ Nhầm 4: “SNAT và DNAT cùng một nút ‘bật NAT’.”
✅ SNAT egress đổi source POSTROUTING; publish đổi dest PREROUTING. Hai chiều, hai field.

❌ Nhầm 5: “iptables -t nat -F cho sạch.”
✅ Xoá publish + MASQUERADE Docker hàng loạt. Policy thêm: DOCKER-USER, không flush mù.

# Cleanup THIS lesson (rules + netns). Adjust if you re-added FORWARD lines.
sudo iptables -t nat -D PREROUTING -i veth-ext -p tcp --dport 8080 \
  -j DNAT --to-destination 10.10.0.10:80 2>/dev/null || true
sudo iptables -D FORWARD -i veth-ext -o br0 -p tcp -d 10.10.0.10 --dport 80 -j ACCEPT 2>/dev/null || true
sudo iptables -D FORWARD -i br0 -o veth-ext -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || true

# Stop http.server in c1 if still running (best-effort)
sudo ip netns exec c1 pkill -f "http.server 80" 2>/dev/null || true

sudo ip netns del c1 2>/dev/null || true
sudo ip netns del ext 2>/dev/null || true
sudo ip link del br0 2>/dev/null || true
sudo ip link del veth-ext 2>/dev/null || true

flowchart TB
    A["Symptom: client cannot hit host:8080"] --> B{"App listen inside container netns?"}
    B -->|"no"| APP["Fix process bind / port in netns"]
    B -->|"yes"| C{"nat PREROUTING / DOCKER DNAT match port?"}
    C -->|"no"| DNAT["Add/fix DNAT or docker -p"]
    C -->|"yes"| D{"FORWARD / DOCKER accept path?"}
    D -->|"DROP"| FW["Fix FORWARD or DOCKER-USER"]
    D -->|"yes"| E{"Publish bind 127.0.0.1 only?"}
    E -->|"yes + client remote"| BIND["Republish 0.0.0.0 or correct IP"]
    E -->|"no"| NEXT["tcpdump veth/br0 — next lesson"]

📚 Deep Dive — man page & docs

Liên hệ các bài khác

• 04 — Container ra Internet (SNAT) — chiều ra (đổi nguồn); bài này vào (đổi đích).
• 03 — Mini-challenge bridge — LAN ảo + gateway; publish thêm cửa mặt tiền host.
• 01 — Network namespaces — app listen trong netns; ss host ≠ ss container.
• 06 — Debug nsenter / tcpdump — bắt gói trên veth/br0 khi DNAT/FORWARD lệch.
• M1 — iptables & netfilter — PREROUTING/FORWARD + survey chain Docker.
• Foundations — NAT & port forwarding — DNAT khái niệm; bài này implement trên host bridge-style.

Tóm tắt

• Publish port = DNAT (đổi đích) trên nat PREROUTING + filter FORWARD vào bridge/container; reply nhờ conntrack.
• docker -p 8080:80 ≈ map host:8080 → container_ip:80 (chain DOCKER / docker-proxy trên Engine).
• Đường gói: client → host:port → DNAT → FORWARD → br0/veth → app trong netns.
• 127.0.0.1:hostPort:containerPort chỉ loopback; omit IP / 0.0.0.0 = publish mọi iface — pitfall demo localhost.
• Pitfall: tin curl localhost, DNAT không FORWARD, nhầm SNAT/DNAT, flush nat Docker.
• Fade: tự chẩn FORWARD DROP + tự chọn bind loopback vs all-interfaces.

7. Tự kiểm tra

Bài tiếp theo: Debug container networking — nsenter và tcpdump