Firewall Migration trong thực tế: khi HA xanh vẫn chưa đủ để Cutover thành công

Từ External Firewall PA-3050 → PA-3410, GlobalProtect Pre-logon, UAT và rollback đến câu hỏi quan trọng hơn trạng thái thiết bị: sau migration, người dùng có thật sự làm việc bình thường không?

Có một khoảnh khắc khá dễ tạo cảm giác yên tâm trong một firewall migration: hai node mới đã hình thành HA, role và trạng thái HA đúng như thiết kế, interface UP, routing table nhìn ổn, policy commit thành công và traffic bắt đầu đi qua.

Nếu chỉ nhìn dashboard của firewall, mọi thứ có thể đã xanh.

Nhưng trong một lần migration External Firewall tại THP từ Palo Alto PA-3050 sang PA-3410, mình càng thấy rõ một điều: HA xanh mới chỉ chứng minh platform đang hoạt động. Nó chưa chứng minh hệ thống phía sau platform đó đang hoạt động đúng.

Đây cũng là một trong những case khiến mình thay đổi cách nhìn về cutover. Từ chỗ tập trung nhiều vào device status, mình bắt đầu dành nhiều sự chú ý hơn cho dependency và service validation.

External Firewall không đứng một mình

Nhìn trên diagram, thay một cặp firewall có vẻ là một bài toán khá rõ: old pair ra, new pair vào, giữ lại traffic path và migrate configuration.

Nhưng External Firewall chỉ là một lớp trong security path. Phía trong còn Internal Firewall Fortinet 200D và IPS; phía ngoài là Internet, remote access và các kết nối khác. Ở giữa là routing, NAT, VPN, certificate, security policy, logging và những application đang phụ thuộc vào tất cả các lớp đó.

Vì vậy mục tiêu của migration không phải tạo ra một PA-3410 có configuration giống PA-3050 nhất có thể. Mục tiêu là thay platform mà vẫn giữ được behavior của hệ thống: gateway, route, policy, NAT, VPN và những service người dùng đang sử dụng.

Thiết bị mới có thể đúng configuration nhưng hệ thống vẫn có thể sai behavior.

HA là điều kiện cần, không phải success criteria

HA rất quan trọng. Với một External Firewall, mình chắc chắn muốn kiểm tra HA state, synchronization, interface, path monitoring, failover behavior và khả năng quay lại trạng thái ổn định khi traffic ownership thay đổi.

Nhưng nếu checklist kết thúc ở đó thì mình mới kiểm tra được firewall như một thiết bị.

Trong production, firewall tồn tại để phục vụ traffic. Vì vậy sau HA còn phải đi tiếp qua routing, NAT, public application, IPSec VPN, SSL Decryption, logging/reporting và remote-access flow. Mỗi lớp đều có thể xanh riêng lẻ nhưng vẫn tạo ra một lỗi ở service cuối cùng.

Hai nhóm kiểm tra này bổ sung cho nhau. Không nên dùng nhóm thứ nhất để suy luận rằng nhóm thứ hai chắc chắn đã pass.

Active/Active không có nghĩa mọi service đều active trên cả hai node

Một chi tiết mình nhớ khá rõ ở giai đoạn đưa PA-3410 vào production là cặp firewall được triển khai theo Active/Active HA. Ở tầng platform, mô hình HA vẫn hoạt động như thiết kế. Nhưng khi kiểm tra kết nối IPsec VPN lên AWS, mình gặp một tình huống khác: VPN có thể lên nhưng traffic qua tunnel lại không truy cập application ổn định như mong đợi.

Cuối cùng, phần VPN network được giữ ownership trên một firewall duy nhất, thay vì cấu để cả hai node cùng tham gia xử lý tunnel. Sau thay đổi đó, traffic path của VPN trở nên rõ ràng và service phía sau hoạt động đúng trở lại.

Case này khiến mình chú ý nhiều hơn đến một lớp validation mà trạng thái HA không thể trả lời thay: session ownership, traffic symmetry và return path của những service stateful. Một cặp firewall có thể đang healthy ở tầng thiết bị, nhưng nếu một flow phụ thuộc state lại đi qua các node theo cách không nhất quán thì application vẫn có thể lỗi.

GlobalProtect Pre-logon: một flow nhỏ nhưng hậu quả không nhỏ

GlobalProtect Pre-logon là một ví dụ mình nhớ khá lâu trong project này.

Một số laptop công ty được thiết kế để khi ở ngoài văn phòng, VPN phải tự hình thành về Head Office trước khi user làm việc bình thường theo policy. Điều đó có nghĩa remote access không chỉ là chuyện user mở GlobalProtect rồi bấm Connect. Certificate, Agent Configuration và Pre-logon behavior đều trở thành một phần của service.

Trong quá trình validation thực tế, phần này cần được tinh chỉnh thêm ở Certificates và Agent Configuration. Đây là kiểu vấn đề rất dễ bị bỏ qua nếu UAT chỉ đứng từ phía firewall và kiểm tra tunnel, interface hay policy.

Điều làm mình chú ý hơn là thời điểm lỗi có thể xuất hiện. Maintenance window thường diễn ra khi phần lớn user không làm việc. Một laptop đang ở văn phòng có thể không tái hiện đúng điều kiện của một laptop đang ở ngoài Internet. Nếu Pre-logon không được đưa vào checklist, đến nhiều giờ sau mới có người phát hiện — có thể là một user đang công tác ở múi giờ khác.

Lúc đó maintenance window đã đóng, team migration có thể đã offline, nhưng với người dùng thì migration mới vừa “bắt đầu”.

UAT phải mô phỏng cách hệ thống được sử dụng

Từ những tình huống như vậy, mình không còn thích một UAT chỉ gồm các trạng thái kỹ thuật. UAT tốt cần đi theo những flow mà production thật sự sử dụng.

Với firewall migration, mình thường muốn checklist được chia theo service path: Internet outbound, published application, NAT, site-to-site VPN, remote access, DNS/NTP dependency nếu có, logging, SSL Decryption và những luồng đặc biệt mà business phụ thuộc. Với VPN stateful, checklist còn cần nhìn cả tunnel state, traffic symmetry, session ownership và khả năng truy cập application end-to-end.

Điểm quan trọng là UAT nên được định nghĩa trước maintenance window. Nếu viết success criteria sau khi traffic đã chuyển, rất dễ rơi vào tâm lý “những gì đang chạy chính là những gì cần chạy”.

Ngược lại, khi UAT đã có trước, mỗi test case trở thành một lời cam kết rõ ràng: trước migration service hoạt động như thế nào, sau migration nó phải tiếp tục hoạt động như vậy.

Configuration migration không nên che mất dependency

PA-3050 → PA-3410 không phải một project build-from-zero. Running configuration của platform cũ là một nguồn quan trọng để migrate policy và behavior sang platform mới. Nhưng import configuration không thể thay thế việc hiểu configuration đó đang phục vụ điều gì.

Interface mapping, license, certificate, security/NAT policy, routing/PBF, VPN, SSL Decryption, logging và Panorama-related configuration đều cần được nhìn trong context của traffic path. Compatibility và commit validation giúp biết configuration có hợp lệ với platform mới; service validation mới giúp biết behavior có còn đúng với production hay không.

Mình thấy đây là một khác biệt khá căn bản:

Configuration tells us what the firewall is configured to do. Validation tells us what the system actually does.

Rollback phải được chuẩn bị khi mọi thứ còn bình thường

Một firewall nằm ở perimeter không phải nơi mình muốn bắt đầu tranh luận rollback khi service đã mất.

Trước cutover, rollback cần đủ rõ để team biết trạng thái nào là giới hạn chấp nhận được, khi nào dừng troubleshooting trên platform mới, và làm thế nào đưa traffic về baseline cũ. Backup configuration chỉ là một phần. Còn có cable/interface state, routing behavior, HA role, dependency với các lớp security phía trong và cách xác nhận hệ thống cũ đã thực sự phục hồi.

Rollback trigger cũng quan trọng không kém rollback procedure. Nếu không có trigger, maintenance rất dễ kéo dài vì mỗi người đều nghĩ “thử thêm một thay đổi nữa”.

Với mình, rollback không phải phương án dành cho lúc team mất tự tin. Nó là một control giúp team biết mình có thể đi đến đâu mà vẫn giữ được đường quay lại.

Sau Go-live mới bắt đầu thấy những thứ maintenance window không thể hiện

Ngay cả khi UAT đã pass, mình vẫn không xem traffic cutover thành công là điểm kết thúc.

Sau go-live còn có một khoảng thời gian quan sát và tối ưu: log, session behavior, performance, những policy/object không còn dùng, naming, reporting, SSL Decryption và các chi tiết chỉ bộc lộ khi production quay lại nhịp bình thường.

Đây cũng là lúc platform mới không còn được đánh giá bằng câu hỏi “có giống hệ thống cũ không?”, mà bằng câu hỏi tốt hơn: nó có đang vận hành đúng, dễ quan sát hơn và đủ rõ để team tiếp tục quản trị trong những năm sau hay không?

Điều còn lại sau một firewall migration

Khi nhìn lại project này, PA-3050 và PA-3410 là hai cái tên dễ nhớ nhất. Nhưng bài học mình giữ lại không nằm ở model thiết bị.

Đó là việc một External Firewall chỉ là một mắt xích trong service path; HA xanh không đại diện cho trải nghiệm của user; một stateful flow như IPsec VPN cần ownership và traffic path rõ ràng; một flow nhỏ như Pre-logon có thể quan trọng hơn hàng chục health indicator; và UAT chỉ thật sự có giá trị khi nó kiểm tra cách hệ thống được sử dụng ngoài đời.

Một cutover đẹp không phải là lúc dashboard không có màu đỏ.

Nó là lúc mình có đủ bằng chứng để biết rằng sau khi thay một thành phần quan trọng, toàn bộ service path vẫn giữ được behavior mà business cần.

HA cho mình biết firewall còn đứng vững. Service validation mới cho mình biết hệ thống còn làm việc.