Container ra Internet — SNAT và MASQUERADE

TL;DR: Container mang IP private trên bridge (ví dụ 10.10.0.10) không tự “thấy” Internet. Host phải forward gói giữa bridge và NIC ra ngoài (net.ipv4.ip_forward=1), cho phép path filter FORWARD, rồi rewrite nguồn bằng MASQUERADE hoặc SNAT trên nat POSTROUTING — server ngoài chỉ thấy IP host, conntrack nhớ mapping để reply về đúng container. Đường gói: container → veth → bridge → host L3 → NAT → WAN. Pitfall kinh điển: FORWARD policy DROP (LAN ảo sống, Internet chết) hoặc quên masquerade (gói ra với source private → reply không về).

Sprint review staging: bridge lab kiểu mini-challenge vừa xong — c1 ping c2 mượt. Product owner demo “service trong container gọi payment API”. Host curl API OK. Trong netns c1, curl timeout. Junior đã iptables -L INPUT và bảo “firewall host chặn”. Bạn hỏi ba câu: “sysctl net.ipv4.ip_forward?” · “gói container ra WAN đi FORWARD hay INPUT?” · “iptables -t nat -L POSTROUTING -n -v còn MASQUERADE/SNAT cho subnet bridge không?” Bridge L2 lành; path forward + NAT egress mới thiếu — không phải payment “chậm”.

Khái niệm SNAT/MASQUERADE đã có ở Foundations — NAT & port forwarding; bản đồ hook/chain ở M1 — iptables & netfilter. Bài này trace end-to-end trên topology container/bridge và implement egress bằng tay.

Bài này faded: lab worked dựng ip_forward + MASQUERADE; bạn tự điền rule FORWARD khi policy DROP và tự chọn SNAT tĩnh trước khi đối chiếu đáp án.

1. Analogy — Toà nhà ra đường: cổng hành lang + tem địa chỉ

Nhớ netns = căn hộ và bridge = switch hành lang. Container gọi Internet giống nhân viên phòng nội bộ gọi ra ngoài:

1. Cổng hành lang xuyên toà phải mở — host cho gói đi xuyên từ bridge sang NIC WAN (ip_forward + chain FORWARD).
2. Tem địa chỉ ra đường — số phòng 10.10.0.10 không route trên Internet. Lễ tân dán số toà (IP host) lên phong bì đi ra, ghi sổ cuộc gọi (NAT table / conntrack).
3. Tem dán lúc ra cửa — đúng chỗ POSTROUTING (sau khi đã biết “ra iface nào”), không phải lúc còn trong phòng.
4. Reply về số toà + “nhánh” (port) → sổ cuộc gọi trả về đúng phòng.

2. Đường gói: container → bridge → host → NAT → out

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

Dùng lại plan IP quen thuộc (hoặc topology Docker 172.17.0.0/16 — cùng mental model):

flowchart LR
    subgraph C1["Netns c1"]
        APP["curl / app"]
        ETH["c1-eth0 10.10.0.10"]
    end
    subgraph HOST["Init / host netns"]
        V["veth-c1"]
        BR["br0 10.10.0.1"]
        FW["filter FORWARD"]
        NAT["nat POSTROUTING MASQUERADE"]
        PHY["eth0 WAN"]
    end
    WAN["Outside"]
    APP --> ETH
    ETH -->|"veth peer"| V
    V --> BR
    BR --> FW
    FW --> NAT
    NAT --> PHY
    PHY --> WAN

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

1. Trong netns c1: app gửi gói src=10.10.0.10 dst=8.8.8.8. Default route → gateway 10.10.0.1 dev c1-eth0.
2. Veth peer: frame sang veth-c1 trên host; bridge br0 nhận (L2 trong LAN ảo).
3. Gateway = host: IP 10.10.0.1 thuộc host → kernel host route gói ra iface WAN (eth0), không deliver local process → path forward.
4. filter FORWARD: policy/rule phải ACCEPT (hoặc jump chain cho phép). DROP ở đây = timeout dù ip route trong container đẹp.
5. nat POSTROUTING: MASQUERADE hoặc SNAT đổi src thành IP host trên iface egress. Server ngoài thấy host, không thấy 10.10.0.10.
6. Conntrack: kernel ghi mapping (src/dst/port) để reply reverse-NAT về 10.10.0.10 rồi đẩy lại bridge/veth vào netns.

Vì sao thiếu NAT thì “có lúc ra được” nhưng reply chết?
Một số mạng lab lỏng có thể forward gói source private; trên Internet thật, router/ISP không route 10.0.0.0/8 / 172.16/12 / 192.168/16 về bạn. Kể cả gói request “lọt”, reply không có đường về đúng host:port đã map — triệu chứng hay gặp: tcpdump thấy SYN ra, không có SYN-ACK về container.

2.3 ip_forward — công tắc router trên host

# Read current (0 = off, 1 = on)
sysctl net.ipv4.ip_forward
# or:
cat /proc/sys/net/ipv4/ip_forward

# Enable until reboot (lab)
sudo sysctl -w net.ipv4.ip_forward=1

Docker Engine khi dùng bridge network thường bật forwarding giúp bạn. Lab from-scratch / hardening playbook / “tắt IP forward cho an toàn” hay để 0 → đúng class lỗi sprint review đầu bài.

3. MASQUERADE vs SNAT — khác nhau chỗ nào khi đổi nguồn?

Cả hai là Source NAT trên POSTROUTING (chiều egress). Foundations: SNAT/MASQUERADE.

# Pattern A — MASQUERADE (Docker-like): traffic from bridge subnet leaving non-bridge ifaces
sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 ! -o br0 -j MASQUERADE

# Pattern B — SNAT static (only if you know stable egress IP)
# sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 ! -o br0 -j SNAT --to-source 203.0.113.10

Vì sao ! -o br0?
Tránh SNAT traffic nội bộ bridge (container ↔ container) khi không cần. Chỉ rewrite khi gói rời domain bridge ra iface khác.

DNAT không phải bài này. Publish host:8080 → container:80 là bài 05 — đổi đích ở PREROUTING. Egress API call = đổi nguồn POSTROUTING.

4. Worked lab — bật egress cho một “container”

Chạy trên Linux có netns + iptables + sudo. macOS/Docker Desktop host không thay view ip netns Linux. Lab cần path ra ngoài thật (NIC/wifi host có default route) hoặc bạn tự dựng peer “WAN giả” — dưới đây giả định host đã ping 8.8.8.8 OK.

4.1 Skeleton tối thiểu (1 netns + bridge)

Nếu còn topology mini-challenge (c1/c2/br0) có thể tái dùng c1. Skeleton gọn:

# --- cleanup leftovers (safe if missing) ---
sudo ip netns del c1 2>/dev/null || true
sudo ip link del br0 2>/dev/null || true

# --- bridge + one container netns ---
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

# Prove L3 to gateway (LAN only — not Internet yet)
sudo ip netns exec c1 ping -c 2 10.10.0.1

Gateway OK không đồng nghĩa Internet OK.

4.2 Predict — trước khi bật NAT

4.3 Chứng minh fail lớp forward/NAT (rồi bật từng lớp)

# Often 0 on hardened/lab hosts
sysctl net.ipv4.ip_forward

# Try from container (expect fail or no useful replies while forward/NAT missing)
sudo ip netns exec c1 ping -c 2 8.8.8.8 || true

Bật forward:

sudo sysctl -w net.ipv4.ip_forward=1

Chỉ bật forward chưa đủ nếu:

• filter FORWARD policy DROP và không có rule ACCEPT, hoặc
• không có MASQUERADE/SNAT.

Rule lab tối thiểu (iptables):

# Forward path: allow bridge <-> rest (lab-simple; tighten later)
sudo iptables -A FORWARD -i br0 -j ACCEPT
sudo iptables -A FORWARD -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Egress SNAT dynamic
sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 ! -o br0 -j MASQUERADE

# Verify
sysctl net.ipv4.ip_forward
sudo iptables -L FORWARD -n -v
sudo iptables -t nat -L POSTROUTING -n -v

Thử lại từ container:

sudo ip netns exec c1 ping -c 3 8.8.8.8
# If ICMP blocked on your network, try TCP/HTTP instead when available:
# sudo ip netns exec c1 curl -sS -o /dev/null -w "%{http_code}\n" --connect-timeout 5 https://example.com || true

Đọc counter: chạy ping/curl lại, xem dòng MASQUERADE và rule FORWARD pkts tăng — bằng chứng gói đi đúng chain (cùng thói quen survey M1).

sudo iptables -t nat -L POSTROUTING -n -v
sudo iptables -L FORWARD -n -v

5. Fade — FORWARD DROP và SNAT tĩnh

5.1 Tự chẩn: policy DROP

sudo iptables -P FORWARD DROP
# (không đụng POSTROUTING — MASQUERADE vẫn còn)

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

1. filter FORWARD — policy DROP + không rule ACCEPT khớp path bridge ↔ WAN. NAT table còn cũng vô ích nếu gói đã DROP trước khi ra POSTROUTING hữu ích / hoặc chiều về bị chặn.
2. Lab tối thiểu (giống §4.3): ACCEPT từ -i br0 ra ngoài; ACCEPT -o br0 cho RELATED,ESTABLISHED (reply). Hoặc siết theo iface WAN cụ thể. Không cần -P FORWARD ACCEPT nếu rule đủ.

# Re-check policy and counters after you add rules
sudo iptables -L FORWARD -n -v
sudo ip netns exec c1 ping -c 2 8.8.8.8

5.2 Tự chọn: MASQUERADE hay SNAT?

Chuyển lab sang SNAT (khi biết IP egress host):

# Discover IPv4 on uplink (example: eth0 — use YOUR iface name)
ip -br addr show eth0

# Swap: delete MASQUERADE rule you added, add SNAT (adjust addresses)
sudo iptables -t nat -D POSTROUTING -s 10.10.0.0/24 ! -o br0 -j MASQUERADE
# Example only — replace 203.0.113.50 with your real egress IPv4:
# sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 ! -o br0 -j SNAT --to-source 203.0.113.50

Nếu ghim sai IP (không phải IP đang có trên iface egress) → request “ra” trông lạ, reply không về host — cùng class “NAT lệch”.

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

❌ Nhầm 1: “Ping container↔container OK ⇒ Internet OK.”
✅ Ping cùng bridge chỉ chứng minh L2/L3 LAN ảo (lab 03). Egress cần ip_forward + FORWARD + MASQUERADE/SNAT.

❌ Nhầm 2: “Soi iptables -L INPUT khi container không ra ngoài.”
✅ Path xuyên host là FORWARD (+ nat POSTROUTING). INPUT là gói tới process host.

❌ Nhầm 3: “Chỉ bật ip_forward=1 là xong.”
✅ Forward bật nhưng policy FORWARD DROP hoặc thiếu NAT → vẫn chết. Ba công tắc, không một.

❌ Nhầm 4: “MASQUERADE và SNAT là hai chiều khác nhau (ra/vào).”
✅ Cả hai là đổi nguồn egress. Chiều vào publish port là DNAT (bài 05).

❌ Nhầm 5: “Flush iptables -F / -t nat -F cho sạch rồi container vẫn ra ngoài.”
✅ Dễ xoá MASQUERADE Docker + rule FORWARD Engine — outage hàng loạt. Sửa policy user qua chỗ đúng (DOCKER-USER trên host Docker), không flush mù.

# Cleanup THIS lesson's lab objects (iptables rules you added — delete explicitly)
sudo iptables -D FORWARD -i br0 -j ACCEPT 2>/dev/null || true
sudo iptables -D FORWARD -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 2>/dev/null || true
sudo iptables -t nat -D POSTROUTING -s 10.10.0.0/24 ! -o br0 -j MASQUERADE 2>/dev/null || true

sudo ip netns del c1 2>/dev/null || true
sudo ip link del br0 2>/dev/null || true
# Deleting netns removes moved veth ends with it

flowchart TB
    A["Symptom: container curl WAN timeout"] --> B{"Ping gateway / peer on bridge?"}
    B -->|"no"| L2["Fix veth/bridge/IP/route in netns"]
    B -->|"yes"| C{"ip_forward == 1?"}
    C -->|"no"| FWD["sysctl ip_forward=1"]
    C -->|"yes"| D{"FORWARD counters / policy"}
    D -->|"DROP no accept"| FW["Add/fix FORWARD path"]
    D -->|"accept path OK"| E{"nat POSTROUTING MASQUERADE/SNAT?"}
    E -->|"missing"| NAT["Add MASQUERADE or SNAT"]
    E -->|"present"| APP["DNS / app / upstream — next"]

📚 Deep Dive — man page & docs

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

• 03 — Mini-challenge bridge from scratch — LAN ảo + gateway; bài này thêm cửa ra Internet.
• 01 — Network namespaces — stack riêng; NAT rule nằm host netns, không “tự có” trong container.
• 05 — Publish port DNAT — chiều vào (đổi đích); bổ đôi với egress SNAT.
• 06 — Debug nsenter / tcpdump — bắt gói đúng netns khi NAT/forward lệch.
• M1 — iptables & netfilter — hook FORWARD/POSTROUTING + survey Docker.
• Foundations — NAT & port forwarding — SNAT/MASQUERADE/DNAT khái niệm; bài này implement trên bridge container.

Tóm tắt

• Container private ra Internet = host ip_forward=1 + filter FORWARD cho path bridge ↔ WAN + nat POSTROUTING MASQUERADE hoặc SNAT.
• Đường gói: netns → veth → bridge → L3 host → FORWARD → rewrite source → WAN; reply nhờ conntrack.
• MASQUERADE = SNAT theo IP iface egress (IP động / Docker default); SNAT tĩnh khi IP ổn định.
• Ping cùng bridge không chứng minh egress; debug INPUT trước = nhìn nhầm chain.
• Pitfall: FORWARD DROP, quên masquerade, flush nat Docker, nhầm SNAT với DNAT.
• Fade: tự chẩn DROP + tự chọn MASQUERADE/SNAT theo kiểu host.

7. Tự kiểm tra

Bài tiếp theo: Publish port — DNAT từ host vào container