Khái niệm VPN & IPSec Phase 1/Phase 2 trên FortiGate

1. Liên hệ thực tế

Sau khi hoàn tất nhóm bài Security Policy, khách hàng của anh Nam mở thêm một chi nhánh mới, yêu cầu kết nối an toàn với trụ sở chính để đồng bộ dữ liệu nội bộ mà không đi qua Internet công khai ở dạng rõ (plaintext). Anh Nam biết đây là lúc cần dùng VPN, nhưng khi mở màn hình cấu hình IPsec trên FortiGate, anh thấy hai mục tách biệt: Phase 1 và Phase 2 — mỗi mục lại có riêng phần chọn thuật toán mã hóa, thời gian sống (lifetime), và các tham số khác.

Anh Nam hỏi chị Lan: "Sao không gộp một lần cấu hình cho gọn, mà phải chia làm hai Phase riêng biệt vậy?"

Chị Lan giải thích: "Đây chính là cách IPsec hoạt động theo chuẩn IKE — Phase 1 xây dựng một 'đường ống quản lý' an toàn trước, rồi mới dùng chính đường ống đó để thương lượng Phase 2 — nơi thực sự tạo ra kênh mã hóa cho dữ liệu công ty đi qua. Tách hai lớp như vậy giúp tăng bảo mật và linh hoạt hơn nhiều so với gộp chung một bước."

Bài này mở đầu nhóm VPN — giải thích khái niệm IPsec VPN và hai giai đoạn thương lượng cốt lõi: Phase 1 (IKE SA)và Phase 2 (IPsec SA).

2. Kiến thức cốt lõi

2.1 VPN và IPsec là gì

VPN (Virtual Private Network) tạo ra một kênh liên lạc riêng tư, an toàn giữa hai điểm qua một mạng công khai không tin cậy (thường là Internet) — dữ liệu đi qua kênh này được mã hóa, tránh bị nghe lén hoặc giả mạo trên đường truyền.

IPsec (Internet Protocol Security) là bộ giao thức tiêu chuẩn phổ biến nhất để triển khai VPN ở tầng mạng (Layer 3), dùng IKE (Internet Key Exchange) để hai bên tự động thương lượng và trao đổi khóa mã hóa mà không cần cấu hình khóa thủ công cố định.

2.2 Hai giai đoạn thương lượng: Phase 1 và Phase 2

Phase 1 thiết lập IKE SA (Security Association) — hai bên xác thực lẫn nhau và thống nhất một bộ tham số bảo mật để xây dựng kênh quản lý an toàn. Kênh này chưa dùng để truyền dữ liệu thực tế, mà dùng để tiếp tục thương lượng Phase 2 một cách an toàn.

config vpn ipsec phase1-interface
    edit "vpn-chi-nhanh-a"
        set interface "wan1"
        set ike-version 2
        set remote-gw 203.0.113.10
        set authmethod psk
        set psksecret "MatKhauManhCanKy"
        set proposal aes256gcm-prfsha384
        set dhgrp 21
        set dpd on-demand
    next
end

Phase 2 thiết lập IPsec SA — diễn ra bên trong kênh Phase 1 đã được bảo vệ, thương lượng bộ tham số riêng để tạo ra SA thực sự dùng cho việc mã hóa dữ liệu đi qua tunnel.

config vpn ipsec phase2-interface
    edit "vpn-chi-nhanh-a-p2"
        set phase1name "vpn-chi-nhanh-a"
        set proposal aes256gcm
        set pfs enable
        set dhgrp 21
        set keylifeseconds 43200
    next
end

⚠️ Lưu ý: Toàn bộ tham số trong Phase 1 (encryption, hash, DH group, phương thức xác thực) và Phase 2 (proposal, PFS, DH group) phải khớp chính xác giữa hai đầu tunnel — chỉ cần một tham số lệch nhau (ví dụ DH group khác nhau), quá trình thương lượng sẽ thất bại ngay từ bước so khớp đề xuất (proposal mismatch), tunnel không bao giờ lên được.

2.3 PFS (Perfect Forward Secrecy) — vì sao Phase 2 cần thêm một lớp bảo vệ

Theo mặc định, khóa dùng trong Phase 2 được tính toán dựa trên khóa đã có từ Phase 1 — điều này có nghĩa nếu khóa Phase 1 chẳng may bị lộ (dù xác suất rất thấp), toàn bộ dữ liệu đã trao đổi trong quá khứ có nguy cơ bị giải mã ngược.

PFS (Perfect Forward Secrecy) giải quyết rủi ro này bằng cách bắt buộc thực hiện thêm một lần trao đổi Diffie-Hellman độc lập ngay trong Phase 2, tạo khóa mới không phụ thuộc vào khóa Phase 1 — dù khóa cũ có bị lộ, các phiên trao đổi trước đó (đã dùng khóa PFS riêng) vẫn an toàn.

config vpn ipsec phase2-interface
    edit "vpn-chi-nhanh-a-p2"
        ...
        set pfs enable
        set dhgrp 21
    next
end

⚠️ Lưu ý: PFS chỉ thực sự phát huy tác dụng rõ rệt khi tunnel có rekey (tự động thương lượng lại khóa mới định kỳ, theo keylifeseconds) — nếu tắt PFS, các lần rekey vẫn dùng chung gốc khóa từ Phase 1 ban đầu; bật PFS thì mỗi lần rekey đều có một khóa Diffie-Hellman hoàn toàn mới, độc lập.

2.4 DH Group — nền tảng của việc trao đổi khóa an toàn

DH Group (Diffie-Hellman Group) xác định độ mạnh của thuật toán trao đổi khóa dùng trong cả Phase 1 lẫn Phase 2 (khi bật PFS) — số group càng cao thường tương ứng độ dài khóa/độ phức tạp toán học càng lớn, an toàn hơn nhưng cũng tốn nhiều tài nguyên tính toán hơn.

config vpn ipsec phase1-interface
    edit "vpn-chi-nhanh-a"
        ...
        set dhgrp 21
    next
end

⚠️ Lưu ý: DH Group của Phase 1 và DH Group dùng cho PFS ở Phase 2 là hai giá trị tách biệt, dù có thể trùng số nếu người quản trị chọn giống nhau. Khi PFS bật, DH Group ở Phase 2 cũng bắt buộc phải khớp giữa hai đầu tunnel, y hệt nguyên tắc đã nêu ở mục 2.2 cho toàn bộ tham số proposal.

2.5 Xác thực Phase 1 — Pre-shared Key vs Certificate

Phase 1 cần một phương thức để hai bên xác thực danh tính lẫn nhau trước khi tin tưởng tiếp tục:

• authmethod psk (Pre-shared Key) — cả hai bên cùng biết trước một chuỗi bí mật chung, đơn giản triển khai, phù hợp cho hầu hết kết nối site-to-site quy mô vừa và nhỏ.
• authmethod signature (Certificate-based) — dùng chứng chỉ số (đã học ở bài Certificate) để xác thực, phù hợp môi trường có PKI sẵn có hoặc yêu cầu bảo mật nghiêm ngặt hơn, tránh rủi ro lộ pre-shared key dùng chung.

⚠️ Lưu ý: Với authmethod psk, pre-shared key cần đủ độ dài và phức tạp (khuyến nghị Fortinet: tối thiểu 16 ký tự, kết hợp chữ hoa/thường/số/ký tự đặc biệt) — đây là bí mật chia sẻ duy nhất bảo vệ toàn bộ quá trình xác thực Phase 1, đặt yếu sẽ là điểm yếu bảo mật dễ bị khai thác nhất của toàn bộ tunnel.

2.6 Bảng tổng hợp Phase 1 vs Phase 2

3. Hỏi & Đáp

Vì sao không gộp Phase 1 và Phase 2 làm một bước duy nhất cho đơn giản?

Tách hai lớp mang lại lợi ích bảo mật và vận hành: Phase 1 (ít tốn tài nguyên hơn, xác thực một lần) tạo nền tảng tin cậy; Phase 2 có thể rekey độc lập nhiều lần (thường xuyên hơn Phase 1) mà không cần xác thực lại toàn bộ từ đầu — giúp cân bằng giữa bảo mật (đổi khóa thường xuyên) và hiệu năng (không phải xác thực lại liên tục).

IKEv1 và IKEv2 khác nhau thế nào trong ngữ cảnh Phase 1/Phase 2?

IKEv2 đơn giản hóa đáng kể số lượng gói tin trao đổi trong Phase 1 so với IKEv1 (chỉ 2 gói thay vì 4-6 gói tùy chế độ Main/Aggressive của IKEv1), đồng thời Phase 2 trong IKEv2 gọi là thương lượng "Child SA" thay vì Quick Mode như IKEv1 — về bản chất khái niệm tương tự nhưng cách trao đổi gói tin hiệu quả hơn. FortiGate hỗ trợ cả hai, khuyến nghị dùng IKEv2 cho các triển khai mới.

Nếu DH Group giữa hai đầu tunnel không khớp thì có log gì để nhận biết?

Có — dùng lệnh chẩn đoán diagnose vpn ike log hoặc bật debug (diagnose debug application ike -1) sẽ thấy thông báo dạng "no SA proposal chosen" hoặc "negotiation failure" — đây là dấu hiệu kinh điển của việc lệch tham số proposal (bao gồm cả DH group) giữa hai bên. Nội dung chi tiết về troubleshooting VPN sẽ được trình bày ở bài riêng trong nhóm này.

Có bắt buộc phải bật PFS cho mọi tunnel không?

Không bắt buộc, nhưng được khuyến nghị cho hầu hết triển khai hiện đại vì chi phí hiệu năng bổ sung không đáng kể so với lợi ích bảo mật mang lại (bảo vệ dữ liệu quá khứ nếu khóa Phase 1 chẳng may bị lộ). Một số thiết bị VPN cũ hoặc cấu hình tương thích ngược đặc biệt có thể không hỗ trợ PFS, cần kiểm tra khả năng tương thích của thiết bị đầu kia trước khi bật.

4. Quiz

Câu 1: IKE SA là kết quả của giai đoạn thương lượng nào trong IPsec VPN?

• A. Phase 2
• B. Phase 1
• C. Cả hai Phase cùng lúc
• D. Không liên quan tới khái niệm SA

Câu 2: Vì sao Phase 2 cần diễn ra bên trong kênh đã thiết lập từ Phase 1?

• A. Vì Phase 2 không cần bảo mật
• B. Vì Phase 1 tạo ra kênh quản lý an toàn để Phase 2 có thể thương lượng các tham số một cách được bảo vệ
• C. Vì FortiGate yêu cầu bắt buộc theo thứ tự ngẫu nhiên
• D. Không có mối liên hệ nào giữa hai Phase

Câu 3: PFS (Perfect Forward Secrecy) giải quyết rủi ro bảo mật nào?

• A. Rủi ro mất kết nối Internet
• B. Rủi ro dữ liệu quá khứ bị giải mã ngược nếu khóa Phase 1 chẳng may bị lộ
• C. Rủi ro tràn bộ nhớ trên FortiGate
• D. Rủi ro trùng địa chỉ IP giữa hai site

Câu 4: Điều gì xảy ra nếu DH Group giữa hai đầu tunnel không khớp nhau?

• A. Tunnel vẫn lên bình thường, chỉ chậm hơn
• B. Quá trình thương lượng thất bại ngay từ bước so khớp proposal, tunnel không lên được
• C. FortiGate tự động chọn DH Group thấp hơn để tương thích
• D. Chỉ ảnh hưởng tới Phase 2, không ảnh hưởng Phase 1

Câu 5: authmethod psk trong cấu hình Phase 1 nghĩa là gì?

• A. Xác thực bằng chứng chỉ số
• B. Xác thực bằng một chuỗi bí mật (pre-shared key) mà cả hai bên cùng biết trước
• C. Không cần xác thực gì cả
• D. Chỉ dùng được cho SSL-VPN

👉 Đáp án

Câu 1: B IKE SA là kết quả của Phase 1 — giai đoạn hai bên xác thực lẫn nhau và tạo kênh quản lý an toàn.

Câu 2: B Phase 1 tạo ra một kênh đã được xác thực và bảo vệ, cho phép Phase 2 thương lượng các tham số nhạy cảm (như khóa mã hóa dữ liệu) mà không bị lộ ra ngoài trong quá trình trao đổi.

Câu 3: B PFS bảo vệ dữ liệu quá khứ khỏi nguy cơ bị giải mã ngược nếu khóa Phase 1 chẳng may bị lộ, bằng cách tạo khóa Phase 2 độc lập qua một lần trao đổi Diffie-Hellman riêng.

Câu 4: B Khi DH Group (hoặc bất kỳ tham số proposal nào khác) không khớp giữa hai đầu, quá trình thương lượng thất bại ngay từ bước so khớp đề xuất, tunnel không bao giờ được thiết lập.

Câu 5: B authmethod psk nghĩa là xác thực bằng Pre-shared Key — một chuỗi bí mật chung mà cả hai bên đã biết trước, dùng để xác thực lẫn nhau trong Phase 1.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng