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 thấy rất rõ một chuyện: HA xanh mới chỉ cho biết cặp firewall đang hoạt động. Nó chưa cho biết những service đi xuyên qua cặp firewall đó có đang chạy đúng hay không.

Từ project này, mình bắt đầu bớt nhìn cutover bằng device status và để ý nhiều hơn tới dependency, traffic path 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 những thứ production đang cần: gateway, route, policy, NAT, VPN và các 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ể chạy sai.

HA là điều kiện cần, không phải điểm kết thúc của UAT

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 service cuối cùng vẫn có thể lỗi.

Hai nhóm kiểm tra này bổ sung cho nhau. Không nên thấy nhóm thứ nhất pass rồi mặc định nhóm thứ hai cũng đã ổn.

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 làm mình để ý nhiều hơn tới session ownership, traffic symmetry và return path của những service stateful. Một cặp firewall có thể healthy ở tầng thiết bị, nhưng nếu một flow phụ thuộc state lại đi qua các node 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”.

Khi test case đã có từ trước, team biết rõ service nào phải được xác nhận trước khi đóng change.

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 production còn chạy đúng hay không.

Mình giữ lại một cách phân biệt khá đơn giản:

Configuration cho biết firewall được cấu hình để làm gì. Validation cho biết traffic thực tế có chạy đúng như mình nghĩ hay không.

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 đơn giản là đường quay lại đã được chuẩn bị trước, để khi cần dừng thì team không phải nghĩ từ đầu trong lúc đang chịu áp lực.

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 mình nhìn platform mới bằng những câu hỏi thực tế hơn: log có đủ để troubleshoot không, traffic có ổn định theo baseline mới không, còn object/policy nào cần dọn, và team sau này có dễ support hơn 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 traffic 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à return 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ỉ 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 team đã kiểm tra đủ để biết rằng sau khi thay firewall, những service cần thiết vẫn làm việc bình thường.

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.