2 giờ sáng, hệ thống giám sát PagerDuty réo rắt báo động. Ứng dụng web của bạn liên tục trả về lỗi 502 Bad Gateway và client liên tục than phiền về tình trạng connection reset by peer. Bạn vội vàng SSH vào con VPS đang chạy Nginx, nhưng không SSH được vào VPS Linux hoặc kết nối chập chờn, gõ một phím phải đợi 3 giây mới phản hồi.
Theo phản xạ, bạn gõ htop, CPU rỗi 80%, RAM mới dùng chưa tới một nửa. Bạn chạy lệnh ping ra ngoài, rớt ngẫu nhiên vài gói tin. Bạn bực mình gõ lệnh reboot. Ba phút sau, VPS khởi động lại, traffic trôi chảy, hệ thống xanh mượt. Nhưng là một SysAdmin hay DevOps Engineer thực thụ, bạn thừa hiểu: restart chỉ là liều thuốc giảm đau tạm thời. Gói tin mạng của bạn không tự nhiên bốc hơi. Nó đã bị chính nhân hệ điều hành (Kernel) loại bỏ (drop) ở một ngóc ngách nào đó do tràn bộ đệm, kẹt luật tường lửa ẩn, hoặc quá tải hàng đợi ngắt mềm.
Để chấm dứt vĩnh viễn cảnh mò mẫm vô vọng này, bài viết dưới đây sẽ đi sâu vào cách sửa lỗi VPS Linux mất kết nối bằng eBPF, công nghệ quan sát (observability) mạnh mẽ nhất tính đến năm 2026. Vậy rốt cuộc, vì sao các tool quốc dân lại phản bội chúng ta trong tình huống này, và làm thế nào để bắt quả tang nhân Linux đang ngầm drop packet của bạn?
Vì sao Ping, Tcpdump, Netstat bó tay trước rớt mạng ngầm?
Trong nhiều năm, anh em kỹ sư hạ tầng luôn mang theo bộ ba ping, tcpdump, netstat (hoặc ss) như những bảo bối trấn phái để troubleshoot mạng. Tuy nhiên, trước các sự cố hủy gói tin (packet drop) ngầm sâu trong Kernel, những công cụ này bộc lộ những điểm mù chí mạng.
tcpdump: Kẻ đứng sai chỗ
tcpdump bắt gói tin bằng cách lắng nghe tại một socket đặc biệt tên là AF_PACKET. Cơ chế này tạo ra hai điểm mù cực lớn:
- Bị mù ở chặng đầu (Ingress quá sớm): Nếu gói tin bị card mạng hoặc các chương trình lọc XDP (eXpress Data Path) hủy ngay khi vừa đến (trước khi Kernel kịp cấp phát cấu trúc bộ nhớ
sk_buff),tcpdumphoàn toàn không biết gói tin đó từng tồn tại. - Bị mù ở chặng cuối (Egress quá muộn): Ngược lại, khi gói tin đi vào hàm nhận lõi,
AF_PACKETsẽ nhân bản (clone) một bản sao đưa chotcpdumphiển thị lên màn hình. Tuy nhiên, bản gốc của gói tin tiếp tục đi sâu vào Kernel và có thể bị Netfilter (iptables) chặn lại, hoặc bị hủy do bộ đệm Socket (sk_rcvbuf) của ứng dụng bị tràn. Lúc này,tcpdumpbáo cáo gói tin hợp lệ, nhưng thực tế ứng dụng chả nhận được byte dữ liệu nào.
ping: Chiếc hộp đen đóng kín
Lệnh ping hoạt động theo cơ chế End-to-End (đầu – cuối). Nó ném một gói ICMP Echo Request đi và chờ phản hồi. Nếu gói tin bị drop ở bất kỳ hàm nào trong Kernel (ví dụ: mất định tuyến, kẹt tường lửa), ping chỉ trả về một thông báo vô hồn: Request timeout. Nó không thể cung cấp call stack (vết ngăn xếp) để chỉ cho bạn biết đích xác hàm nào mang tên ip_rcv hay nf_hook_slow đã hủy gói tin.
netstat / ss: Số liệu cộng dồn vô nghĩa
Khi chạy netstat -s, bạn có thể thấy bộ đếm packets pruned from receive queue tăng lên, chứng tỏ VPS đang quá tải. Nhưng vấn đề là: Bộ đếm này cộng dồn cho toàn bộ hệ thống. Bạn không thể biết gói tin bị hủy thuộc về IP nào, Port nào, của tiến trình (process) nào đang chạy.
Sức mạnh eBPF & CO-RE năm 2026: Trải nghiệm Compiler-Free
Để phá vỡ những điểm mù hẹp hòi đó, eBPF (Extended Berkeley Packet Filter) nổi lên như một cuộc cách mạng. Hãy hình dung eBPF như một cỗ máy ảo siêu nhẹ và an toàn tuyệt đối nằm ngay bên trong nhân Linux. Nó cho phép SysAdmin gắn các đoạn mã theo dõi (hook) trực tiếp vào hàng nghìn hàm nội bộ của Kernel để giám sát luồng mạng theo thời gian thực mà không làm suy giảm hiệu năng (overhead cực thấp).
Nhưng điều khiến eBPF thực sự trở thành giải pháp tối ưu của giới vận hành trong năm 2026 chính là kiến trúc CO-RE (Compile Once – Run Everywhere).
Trước đây, để chạy các script Python của BCC (BPF Compiler Collection), bạn phải cài đặt nguyên một bộ compiler LLVM/Clang nặng nề cùng hàng trăm MB gói kernel-headers lên con VPS production. Điều này không chỉ ngốn RAM, dung lượng đĩa mà còn tạo ra rủi ro bảo mật khổng lồ (tăng attack surface).
Với sự phổ biến của các nhân Linux hiện đại (từ 5.15 LTS đến 6.x LTS), Kernel giờ đây mang sẵn trong mình một cuốn từ điển siêu dữ liệu gọi là BTF (BPF Type Format). Nhờ BTF, các tool eBPF thế hệ mới được biên dịch sẵn (pre-compiled) bằng C/Rust/Go có thể chạy trực tiếp trên mọi VPS.
Bạn không cần cài trình biên dịch, không cần tải header. Mọi thứ hoạt động theo chuẩn Tải binary về và chạy (Compiler-Free), một bước tiến lớn cho các anh em quản trị hạ tầng Cloud tối giản.
Bộ 3 công cụ eBPF hạng nặng SysAdmin cần trang bị ngay
Để chuẩn bị cho cuộc rà soát nguyên nhân rớt gói, bạn không cần phải tự ngồi code eBPF bằng C. Cộng đồng mã nguồn mở đã đóng gói sẵn những công cụ dò tìm mạng cực kỳ tinh vi. Dưới đây là bộ 3 công cụ thực chiến bạn cần biết:
- pwru (Packet, Where Are You?): Một kiệt tác do đội ngũ Cilium phát triển.
pwrutự động gắn kprobe vào gần như mọi hàm xử lý mạng bên trong Kernel. Bạn chỉ cần nhập IP hoặc Port, nó sẽ trace (theo dấu) gói tin đó đi qua những hàm nào và đột ngột biến mất ở đâu. - retis (Red Hat): Nếu hạ tầng của bạn phức tạp với nhiều lớp mạng ảo hóa (như Open vSwitch, namespaces),
retischo phép bạn đặt bộ lọc kiểu tcpdump ở bất kỳ tracepoint sâu thẳm nào trong hệ điều hành. - dropwatch (eBPF version): Phiên bản nâng cấp của công cụ Linux kinh điển. Thay vì đoán mò bằng việc xem log và gỡ lỗi VPS một cách thủ công, nó bám chặt vào tracepoint
skb:kfree_skbđể hứng trọn vẹn Stack Trace (chuỗi hàm gọi) mỗi khi có một quyết định hủy gói tin được đưa ra.
4 bước thực chiến: Cách sửa lỗi VPS Linux mất kết nối bằng eBPF
Giờ là lúc xắn tay áo lên. Giả sử VPS của bạn đang gặp tình trạng khách hàng phàn nàn API timeout liên tục, thi thoảng mất kết nối. Hãy áp dụng quy trình chuẩn cách sửa lỗi VPS Linux mất kết nối bằng eBPF thông qua 4 bước sau.
Bước 1: Bắt lỗi TCP Drop & Retransmission với libbpf-tools
Thay vì dùng các script Python cũ rích trong thư mục /usr/share/bcc/tools/, chúng ta sẽ dùng bộ libbpf-tools thế hệ mới (chuẩn CO-RE). Bạn chỉ cần tải file binary tĩnh về VPS là có thể chạy ngay lập tức.
Đầu tiên, kiểm tra xem luồng TCP nào đang phải chật vật gửi lại dữ liệu do thất lạc trên đường truyền bằng lệnh tcpretrans:
./tcpretrans -cKết quả trả về:
LADDR:LPORT RADDR:RPORT RETRANSMITS
10.0.1.5:443 <-> 198.51.100.77:54123 1250
10.0.1.5:22 <-> 203.0.113.10:48201 2Nhìn vào kết quả, ta thấy traffic từ Client (198.51.100.77) đến Port 443 đang bị Retransmit tới 1250 lần. Chắc chắn có rớt mạng ngầm ở luồng này.
Tiếp theo, ta dùng tcpdrop (bản C binary) để xem chính xác Kernel có đang vứt bỏ các phân đoạn TCP này hay không:
./tcpdropĐầu ra Terminal in ra một Stack Trace:
TIME PID COMM SADDR:SPORT DADDR:DPORT STATE
02:15:00 0 swapper 10.0.1.5:443 198.51.100.77:54123 ESTABLISHED
tcp_drop+0x1
tcp_v4_do_rcv+0x135
ip_local_deliver_finish+0x62Đoạn log trên vô giá! tcpdump không bao giờ cho bạn thấy điều này. Nó khẳng định: Gói tin đã vào đến tận hàm TCP nhận (tcp_v4_do_rcv), nhưng ngay sau đó bị Kernel gọi hàm tcp_drop để hủy đi. Lỗi không nằm ở cáp mạng vật lý, lỗi nằm ở cấu hình bộ đệm giao thức TCP hoặc trạng thái kết nối.
Bước 2: Theo dấu hành trình gói tin bằng pwru
Nếu tcpdrop chưa đủ để bạn kết luận, hãy tung công cụ pwru vào sân để theo dõi toàn bộ hành trình của gói tin. (Tải file binary tĩnh từ Github của Cilium/pwru).
Ta lọc riêng luồng dữ liệu đi vào cổng 443:
sudo ./pwru --filter-dport 443 --output-tupleKết quả theo dấu lập tức hiện lên:
NETNS PID COMM IP ADDR:PORT DIRECTION FUNCTION
4026531992 0 <...> IPv4 198.51.100.77:54123 -> 10.0.1.5:443 INGRESS ip_rcv
4026531992 0 <...> IPv4 198.51.100.77:54123 -> 10.0.1.5:443 INGRESS nf_hook_slow
4026531992 0 <...> IPv4 198.51.100.77:54123 -> 10.0.1.5:443 INGRESS kfree_skb_reasonĐọc luồng này, bạn thấy gói tin vừa đi qua hàm xử lý IP (ip_rcv), chạm mặt hàm nf_hook_slow (nơi Netfilter duyệt các rule của iptables/nftables) thì ngay lập tức bốc hơi bởi hàm hủy kfree_skb_reason.
Thủ phạm đã lộ diện: 100% là do một rule Firewall nào đó trên VPS đang chặn luồng dữ liệu này lại.
Bước 3: Đọc mã lỗi skb_drop_reason từ Kernel bằng bpftrace
Bắt đầu từ phiên bản Linux 5.17+, Kernel đã bổ sung một tính năng tuyệt vời: Định danh lý do hủy gói skb_drop_reason. Nhân Linux hỗ trợ hơn 120 mã lỗi cụ thể (ví dụ: lỗi checksum, lỗi kẹt firewall, lỗi không tìm thấy socket).
Nếu bạn có sẵn công cụ đa năng bpftrace, chỉ cần 1 đoạn script ngắn gọn sau để hứng mọi lý do hủy thực sự (bỏ qua các gói được giải phóng tự nhiên khi truyền xong):
sudo bpftrace -e '
tracepoint:skb:kfree_skb
/args->reason > 2/
{
time("%H:%M:%S ");
printf("Dropped: COMM=%s PID=%d Reason=%d\n", comm, pid, args->reason);
print(kstack);
}'- Nếu kết quả báo
Reason=7(SKB_DROP_REASON_NETFILTER_DROP): Đích thị là do iptables. - Nếu
Reason=19(SKB_DROP_REASON_NO_SOCKET): Tức là ứng dụng (như Nginx) đã crash hoặc không hề lắng nghe trên port đó, khiến gói tin bơ vơ và bị hủy.
(Lưu ý thực chiến: Tính đến 2026, các nền tảng Observability cao cấp như Cilium Hubble hoặc Tetragon chạy eBPF ngầm đã tự động map các mã Reason dạng số này thành chữ [Human-readable] ngay trên Dashboard để bạn đọc hiểu dễ dàng).
Bước 4: Chẩn bệnh và kê toa 5 nguyên nhân gốc rễ
Từ Stack Trace và mã lý do bắt được, dưới đây là 5 căn bệnh phổ biến nhất gây rớt mạng trên VPS và cách dùng lệnh để xử lý dứt điểm.
1. Bảng theo dõi kết nối Conntrack đầy (nf_conntrack: table full)
- Chẩn bệnh: Vết ngăn xếp đi qua
nf_conntrack_in. Thường xảy ra khi VPS làm Proxy hoặc API Server nhận hàng chục nghìn request ngắn, khiến bảng theo dõi trạng thái bị tràn. - Kê toa: Tăng giới hạn tối đa ngay lập tức bằng
sysctl.sudo sysctl -w net.netfilter.nf_conntrack_max=262144
2. Rule Firewall chặn ngầm
- Chẩn bệnh: Lỗi tại
nf_hook_slownhư ta thấy ở Bước 2. Có thể do dịch vụ Fail2ban chặn nhầm IP, hoặc rule mạng Overlay của Docker cấu hình sai. - Kê toa: Kiểm tra lại tuần tự các rule.
sudo iptables -L -n -v --line-numbers
3. Tràn hàng đợi lõi CPU (Softnet Backlog / Time-squeeze)
- Chẩn bệnh: Lệnh
cat /proc/net/softnet_statthấy cột 2 (dropped) hoặc cột 3 (time_squeeze) tăng đều. VPS có lưu lượng mạng quá lớn, Kernel đẩy gói lên nhanh nhưng lõi CPU không kịp xử lý hết trong một chu kỳ ngắt mềm (SoftIRQ). - Kê toa: Nới rộng không gian lưu trữ đệm trung gian và tăng thời gian làm việc cho CPU.
sudo sysctl -w net.core.netdev_max_backlog=5000 sudo sysctl -w net.core.netdev_budget=600
4. Tràn hàng đợi vòng (Ring Buffer) của Card mạng (vNIC)
- Chẩn bệnh: Gói tin bị loại bỏ ngay từ giai đoạn đầu ở tầng Driver (các hàm có tiền tố
virtio_nethoặcmlx5e_). Lệnhethtool -S eth0báorx_missed_errorsnhảy số liên tục. Lượng burst traffic đánh vào quá gắt. - Kê toa: Tăng sức chứa phần cứng của card mạng lên tối đa (Lưu ý mạng sẽ chớp tắt vài mili-giây khi áp dụng).
sudo ethtool -G eth0 rx 4096 tx 4096
5. Ứng dụng đọc chậm làm tràn Socket Buffer
- Chẩn bệnh: Stack trace báo lỗi ở
tcp_v4_rcv, hệ thống vứt bỏ gói vì overrun. RAM nhiều nhưng ứng dụng (ví dụ các hệ thống tối ưu database VPS Linux chịu tải query lớn) bị kẹt I/O không kịp lấy dữ liệu ra khỏi bộ đệm nhận của OS. - Kê toa: Bơm thêm RAM giới hạn cho TCP Buffer.
sudo sysctl -w net.core.rmem_max=16777216 sudo sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
(Nhớ lưu các tham số sysctl vào /etc/sysctl.conf để không bị mất khi reboot VPS).
Giới hạn của eBPF: Khi nào mấu chốt nằm ngoài VPS?
Dù eBPF là khả năng quan sát toàn diện bên trong hệ điều hành Linux, một SysAdmin lão luyện cần phải biết giới hạn của công cụ. eBPF hoạt động bên trong Guest OS (Hệ điều hành của VPS), nghĩa là nó chỉ nhìn thấy sự kiện khi gói tin đã chạm vào card mạng ảo (vNIC) của bạn.
Nếu bạn cài đặt pwru, tcpdrop chạy mượt mà, log hoàn toàn sạch sẽ, không ghi nhận bất kỳ sự kiện drop nào nhưng Client vẫn báo lỗi timeout, thì mấu chốt nằm ở hạ tầng ảo hóa bên dưới. Rất có thể gói tin đã bị loại bỏ bởi:
- Security Groups / Network ACLs: Firewall ở cấp độ Control Panel của nhà cung cấp Cloud (như AWS, Google Cloud).
- Hệ thống Anti-DDoS lớp dưới: Switch vật lý hoặc Hypervisor của nhà cung cấp đã dùng XDP để drop các gói tin bất thường trước khi đẩy nó lên VPS của bạn.
Lúc này, hãy đóng Terminal lại, đăng nhập vào Cloud Dashboard để rà soát rule, hoặc mở ngay Ticket nhờ bộ phận Support can thiệp.
Câu hỏi thường gặp (FAQ)
1. Sử dụng công cụ eBPF để trace mạng có làm chậm VPS không?
Không. eBPF có overhead cực thấp, chương trình được compile JIT trực tiếp chạy trong Kernel. Khi không có sự kiện xảy ra, nó gần như không tiêu tốn CPU.
2. Tôi có cần cài đặt compiler (LLVM/Clang) lên VPS để dùng eBPF không?
Không cần thiết. Nhờ kiến trúc CO-RE và BTF trên các nhân Linux hiện đại (5.15+), bạn chỉ cần tải trực tiếp các file binary (libbpf-tools) về và chạy ngay lập tức.
3. eBPF có thể phát hiện lỗi do Cloud Firewall chặn không?
Không thể. eBPF chạy bên trong VPS, nó chỉ thấy được gói tin sau khi đã đi vào vNIC. Nếu bị Cloud Provider chặn ở vòng ngoài, eBPF sẽ không thể quan sát được.
4. Dùng pwru có thay thế hoàn toàn được tcpdump không?
Không. tcpdump dùng để bắt và phân tích nội dung gói tin (payload/pcap). pwru dùng để trace hành trình của gói tin qua các hàm Kernel. Nên dùng kết hợp cả hai để có cái nhìn toàn diện.
Kết luận
Sự cố mạng ngầm từng là một tình trạng đáng sợ, tốn của giới vận hành hàng chục giờ đồng hồ phân tích pcap mà không thu lại kết quả. Tuy nhiên, bằng việc áp dụng cách sửa lỗi VPS Linux mất kết nối bằng eBPF kết hợp với kiến trúc CO-RE, bạn đã chuyển đổi tư duy từ chẩn đoán qua triệu chứng sang xác định chính xác những hàm Kernel đang drop packet.
Các công cụ mạnh mẽ như pwru, tcpdrop (libbpf-tools) không chỉ giúp chẩn đoán sự cố trong vài phút mà còn chứng minh năng lực kiểm soát hạ tầng chuyên sâu của bạn. Trong môi trường Cloud Server, Proxy hay Microservices đan chéo phức tạp, làm chủ eBPF chính là làm chủ huyết mạch của hệ thống.
Tài liệu tham khảo
- eBPF – Introduction, Tutorials & Community Resources
- GitHub – iovisor/bcc: BCC – Tools for BPF-based Linux IO analysis, networking, monitoring, and more
- GitHub – cilium/pwru: Packet, where are you? — eBPF-based Linux kernel networking debugger
- How to retrieve packet drop reasons in the Linux kernel | Red Hat Developer
- Linux eBPF Tracing Tools