NFS

nfs.md

Rất tốt! Việc /etc/exports đã allow cả dải /24 chứng minh rằng IP của client C (1.2.3.4) không bị chặn ở cấp độ cấu hình export NFS — loại trừ được một trong các nguyên nhân phổ biến.

---

Vậy hãy quay lại với hiện tượng quan trọng nhất trong tcpdump mà bạn cung cấp:

✅ TCP handshake thành công
❌ Client C gửi NFS request nhưng server A không phản hồi
🔁 A gửi lại SYN-ACK nhiều lần như thể bị "quên" hoặc mất session

---

✅ Phân tích lại ngữ cảnh kỹ hơn

Những điều đặc biệt trong kết quả:

• Client gửi đi cùng một request nhiều lần (xid 1072526911) mà không bao giờ nhận được phản hồi NFS
• NFS server gửi lại SYN-ACK lặp lại — dấu hiệu session TCP bị "mất trạng thái", thường do:
  • NAT timeout
  • conntrack (iptables) drop state
  • kernel TCP reset
  • hoặc xử lý mạng không đầy đủ (VD: asymmetric routing)

---

🔍 Giả thuyết mạnh nhất lúc này: conntrack/NAT/firewall làm mất session state

NFS là giao thức "stateful", nếu giữa chừng firewall hoặc NAT reset hoặc quên session, thì NFS server không còn biết phải trả lời ra sao.

---

✅ Các bước xử lý tiếp theo bạn nên thử

---

✅ 1. Kiểm tra conntrack trên NFS server (A)

sudo conntrack -L | grep 1.2.3.4

→ Nếu không thấy session hoặc bị "UNREPLIED", đó là vấn đề.

Xử lý: nếu server A dùng nhiều kết nối NAT hoặc bảng conntrack quá tải, bạn nên:

sudo sysctl -w net.netfilter.nf_conntrack_max=262144

Hoặc xóa session của client C:

sudo conntrack -D -s 1.2.3.4

---

✅ 2. Bật log packet bị drop trên firewall (nếu có)

Nếu đang dùng iptables, bạn có thể thêm rule log để xem có gói nào bị drop:

sudo iptables -A INPUT -j LOG --log-prefix "DROP_INPUT: " --log-level 4

Sau đó kiểm tra log:

sudo dmesg | grep DROP_INPUT

---

✅ 3. Kiểm tra asymmetric routing

Có thể server A trả lại qua một interface khác, hoặc qua gateway không phù hợp → khiến gói phản hồi không đến được client

Trên A:

ip route get 1.2.3.4

→ Kiểm tra xem đường trả về có đúng interface/gateway không

---

✅ 4. Bắt tcpdump trên interface khác của server A (nếu có nhiều NIC)

Đôi khi bạn bắt gói ở ens3 nhưng trả lời lại đi qua ens4 → bạn không thấy phản hồi chứ không phải không có

---

✅ 5. Restart nfsd và rpcbind để loại trừ bug

sudo systemctl restart nfs-server rpcbind

---

📌 Tổng kết lại hướng xử lý

Kiểm tra gì	Mục tiêu
✅ conntrack -L	Xác định connection có bị "quên" không
✅ ip route get	Xác định routing có đúng chiều về
✅ iptables/ufw logs	Có rule nào silently drop packet không
✅ tcpdump nhiều interface	Xác nhận gói phản hồi có thực sự được gửi

---

Nếu bạn gửi thêm:

• Output conntrack -L | grep 1.2.3.4
• Output ip route get 1.2.3.4
• iptables -L -n -v

→ Mình sẽ check và chỉ thẳng ra điểm bất thường giúp bạn luôn nhé!