Fail2Ban là công cụ mà rất nhiều người dùng hàng ngày — cài, viết vài dòng jail.conf, thấy log báo "Ban 1.2.3.4" là yên tâm. Nhưng ít ai mở source code ra xem thật sự bên trong nó chạy như thế nào: vì sao có 2 lệnh fail2ban-client và fail2ban-server riêng biệt? Vì sao log bị xoay vòng (logrotate) mà fail2ban không đọc nhầm hay đọc sót? Cái gọi là "ticket" thực chất là gì? Và vì sao thiết kế cũ kỹ từ 2004 vẫn còn sống tốt đến tận 2026?
Hầu hết tài liệu về nftables — kể cả trang chính thức của Ubuntu — dừng lại ở mức "đây là cú pháp, đây là ví dụ nft add rule". Rất ít tài liệu trả lời những câu hỏi nằm ngay bên dưới: nft list ruleset thật ra đang hỏi ai? Vì sao nft có thể gộp nhiều lệnh add table lại thành 1 giao dịch atomic mà không cần khóa toàn bộ ruleset? "Bytecode" mà tài liệu Ubuntu nhắc tới thực chất là gì — có phải mã máy biên dịch sẵn không? Và vì sao iptables sau Ubuntu 20.10 vẫn chạy được, nhưng ufw lại không đụng được vào rule nftables thuần?
Bài nftables cầm 1 server Linux thật, viết 1 ruleset thật, và đi qua những use case gặp nhiều nhất trong vận hành — chặn SSH brute-force mà không cần fail2ban, NAT cho router, rate-limit chống flood, quản lý allowlist/denylist lớn, và cách reload ruleset mà không tự đá mình ra khỏi SSH session.
Phần 13/21 trong loạt Open vSwitch (OVS) — nối tiếp Phần 12, nơi Mục 4 đã liệt kê sơ field ct_state (32-bit, read-only, dùng dạng +trk+new/+trk+est...) rồi hẹn lại đúng câu: "packet chưa đi qua action ct() thì mọi field connection-tracking đều bằng 0 (trạng thái 'untracked'); Bài 13 sẽ đào sâu toàn bộ cơ chế conntrack, bao gồm chính xác các flag trk/new/est/rel nghĩa là gì và khi nào dùng". Đây là bài thứ hai của Module 3 — Nâng cao, tiếp tục dùng đúng khái niệm multi-table pipeline vừa học ở Bài 12 — rule stateful gần như luôn được tách riêng ra một table trong pipeline, không nhồi chung với ACL hay L2 forward. Đọc xong, Bài 14 sẽ chuyển sang DPDK — userspace datapath tăng tốc.