iptables & netfilter — filter, NAT, hooks

TL;DR: Netfilter là framework hook trong kernel trên path IP; iptables (hoặc nftables) là frontend user-space gắn rule vào hook đó. Rule nằm trong table (filter, nat, mangle…) và chain (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING). Gói tới process host đi INPUT; gói xuyên host (container ↔ WAN, container ↔ container qua IP forward) đi FORWARD. Docker bridge inject chain riêng (DOCKER-USER, DOCKER, …) và thường MASQUERADE trên POSTROUTING — survey rule trước, SNAT/DNAT sâu ở Module 2. Pitfall kinh điển: thứ tự rule + FORWARD policy DROP làm “LAN ảo sống, Internet chết”.

UAT đêm trước go-live: hardening playbook chạy xong, hai container trên docker0 vẫn ping nhau. Sáng ra, curl registry từ container timeout. Junior soi INPUT và UFW — “firewall host chặn”. Bạn hỏi: “traffic container ra ngoài đi FORWARD hay INPUT? Counter chain DOCKER-USER / DOCKER-FORWARD tăng khi thử không?” L2 bridge (bài 03) lành; path IP forward + netfilter mới gãy — policy FORWARD DROP và jump Docker bị đụng, không phải “app registry chậm”.

Bài 01 — Linux network stack đã đặt tên hook trên đường gói; bài 03 cho LAN ảo qua docker0. Bài này gắn tables/chains và rule Docker thật vào đúng hook — bản đồ đọc iptables -L / -t nat -L trước khi đào SNAT/DNAT ở Module 2.

Bài này giải thích cơ chế bên dưới netfilter + survey rule Docker (chưa deep SNAT), fade: bạn tự map path gói vào chain trước khi đối chiếu lời giải.

1. Analogy — Trạm kiểm soát trên hành lang toà nhà

Nhớ analogy bưu cục bài 01: gói đã vào toà (ring → softirq → sk_buff). Bây giờ hành lang có trạm kiểm soát:

1. Cửa vào sảnh — quét mọi người vừa bước vào, trước khi biết họ lên tầng nội bộ hay đi xuyên sang toà bên (PREROUTING).
2. Quầy lễ tân tầng — chỉ người đến làm việc trong toà này (INPUT).
3. Hành lang xuyên toà — khách đi xuyên sang cửa khác, không dừng làm việc tại đây (FORWARD).
4. Cửa ra — tem / đổi nhãn trước khi ra đường (POSTROUTING — nơi NAT “đóng gói” địa chỉ ra ngoài hay gặp).
5. Lối ra từ phòng nội bộ — nhân viên toà xuất phát từ trong (OUTPUT).

2. Netfilter vs iptables — ai làm gì?

Netfilter là framework trong kernel: tại các điểm cố định trên path IP, kernel gọi hook — danh sách callback có thể ACCEPT, DROP, QUEUE, hoặc sửa gói (NAT, mark). Gói vẫn là sk_buff trên softirq/stack path bài 01; hook cắm vào path đó.

iptables (và nftables ngày nay) là user-space + module kernel tương ứng: bạn khai báo rule, tool đẩy vào cấu trúc netfilter. Docker Engine mặc định vẫn tạo rule kiểu iptables cho bridge network (có backend nftables trên phiên bản mới — cùng ý: rule filter/NAT cho isolation, publish port, masquerade).

flowchart TB
    SKB["sk_buff on IP path"] --> HOOK["Netfilter hook"]
    HOOK --> RULES["iptables or nft rules"]
    RULES -->|"ACCEPT"| CONT["Continue stack"]
    RULES -->|"DROP / REJECT"| DROP["Packet dropped"]
    RULES -->|"NAT target"| NAT["Rewrite addr or port"]

Vì sao không “firewall process” user-space mỗi gói? Throughput và latency: quyết định nằm trên soft path kernel. User-space chỉ cấu hình. Khi debug: hỏi hook + chain + counter rule, không hỏi PID “firewall.exe”.

NAT khái niệm (SNAT/DNAT/port forward) đã có ở Foundations — NAT và port forwarding. Bài này map chỗ NAT bám trên Linux (PRE/POST + table nat), chưa đào ví dụ SNAT container sâu (→ M2 — container ra Internet SNAT).

3. Tables — filter, nat, mangle (và raw)

Một table nhóm rule theo mục đích. Cùng tên chain có thể xuất hiện ở nhiều table — thứ tự table × hook do kernel định (đừng học thuộc lòng hết; nhớ filter vs nat cho container là đủ lúc đầu).

filter trả lời: “gói này được đi tiếp không?”
nat trả lời: “địa chỉ/port trên header có cần đổi không?” (thường chỉ gói đầu của connection; conntrack nhớ flow).
mangle ít dùng khi mới đọc Docker — biết “có table này để mark” là đủ.

# List filter table (default)
sudo iptables -L -n -v

# List NAT table — Docker MASQUERADE / publish sống ở đây
sudo iptables -t nat -L -n -v

# Optional: mangle
sudo iptables -t mangle -L -n -v

-n = không reverse DNS (nhanh, ổn định lab). -v = counter packet/byte — vàng khi hỏi “rule này có dính traffic không?”.

4. Chains builtin — PRE, INPUT, FORWARD, OUTPUT, POST

4.1 Bản đồ path (nhắc bài 01, gắn chain)

flowchart LR
    IN["Packet in"] --> PRE["PREROUTING"]
    PRE --> RT{"Local or Forward?"}
    RT -->|"local"| INPUT["INPUT"]
    RT -->|"forward"| FWD["FORWARD"]
    INPUT --> LOCAL["Local process"]
    FWD --> POST["POSTROUTING"]
    POST --> OUTDEV["Egress device"]
    APP["Local app send"] --> OUTPUT["OUTPUT"]
    OUTPUT --> POST

Hai câu tách lỗi ngay:

1. Gói tới process trong container (sau DNAT) vs gói tới daemon trên host — khác path, khác chain.
2. Container ping peer cùng docker0 chủ yếu L2 bridge (bài 03) — có thể không đi FORWARD L3. Container ra Internet gần như chắc FORWARD + POSTROUTING nat.

4.2 Rule matching & target (đủ để đọc)

Trong một chain, rule được duyệt từ trên xuống (first match wins với target kết thúc như ACCEPT/DROP; một số target kiểu LOG không dừng).

# Policy of built-in chains (filter)
sudo iptables -S | head
# Example lines you may see:
# -P FORWARD DROP
# -A FORWARD -j DOCKER-USER

4.3 Fade — tự map path trước lời giải

4.4 Lời giải — map kịch bản

Cơ chế: routing decision sau PREROUTING tách local vs forward. Publish port đổi địa chỉ đích sớm (DNAT) nên gói “tưởng vào host:8080” có thể không còn là local-delivery thuần — vì thế rule UFW trên INPUT dễ bị bypass cảm giác: traffic đã rẽ sang path NAT/forward trước khi bạn tưởng tượng “firewall host cổ điển”. Chi tiết DNAT publish → Module 2 bài 05; ở đây chỉ cần đúng hook.

5. Docker survey — chain và rule tự thêm

Phạm vi bài: đọc và định vị rule Docker bridge. Không viết lại toàn bộ graph NAT; không tắt iptables daemon option nếu chưa hiểu hệ quả (docs Docker: tắt dễ gãy masquerade / isolation).

5.1 filter — FORWARD và họ DOCKER*

Trên host có Docker bridge, bạn thường thấy (tên chain có thể thêm bớt theo version Engine — đọc máy bạn):

Docker docs: khi Engine bật IP forwarding, nó có thể set default FORWARD policy DROP và chỉ ACCEPT những gì rule Docker (và DOCKER-USER) cho qua — host không tự thành router mở cho mọi iface trừ khi bạn chủ động cho phép.

# Survey filter path (host with Docker)
sudo iptables -L FORWARD -n -v
sudo iptables -L DOCKER-USER -n -v
sudo iptables -L DOCKER -n -v 2>/dev/null || true
# Newer engines may show DOCKER-FORWARD, DOCKER-BRIDGE, ...
sudo iptables -L -n -v | head -80

Vì sao append -A FORWARD ... của bạn “không chạy”?
Nếu đầu chain FORWARD đã -j DOCKER-USER và gói ACCEPT/DROP xong trong nhánh Docker, rule bạn append cuối FORWARD không bao giờ thấy gói. Đúng chỗ policy user: DOCKER-USER (insert/append trong chain đó), không phải “cuối FORWARD cho chắc”.

5.2 nat — MASQUERADE và chain DOCKER

sudo iptables -t nat -L -n -v
sudo iptables -t nat -L POSTROUTING -n -v
sudo iptables -t nat -L DOCKER -n -v 2>/dev/null || true

Deep cơ chế SNAT/MASQUERADE từng bước + lab → 04 — Container ra Internet (SNAT). Deep publish DNAT → 05 — Publish port (DNAT).

5.3 Liên hệ bridge — khi nào cần netfilter?

flowchart TB
    C["Container"] -->|"veth"| BR["docker0 bridge L2"]
    BR -->|"same subnet peer"| C2["Other container"]
    BR -->|"IP to gateway host"| L3["Host IP forward"]
    L3 --> FW["filter FORWARD + DOCKER*"]
    FW --> POST["nat POSTROUTING MASQUERADE"]
    POST --> WAN["Outside"]

6. Pitfall tổng hợp

❌ Nhầm 1: “Chặn/cho phép container bằng filter INPUT.”
✅ Path container bridge xuyên host là FORWARD (sau khi rời netns). INPUT là gói local host. Hardening chỉ soi INPUT → mù half path container.

❌ Nhầm 2: “Thêm rule -A FORWARD cuối chain là đủ kiểm soát Docker.”
✅ Docker jump sớm sang DOCKER-USER / chain riêng. Gói ACCEPT/DROP trong đó không rơi xuống rule append cuối. Dùng DOCKER-USER cho policy thêm (và nhớ: sau DNAT, match theo IP nội bộ container trừ khi dùng conntrack original dest — nâng cao).

❌ Nhầm 3: “FORWARD policy DROP = Docker hỏng hoàn toàn.”
✅ DROP default là bình thường khi Docker quản forward: rule ACCEPT có chọn lọc phải tồn tại. Hỏng khi mất jump/rule Docker (flush tay, firewall khác ghi đè) hoặc DOCKER-USER DROP nhầm — không phải “thấy DROP là gỡ Docker”.

❌ Nhầm 4: “Ping cùng bridge OK ⇒ netfilter ổn.”
✅ Ping L2/L3 nội bộ không chứng minh MASQUERADE/FORWARD egress. Checklist tách: L2/FDB (bài 03) → ip_forward → iptables -t nat -L -v + FORWARD -v.

❌ Nhầm 5: “iptables: false cho sạch rule host.”
✅ Docs Docker: tắt tạo rule dễ gãy masquerade/isolation/publish. Muốn siết policy: DOCKER-USER, không “tắt netfilter Docker” nếu chưa có thay thế đầy đủ.

📚 Deep Dive — man page & docs

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

• 00 — Tổng quan module — mảnh 4: kiểm soát gói sau stack + bridge.
• 01 — Linux network stack — softirq/sk_buff/vị trí hook; bài này đặt rule lên hook.
• 02 — Virtual network devices — veth đưa gói netns ↔ host trước khi filter/NAT.
• 03 — Linux bridge — L2 docker0; bài này = L3 forward + netfilter khi rời LAN ảo.
• Foundations — NAT và port forwarding — khái niệm SNAT/DNAT; đây là chỗ chúng bám trên Linux/Docker.
• M2 — Container ra Internet (SNAT) — đào MASQUERADE/SNAT có lab (defer từ survey bài này).
• M2 — Publish port (DNAT) — DNAT publish end-to-end.

Tóm tắt

• Netfilter = hook kernel trên path IP; iptables/nft = frontend khai rule.
• Tables: filter (allow/deny), nat (đổi addr/port), mangle (mark) — container hằng ngày: filter + nat.
• Chains: PREROUTING → routing → INPUT | FORWARD → POSTROUTING; OUTPUT cho gói local origin.
• Docker bridge: jump FORWARD → DOCKER-USER → …; nat DOCKER + MASQUERADE POSTROUTING — đọc counter trước khi sửa tay.
• Pitfall: nhầm INPUT, append FORWARD sau jump Docker, tưởng policy DROP = bug, tin ping L2 đủ chứng minh egress.
• Fade: tự map 3 kịch bản SSH / container→WAN / publish → đối chiếu bảng §4.4.
• SNAT/DNAT sâu = Module 2; Module 1 chỉ cần bản đồ đúng chỗ.

7. Tự kiểm tra

Bài tiếp theo: Tổng kết module — Linux network internals