Debug container networking — nsenter và tcpdump

TL;DR: Sự cố mạng container hiếm khi “sửa bằng restart Docker”. Bạn vào đúng network namespace (nsenter -t <pid> -n sau docker inspect lấy PID, hoặc ip netns exec trên lab named), survey iface/route/ss/iptables trong view đó, rồi bắt gói (tcpdump) đúng điểm: eth container, veth host, bridge, iface WAN. Chẩn đoán layer-by-layer L2 → L3 → NAT host → app — không nhảy thẳng firewall INPUT. Pitfall số một: debug nhầm netns / nhầm đầu veth — lệnh đúng, view sai, kết luận sai.

UAT prep: service payments trong container không ping được peer 10.10.0.20 trên cùng bridge lab (cùng topology mini-challenge). Junior đã tcpdump -ni eth0 trên host lúc reproduce — im lặng — rồi kết luận “NIC host chết / ISP chặn ICMP”. Bạn hỏi: “gói bridge có đi qua eth0 WAN không?” · “ss/ip route đã chạy trong netns container chưa?” · “bắt gói trên veth/br0 hay eth vật lý?” Path L2/L3 trong LAN ảo không bắt buộc đi NIC ngoài. Im trên eth0 host là đúng nếu đứt trước khi ra WAN — không chứng minh “mạng host hỏng”.

Bài này ghép netns, veth, bridge, SNAT, DNAT thành runbook chẩn đoán. Fade independent: kịch bản ping fail — bạn chọn thứ tự bước trước khi mở đáp án runbook.

1. Analogy — Thợ điện vào đúng căn, đúng hộp cáp

Nhớ netns = căn hộ, veth = cáp nhảy, bridge = switch hành lang, SNAT = tem ra đường, DNAT = chuông ngoài → phòng. Debug mạng container giống thợ:

1. Vào đúng căn — nsenter/exec đúng netns, không đo điện căn kế.
2. Xem tủ trong căn — iface UP? IP? route? app cắm ổ nào (ss)?
3. Kẹp ampe đúng đoạn dây — tcpdump trên eth trong căn, hoặc đầu cáp hành lang (veth host), hoặc switch (br0), không kẹp ngẫu nhiên dây điện toà (eth WAN) khi sự cố chỉ trong hành lang.
4. Theo lớp — cáp/link (L2) → địa chỉ/route (L3) → sổ NAT/forward ở sảnh (host netfilter) → thiết bị trong phòng (app).

2. Vào đúng netns — nsenter lấy PID thế nào?

2.1 Vì sao ip netns list production thường “trống”?

Lab module dùng named netns (ip netns add c1) → file dưới /var/run/netns/c1, list được.

Runtime container (Docker/containerd) thường tạo anonymous network namespace gắn process: bạn không thấy tên trong ip netns list, nhưng kernel vẫn có object netns. “Cửa vào” ổn định là PID process trong container (thường PID 1 trong pid ns container = process chính trên host view qua inspect).

2.2 Lấy PID — docker inspect

# Replace NAME with container name or ID
CID=$(docker ps --format '{{.Names}}' | head -n1)   # pick carefully in real work
PID=$(docker inspect -f '{{.State.Pid}}' "$CID")
echo "container=$CID pid=$PID"

• State.Pid == 0 → container không running (stopped/created). Không nsenter được netns sống.
• Cần quyền đủ để đọc /proc/<pid>/ns/net (thường root / cap phù hợp).

Tương đương mental model không Docker: lab named c1 không cần PID — dùng ip netns exec c1 …. Production: PID là “tên” thực dụng.

2.3 nsenter -t <pid> -n — join chỉ network namespace

# Enter network ns of that PID, run one command, exit
sudo nsenter -t "$PID" -n ip -br addr
sudo nsenter -t "$PID" -n ip route
sudo nsenter -t "$PID" -n ss -lntp

Cơ chế bên dưới: nsenter gọi setns() trên file /proc/<pid>/ns/net. Process con sau đó resolve iface/route/socket theo netns đó. Cùng kernel, khác view — đã map ở bài 01.

flowchart LR
    INS["docker inspect State.Pid"] --> PID["PID on host"]
    PID --> NS["/proc/PID/ns/net"]
    NS --> ENT["nsenter -t PID -n"]
    ENT --> VIEW["ip / ss / tcpdump in container netns"]

2.4 Ba cách vào — chọn theo ngữ cảnh

Xác nhận đã đúng ns (so sánh inode):

# Host init netns vs container netns — different inode = different stack
readlink /proc/self/ns/net
sudo nsenter -t "$PID" -n readlink /proc/self/ns/net
# Optional: which netns is this PID in?
sudo ip netns identify "$PID" 2>/dev/null || true

Hai dòng readlink trùng → bạn chưa vào netns container (PID sai, container share host net --network host, hoặc không đủ quyền).

3. Survey trong netns — route, ss, iptables

Sau khi đúng view, survey theo thứ tự ngắn — đừng nhảy iptables -F.

3.1 Link + địa chỉ (L2/L3 foundation)

sudo nsenter -t "$PID" -n ip -br link
sudo nsenter -t "$PID" -n ip -br addr

Checklist nhanh:

3.2 Route (L3)

sudo nsenter -t "$PID" -n ip route

• Cùng subnet bridge: cần connected route (thường tự có khi gán 10.10.0.10/24).
• Ra ngoài subnet / Internet: cần default via <gateway-bridge> (vd 10.10.0.1).
• Thiếu default → ping 8.8.8.8 fail dù ping peer cùng /24 có thể OK.

3.3 App listen (ss) — trong ns

sudo nsenter -t "$PID" -n ss -lntp
# So sánh với host (thường KHÔNG thấy bind container trừ publish/proxy)
ss -lntp | head

Publish DNAT (bài 05): client hit host:port; app listen trong netns trên container port. ss host xanh không chứng minh app listen; ss trong ns mới là nguồn sự thật bind.

3.4 iptables — hai ruleset

# Inside container netns — often empty / default on simple bridge apps
sudo nsenter -t "$PID" -n iptables -L -n -v 2>/dev/null | head

# Host netns — where Docker SNAT/DNAT/FORWARD live
sudo iptables -L FORWARD -n -v | head
sudo iptables -t nat -L -n -v | head

4. tcpdump trong namespace và trên host path

4.1 Điểm bắt — chọn theo giả thuyết

flowchart TB
    APP["app / ping in c1"] --> ETH["c1 eth0 — tcpdump in ns"]
    ETH --> V["veth-c1 host — tcpdump host"]
    V --> BR["br0"]
    BR --> V2["veth-c2 / peer"]
    BR --> NAT["host L3 + NAT / FORWARD"]
    NAT --> WAN["eth0 WAN"]

4.2 Lệnh mẫu

# A) Inside container netns (nsenter keeps host tools available)
sudo nsenter -t "$PID" -n tcpdump -ni eth0 -nn icmp

# B) Lab named netns
sudo ip netns exec c1 tcpdump -ni c1-eth0 -nn icmp

# C) Host end of veth (name from `ip -br link` / docker network inspect)
sudo tcpdump -ni veth-c1 -nn icmp

# D) Bridge
sudo tcpdump -ni br0 -nn icmp

Reproduce trong lúc capture (terminal khác):

sudo ip netns exec c1 ping -c 3 10.10.0.20
# or: docker exec payments ping -c 3 10.10.0.20

4.3 Đọc kết quả (mental model)

Vì sao không bắt đầu bằng tcpdump eth0 host cho mọi triệu chứng?
Gói cùng bridge đổi chéo container không cần đi NIC vật lý. Capture WAN im lặng tương thích với sự cố L2/L3 nội bộ — đúng như hook UAT.

5. Runbook layer-by-layer: L2 → L3 → NAT → app

Đây là khung dùng lại mỗi ticket. Mỗi tầng PASS mới xuống tầng dưới (hoặc lên lại khi bằng chứng mâu thuẫn).

flowchart TB
    S["Symptom: connectivity fail"] --> L2{"L2: link UP? veth pair? bridge master?"}
    L2 -->|"fail"| F2["Fix link / veth / bridge port"]
    L2 -->|"ok"| L3{"L3: IP? connected route? default gw?"}
    L3 -->|"fail"| F3["Fix addr / route in correct netns"]
    L3 -->|"ok"| NAT{"Need NAT path? egress or publish?"}
    NAT -->|"LAN only"| APP{"App listen / ICMP / policy in ns?"}
    NAT -->|"egress"| EG["Host: ip_forward + FORWARD + MASQUERADE"]
    NAT -->|"publish"| IN["Host: DNAT PREROUTING + FORWARD + bind"]
    EG --> CAP["tcpdump + counters to confirm"]
    IN --> CAP
    APP --> CAP

5.1 L2 — cáp và switch ảo

1. Trong ns: ip -br link — iface data UP.
2. Host: peer veth tồn tại, UP, master đúng bridge (nếu bridge mode).
3. bridge link / ip -d link show <veth> — không “Device not found” một phía.
4. Cần ARP: ip neigh trong ns; tcpdump ARP khi nghi L2.

5.2 L3 — IP và route trong đúng ns

1. ip -br addr — IP/mask đúng plan.
2. ip route — connected + default (nếu ra ngoài subnet).
3. ping gateway bridge (10.10.0.1) trước peer/WAN — chia “LAN ảo” vs “ra host L3”.

5.3 NAT / filter trên host (khi path cần)

5.4 App

1. Process running? ss -lntp trong ns.
2. Bind 0.0.0.0 vs 127.0.0.1 trong container.
3. Security group / NetworkPolicy (Module 3) — ngoài scope M2 nhưng cùng mental model “filter đúng chỗ”.

5.5 Bảng “triều chứng → tầng ưu tiên”

6. Independent — kịch bản ping fail (chọn bước trước đáp án)

Bài fadeLevel: independent: bạn tự chọn thứ tự chẩn đoán. §6.2 chỉ định hướng. §6.3 là đáp án runbook — đừng mở sớm nếu muốn luyện.

6.1 Đề bài (symptom only)

Topology lab (giống mini-challenge + peer):

Triệu chứng (UAT):

# From c1:
ping -c 2 10.10.0.20
# → 100% packet loss (timeout)

# Junior already did (on HOST):
tcpdump -ni eth0 icmp   # silent during ping
# Conclusion junior: "host NIC / uplink broken"

Nhiệm vụ của bạn (viết ra giấy / note trước khi mở §6.3):

1. Junior sai giả định nào khi bắt eth0 host?
2. Liệt kê 4–6 bước bạn sẽ chạy theo thứ tự (lệnh + view: host vs c1 vs c2).
3. Với mỗi bước, kỳ vọng nếu L2 OK / nếu veth đứt / nếu chỉ thiếu route một phía.
4. Chỉ khi nào bạn mới đụng iptables -t nat trong ticket này?

Không cần “đoán root cause bí mật duy nhất” — lab thật có thể hỏng ở nhiều tầng. Mục tiêu: thứ tự đúng + view đúng.

6.2 Gợi ý (không lộ đáp án đầy đủ)

6.3 Đáp án runbook (mở sau khi đã viết bước)

1) Bác bỏ giả định WAN trước

Ping 10.10.0.10 → 10.10.0.20 là on-link / bridge L2+L3 trong LAN ảo. Frame không cần eth0 WAN. tcpdump -ni eth0 im không chứng minh hỏng uplink — chứng minh “không có ICMP ra WAN”, đúng với traffic nội bridge.

2) Vào đúng netns c1 — survey L2/L3

sudo ip netns exec c1 ip -br link
sudo ip netns exec c1 ip -br addr
sudo ip netns exec c1 ip route

Kỳ vọng lành: c1-eth0 UP, 10.10.0.10/24, connected 10.10.0.0/24, default via 10.10.0.1.
Nếu thiếu iface/IP/route → sửa tầng này trước, chưa tcpdump WAN.

(Production Docker: thay ip netns exec c1 bằng nsenter -t $(docker inspect -f '{{.State.Pid}}' payments) -n.)

3) Survey c2 đối xứng

sudo ip netns exec c2 ip -br link
sudo ip netns exec c2 ip -br addr
sudo ip netns exec c2 ip route

One-way: c1 đẹp, c2 DOWN hoặc thiếu IP → ping fail.

4) Host path L2: veth + bridge

ip -br link | egrep 'br0|veth'
bridge link 2>/dev/null || ip link show master br0

Hai host-end UP + master br0. Thiếu master = “cáp không cắm switch”.

5) tcpdump hai điểm (không eth WAN)

Terminal A:

sudo ip netns exec c1 tcpdump -ni c1-eth0 -nn icmp

Terminal B:

sudo ip netns exec c2 tcpdump -ni c2-eth0 -nn icmp

Terminal C (reproduce):

sudo ip netns exec c1 ping -c 3 10.10.0.20

Tuỳ chọn host: tcpdump -ni br0 -nn icmp hoặc tcpdump -ni veth-c1.

6) NAT?

Với chỉ ping peer cùng 10.10.0.0/24 trên bridge: chưa cần MASQUERADE/DNAT. Chỉ leo host FORWARD/nat khi triệu chứng là egress WAN hoặc publish port — ticket này chưa đưa bằng chứng đó.

7) App

ICMP không cần process listen. Nếu đổi triệu chứng sang TCP curl 10.10.0.20:80 → thêm ss -lntp trong c2.

6.4 Tự chấm independent

• Đã viết thứ tự trước khi đọc §6.3
• Không lấy “im eth0 host” làm proof uplink chết cho traffic bridge
• Có bước vào netns (exec/nsenter) trước kết luận host-wide
• Có tcpdump trên path bridge/veth/ns, không chỉ WAN
• NAT chỉ khi path thật sự cần NAT

6.5 Pitfall tổng hợp

❌ Nhầm 1: Debug nhầm network namespace.
✅ Mọi ip/ss/tcpdump không gắn nsenter/netns exec/docker exec là host view. So readlink /proc/self/ns/net trước/sau. PID inspect = 0 → container không chạy.

❌ Nhầm 2: tcpdump nhầm đầu veth / nhầm iface.
✅ Pair có hai đầu (netns + host). Im một đầu ≠ “không có gói trên wire”. Ghi rõ tên iface từ ip -br link mỗi phía.

❌ Nhầm 3: Mọi fail đều “NAT/firewall INPUT”.
✅ Ping cùng bridge: L2/L3 trước. Egress: FORWARD + POSTROUTING. Publish: PREROUTING DNAT + FORWARD. INPUT là bẫy mental model service host.

❌ Nhầm 4: Tin docker exec đủ khi image không có tool.
✅ Image distroless/alpine tối → thiếu tcpdump/ip. nsenter -t PID -n dùng binary host trong net view container.

❌ Nhầm 5: --network host mà vẫn “nsenter tìm eth0 container”.
✅ Host network = chung netns host. readlink trùng host; không có “eth0 container” tách. Debug như process host.

❌ Nhầm 6: Capture không reproduce song song.
✅ Mở tcpdump trước, rồi mới ping/curl. Capture sau sự cố = luôn “im”.

# Cleanup lab names if you recreated c1/c2/br0 for practice
# sudo ip netns del c1; sudo ip netns del c2; sudo ip link del br0

📚 Deep Dive — man page & docs

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

• 01 — Network namespaces — isolation view; bài này vào view production bằng PID.
• 02 — Veth — hai đầu cáp; tcpdump từng đầu khi one-way.
• 03 — Mini-challenge bridge — topology lab ping fail §6.
• 04 — SNAT/MASQUERADE — tầng NAT egress trong runbook.
• 05 — DNAT publish — tầng NAT inbound + bind pitfall.
• M1 — Linux network stack — tcpdump ≠ process đã recv.
• M1 — iptables — FORWARD vs INPUT, counter -v.

Tóm tắt

• Debug container = đúng netns + survey + tcpdump đúng điểm + runbook L2 → L3 → NAT → app.
• docker inspect → State.Pid → nsenter -t <pid> -n (hoặc ip netns exec / docker exec).
• Ruleset iptables tách theo ns; NAT Docker sống host; LAN bridge fail thường chưa phải NAT.
• tcpdump eth WAN im không kết án uplink khi traffic chỉ trong bridge.
• Pitfall tối thượng: wrong netns / nhầm đầu veth / soi INPUT thay FORWARD.
• Independent: kịch bản ping fail — tự xếp bước trước đáp án §6.3.

7. Tự kiểm tra

Bài tiếp theo: Tổng kết module Container Networking