SECURITY VALIDATION

Kiểm thử firewall HA stateful: session sync, asymmetric traffic và failover

7/9/2026 · 17 phút

Minh họa: Cặp firewall HA đồng bộ session giữa hai đường mạng và vùng dịch vụ
Mục lục bài viết 10 phần

Một cặp firewall báo trạng thái “in sync” chưa chứng minh mọi session, NAT binding và security context đều sống sót qua failover. Nghiệm thu HA cần tạo lỗi có kiểm soát, quan sát cả hai chiều và xác nhận rằng continuity không đổi lấy policy bypass, duplicate hoặc state sai.

ĐỌC NHANH

Bài viết giúp bạn

  • Câu hỏi kỹ thuật cần trả lời
  • Topology và điều kiện đo
  • Biến số phải kiểm soát
Tùy chỉnh đọc
01

Câu hỏi kỹ thuật cần trả lời

#

NIST SP 800-41 Rev. 1 cung cấp hướng dẫn nền về firewall policy và kiến trúc, không phải đặc tả đồng bộ HA. RFC 7857 bàn về hành vi NAT44, không quy định session replication giữa hai firewall. Hành vi HA/session synchronization vẫn phụ thuộc implementation. Test plan phải bắt đầu bằng inventory những state thực sự được vendor/model/version đồng bộ: L3/L4 session, NAT, VPN, application identification, authentication, inspection proxy, TLS state hay chỉ một phần.

Ba câu hỏi cần trả lời là: fault nào kích hoạt failover; flow hiện hữu và flow mới phản ứng ra sao; và security policy có tiếp tục được thực thi đúng. “Không rớt phiên” không phải pass nếu traffic bị chuyển qua đường bypass hoặc node dự phòng thiếu policy/object mới nhất.

02

Topology và điều kiện đo

#

Topology tối thiểu gồm hai firewall HA, hai switch phía trust/untrust, link heartbeat/state sync độc lập, route peers và traffic generator hai phía. Thêm server thật hoặc emulator cho HTTP/TLS, DNS, UDP, TCP dài, VPN và ứng dụng cần inspection. Đặt capture point trước và sau mỗi firewall, cùng telemetry trên sync link.

Baseline cần lưu role, config checksum/revision, session table, NAT binding, route/FIB, policy hit, HA health và throughput/latency. Đồng bộ clock bằng nguồn độc lập; timestamp từ hai node lệch nhau sẽ làm sai thứ tự fault, switchover và packet recovery.

Minh họa: Topology kiểm thử firewall HA và đồng bộ session
Minh họa: Topology kiểm thử firewall HA và đồng bộ session
03

Biến số phải kiểm soát

#

Khóa mode active/standby hoặc active/active, session owner, sync transport, preemption, hold timer, link/path monitoring, routing adjacency, ECMP, NAT pool, policy revision và offload/acceleration. Ghi rõ state không được hỗ trợ đồng bộ; đừng suy từ TCP sang UDP, IPsec hoặc proxy session.

Traffic profile phải nêu concurrent sessions, connection rate, frame size, TLS version, application mix, session age và idle timeout. Tạo cả accepted và denied traffic, malformed packet an toàn, user identity và rule change đang chờ đồng bộ. Với active/active, kiểm hash/ownership và reordering riêng.

04

KPI và bằng chứng đầu ra

#

KPI availability gồm failure detection, role transition, packet loss, outage, throughput dip, latency/jitter, reset và new-session success. KPI correctness gồm tỷ lệ session/NAT binding khôi phục, duplicate, reordering, policy decision, log continuity, tunnel state và path symmetry. Theo dõi sync backlog, drop và CPU/memory để giải thích failure dưới tải.

Bộ bằng chứng tối thiểu: configuration diff/checksum, HA event, session/NAT snapshot trước–sau, routing update, policy/security log, PCAP hai phía và generator timeline. Với giao dịch, dùng request/transaction ID và server log để phát hiện commit trùng hoặc response mất.

05

Ma trận session và quyết định pass/fail

#

Pass/fail cần ghi rõ flow nào được phép reset. Không dùng “100% session synchronized” nếu công cụ chỉ đếm table entry mà chưa kiểm byte continuity, NAT tuple và security outcome.

  • Loại traffic: TCP dài · State cần kiểm: sequence/window/NAT · Kỳ vọng failover: tiếp tục hoặc reset theo thiết kế đã công bố · Dấu hiệu fail: silent blackhole
  • Loại traffic: TCP flow mới · State cần kiểm: policy, route, NAT pool · Kỳ vọng failover: tỷ lệ thành công trong SLO · Dấu hiệu fail: node mới không cấp binding
  • Loại traffic: UDP request/stream · State cần kiểm: pseudo-session/NAT timeout · Kỳ vọng failover: loss trong budget · Dấu hiệu fail: binding đổi ngoài dự kiến
  • Loại traffic: IPsec/VPN · State cần kiểm: SA, anti-replay, route · Kỳ vọng failover: hành vi theo capability đã xác minh · Dấu hiệu fail: replay drop kéo dài hoặc tunnel mồ côi
  • Loại traffic: Proxy/TLS inspection · State cần kiểm: proxy state/certificate · Kỳ vọng failover: không suy continuity nếu không sync · Dấu hiệu fail: bypass inspection
  • Loại traffic: Denied/malicious test · State cần kiểm: rule/object/log · Kỳ vọng failover: vẫn bị chặn và ghi log · Dấu hiệu fail: fail-open trái policy
06

Test plan failover và đồng bộ trạng thái

#

Chạy lần lượt mất data link, mất heartbeat, lỗi sync link, process restart, node reload, mất nguồn, route withdrawal upstream và health-monitor false negative. Mỗi lần chỉ gây một fault, sau đó thử fault kép: sync link suy giảm trước khi active node lỗi. Đo flow cũ và flow mới đồng thời.

  • Xác nhận config revision và object đồng nhất.
  • Tạo session mix đủ protocol, age và direction.
  • Lưu session/NAT baseline ở cả hai node.
  • Gây fault và đánh dấu timestamp độc lập.
  • Đối soát sequence, reset, duplicate và policy log.
  • Kiểm session tạo đúng trong cửa sổ transition.
  • Phục hồi node cũ, kiểm resync rồi mới failback.
  • Lặp lại khi session table và connection rate gần tải mục tiêu.
07

Asymmetric traffic, NAT và kiểm soát bảo mật

#

Tạo asymmetric path có kiểm soát bằng route policy hoặc ECMP để biết firewall drop, re-route hay đồng bộ owner theo thiết kế. Không coi việc “cho qua được” là tốt nếu implementation đòi symmetry để inspection đúng. Đo riêng return traffic và xác nhận upstream không vô tình gửi qua node khác.

Với NAT, kiểm tuple giữ nguyên cho session hiện hữu, pool exhaustion và port reuse. Với rule/object update, tạo thay đổi ngay trước failover để đo config propagation. Phát accepted, denied và test pattern an toàn nhằm chứng minh standby áp cùng policy; không thực hiện exploit ngoài lab được phép.

Minh họa: Timeline firewall HA từ mất node đến phục hồi session và policy
Minh họa: Timeline firewall HA từ mất node đến phục hồi session và policy
08

Scale, runbook và rollback

#

Tăng concurrent session, new connection rate, policy count, VPN tunnel và log rate theo bậc. Báo cáo p95/p99 restoration, không chỉ trung bình. Chạy soak test để phát hiện sync backlog, memory pressure hoặc divergence sau nhiều vòng failover/failback.

Runbook phải có OOB, điều kiện cô lập split-brain, cách đóng traffic khi security state không chắc chắn, backup config, canary và ngưỡng rollback. Chỉ failback khi node cũ đã đồng bộ config, route, object và session theo tiêu chí được định nghĩa; preempt tự động cần thử riêng.

09

Giới hạn kết luận

#

Kết quả chỉ đúng cho model, phiên bản, license, mode HA, topology, route policy, session type và load đã thử. Firmware upgrade, inspection engine, offload hoặc thay đổi TLS policy có thể làm state-sync behavior khác đi.

HA firewall không thay thế HA của switch, router, identity, certificate, DNS hoặc ứng dụng. Nếu không có capture hai phía và server evidence, chỉ có thể kết luận control plane chuyển vai trò, không thể kết luận dịch vụ hoặc bảo mật end-to-end.

10

Khái niệm cần nhớ

#
  • Stateful HA: cụm dự phòng có đồng bộ một phần trạng thái phiên.
  • Session owner: node chịu trách nhiệm xử lý trạng thái của flow.
  • NAT binding: ánh xạ tuple địa chỉ/cổng trước và sau NAT.
  • Split-brain: nhiều node cùng tin mình đang active trái thiết kế.
  • Asymmetric traffic: chiều đi và về qua đường hoặc node khác nhau.
  • Fail-open/fail-close: cho qua hoặc chặn khi inspection không thể hoàn tất.
  • State-sync backlog: trạng thái chờ truyền hoặc áp dụng ở peer.
THUẬT NGỮ NHANH

Khái niệm cần nhớ

Security efficacy
Mức độ phát hiện hoặc ngăn chặn đúng nội dung kiểm thử trong phạm vi đã xác định.
Goodput
Lưu lượng ứng dụng hữu ích tới đích, không tính phần truyền lại hoặc overhead không tạo giá trị.
False positive
Lưu lượng hợp lệ bị nhận diện hoặc xử lý nhầm như một mối đe dọa.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn

Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.

Nguyên tắc biên tập

NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.

Thông số và khả năng sản phẩm có thể thay đổi theo phiên bản. Hãy đối chiếu tài liệu chính thức trước khi xây dựng cấu hình hoặc tiêu chí nghiệm thu.
BẮT ĐẦU TỪ BÀI TOÁN

Cần chuyển kiến thức thành test plan?

Chia sẻ mục tiêu, topology và ràng buộc kỹ thuật. NetVali sẽ cùng bạn xác định bài đo phù hợp.

Trao đổi yêu cầu kỹ thuật