IPsec trên Junos
Mục lục
- 1. IPsec là gì và giải quyết vấn đề gì?
- 2. Security Association (SA) và SPI
- 3. SPD và SAD — kiến trúc quyết định Protect / Discard / Bypass
- 4. AH vs ESP — cấu trúc header
- 5. Tunnel Mode vs Transport Mode
- 6. IKE — Phase 1 và Phase 2
- 7. Cấu hình IPsec VPN trên Junos (AutoKey IKE)
- 8. Kiểm tra IPsec hoạt động
- 9. NAT Traversal (NAT-T) và MTU/Fragmentation
- 10. Hạn chế và thách thức thực tế
1. IPsec là gì và giải quyết vấn đề gì?
GRE Tunnel (đã nói ở tài liệu trước) giải quyết bài toán "tạo một liên kết ảo point-to-point qua mạng công cộng" — nhưng bản thân GRE không hề mã hóa gì cả. Ai chặn được traffic giữa đường vẫn đọc được nguyên văn nội dung bên trong. IPsec (Internet Protocol Security) ra đời để giải đúng phần còn thiếu đó: một bộ giao thức hoạt động ở Layer 3, đảm bảo dữ liệu đi qua mạng công cộng vừa được mã hóa (không ai đọc được nếu chặn giữa đường) vừa được xác thực (biết chắc gói tin đến từ đúng người gửi hợp lệ, không bị sửa đổi dọc đường).
💡 Hình dung như thế này: GRE giống như gửi một lá thư trong phong bì thường — ai mở ra giữa đường cũng đọc được. IPsec giống gửi lá thư đó trong một phong bì niêm phong bằng sáp có con dấu riêng: nếu phong bì bị bóc hoặc sáp bị vỡ dọc đường, người nhận biết ngay có ai đó đã can thiệp; và nếu không biết "công thức" mở niêm phong, không ai đọc được nội dung bên trong dù có cầm được phong bì trong tay.
Ba nhiệm vụ cốt lõi IPsec đảm nhiệm:
- Mã hóa (Confidentiality) — nội dung gói tin bị biến đổi sao cho chỉ bên nhận hợp lệ mới giải mã được.
- Xác thực nguồn gốc & toàn vẹn dữ liệu (Authentication & Integrity) — đảm bảo gói tin đến từ đúng người gửi đã thỏa thuận trước, và không bị chỉnh sửa dọc đường.
- Chống replay attack — mỗi gói mang một số thứ tự, giúp bên nhận phát hiện và loại bỏ gói bị ghi lại rồi gửi lại (replay) bởi kẻ tấn công.
So với GRE Tunnel, khác biệt cốt lõi nằm ở đúng một chữ: GRE chỉ đóng gói (encapsulate) để tạo đường đi ảo, còn IPsec đóng gói và biến đổi nội dung bằng mật mã học. Trong thực tế, hai công nghệ này thường được kết hợp — GRE tạo tunnel để mang được các giao thức routing (OSPF, BGP...), rồi bọc thêm một lớp IPsec bên ngoài để mã hóa toàn bộ traffic đó, tận dụng điểm mạnh của cả hai (GRE over IPsec).
2. Security Association (SA) và SPI
Trước khi hai bên trao đổi được bất kỳ gói tin mã hóa nào, họ phải thống nhất trước: dùng thuật toán mã hóa nào, khóa gì, sống bao lâu. Toàn bộ thỏa thuận đó được gói gọn trong một khái niệm gọi là Security Association (SA).
💡 Hình dung như thế này: SA giống một hợp đồng vận chuyển hàng hóa riêng cho một chiều đường cụ thể — hợp đồng chiều đi (A→B) hoàn toàn tách biệt với hợp đồng chiều về (B→A), dù cùng một tuyến đường vật lý. Mỗi hợp đồng có một mã số hồ sơ riêng để tra cứu nhanh — đó chính là SPI.
Điểm quan trọng nhất cần nhớ: SA là một thỏa thuận một chiều (unidirectional). Giao tiếp hai chiều bình thường giữa hai gateway luôn cần tối thiểu 2 SA — một SA bảo vệ chiều A→B, một SA khác bảo vệ chiều B→A, dù chúng chạy trên cùng một tunnel vật lý.
SPI (Security Parameter Index) là một con số nằm ngay trong header AH/ESP (sẽ thấy ở Mục 4), giúp bên nhận — khi nhận một gói tin đến — tra cứu ngay lập tức SA nào đang áp dụng cho gói này mà không cần đoán: đọc SPI, tra bảng, biết chính xác dùng thuật toán gì và khóa nào để giải mã/xác thực. Một SA đầy đủ luôn định nghĩa: giao thức bảo mật (AH hay ESP), mode (tunnel hay transport — Mục 5), thuật toán mã hóa/xác thực và khóa tương ứng, và thời gian sống (lifetime) trước khi phải đàm phán lại. Bảng tra cứu chứa toàn bộ các SA đang hoạt động có tên riêng — chi tiết ngay ở Mục 3.
3. SPD và SAD — kiến trúc quyết định Protect / Discard / Bypass
SA ở Mục 2 chỉ là "một thỏa thuận đã có sẵn" — nhưng làm sao gateway biết gói tin nào cần áp SA, gói nào cứ để đi bình thường, và gói nào phải hủy thẳng? Đây là việc của hai cơ sở dữ liệu nội bộ mà RFC 4301 định nghĩa: SPD (Security Policy Database) và SAD (Security Association Database).
💡 Hình dung như thế này: SPD giống một nhân viên bảo vệ đứng ở cổng, cầm danh sách quy định: "thư từ đi tới địa chỉ X phải niêm phong, thư tới địa chỉ Y cứ gửi bình thường, thư tới địa chỉ Z thì hủy luôn". SAD giống tủ hồ sơ lưu toàn bộ hợp đồng vận chuyển (SA) đang có hiệu lực, đánh số theo đúng SPI để tra cứu tức thì — nhân viên bảo vệ (SPD) chỉ quyết định "có niêm phong hay không", còn tủ hồ sơ (SAD) mới biết "niêm phong bằng công thức nào".
Quy trình xử lý một gói tin outbound (đi ra khỏi gateway), theo đúng RFC 4301:
- Tra SPD trước tiên — mọi gói tin đi qua ranh giới IPsec (kể cả traffic quản lý) đều bắt buộc phải qua bước này. SPD so khớp gói tin theo các Selector (địa chỉ IP nguồn/đích, port, giao thức Layer 4...) với danh sách policy đã cấu hình.
- Ba khả năng xảy ra: DISCARD (hủy gói — dùng cho traffic biết chắc không được phép), BYPASS (cho đi bình thường, không áp IPsec — ví dụ traffic nội bộ tin cậy), hoặc PROTECT (bắt buộc phải bảo vệ bằng IPsec).
- Nếu là PROTECT, tra tiếp SAD — tìm SA phù hợp đã tồn tại; nếu chưa có, kích hoạt IKE (Mục 6) để đàm phán tạo SA mới, rồi mới áp AH/ESP (Mục 4) lên gói tin.
Chiều inbound (gói tin đến) đơn giản hơn: vì gói đã mang sẵn SPI ngay trong header AH/ESP, gateway tra thẳng SAD theo bộ (địa chỉ đích, giao thức IPsec, SPI) mà không cần match lại Selector từ đầu — đây chính xác là cơ chế đã thấy ở Mục 2, chỉ khác là giờ nhìn từ góc độ "cái gì tra cứu cái gì" trong kiến trúc tổng thể.
Một điểm hay bị bỏ sót: nếu không có policy nào trong SPD khớp với gói tin (dù inbound hay outbound), gói đó bị DISCARD theo mặc định — đây là hành vi "fail closed" (an toàn hơn là mở), không phải lỗi cấu hình. Khi một gói tin biến mất không rõ lý do dù VPN "trông có vẻ" đã lên, kiểm tra lại đúng chỗ SPD/Selector (proxy-id/traffic-selector đã nhắc ở Mục 8) trước khi nghi ngờ tới thuật toán mã hóa.
4. AH vs ESP — cấu trúc header
IPsec có hai giao thức bảo mật con, khác nhau ở đúng một điểm: có mã hóa hay không.
💡 Hình dung như thế này: AH giống một sợi dây niêm phong quấn quanh cả thùng hàng — ai cũng nhìn thấy được hàng bên trong (không che giấu nội dung), nhưng nếu dây niêm phong bị đứt hoặc thùng bị mở ra chỉnh sửa, người nhận phát hiện ngay. ESP giống việc bỏ hàng vào một chiếc hộp khóa kín rồi mới niêm phong: vừa không ai nhìn thấy nội dung bên trong (mã hóa), vừa biết được nếu có ai cố mở hộp giữa đường (xác thực).
- AH (Authentication Header) — chỉ xác thực nguồn gốc và tính toàn vẹn của toàn bộ gói IP (kể cả IP header), dùng thuật toán hash như MD5 hoặc SHA. Không mã hóa — ai chặn được vẫn đọc nguyên văn nội dung.
- ESP (Encapsulating Security Payload) — vừa mã hóa payload, vừa có thể xác thực. Đây là giao thức được dùng phổ biến hơn hẳn trong thực tế, vì AH thiếu hẳn phần mã hóa nên ít có giá trị thực dụng khi mục tiêu chính là bảo mật dữ liệu.
Nhìn kỹ sơ đồ ESP: vùng được mã hóa (viền đỏ) chỉ gồm Data và ESP Trailer — không bao gồm ESP Header (vì bên nhận cần đọc được SPI ngay để biết dùng SA nào) và không bao gồm trường Auth cuối cùng (dùng để lưu chính giá trị xác thực, không thể tự xác thực chính nó). Vùng được xác thực (viền xanh, gọi là ICV — Integrity Check Value) rộng hơn, phủ từ ESP Header tới hết ESP Trailer — nhưng không phủ IP Header gốc, khác hẳn AH vốn xác thực luôn cả IP header. Đây là lý do khi cần cả mã hóa lẫn xác thực toàn bộ gói tin (kể cả IP header), một số triển khai cũ kết hợp AH+ESP cùng lúc — dù trong thực tế ngày nay, ESP với thuật toán AEAD (như AES-GCM, tự tích hợp cả mã hóa lẫn xác thực trong một bước) gần như đã thay thế hoàn toàn nhu cầu dùng AH riêng.
Nên chọn thuật toán nào?
Với ESP, có hai cách kết hợp mã hóa và xác thực: dùng hai thuật toán riêng biệt (ví dụ AES-CBC để mã hóa + HMAC-SHA256 để xác thực), hoặc dùng một thuật toán AEAD (Authenticated Encryption with Associated Data — tự làm cả hai việc trong một bước tính toán duy nhất, như AES-GCM). AEAD vừa nhanh hơn (ít round tính toán hơn) vừa khó cấu hình sai hơn (không thể quên bật auth vì nó luôn đi kèm), nên đây là lựa chọn mặc định được khuyến nghị hiện nay — đúng như cấu hình encryption-algorithm aes-256-gcm đã dùng ở Mục 7.
Ngược lại, một số thuật toán từng phổ biến giờ đã bị coi là yếu, không nên dùng cho triển khai mới: DES (khóa chỉ 56-bit, bẻ được bằng brute-force trong thời gian ngắn), 3DES (168-bit nhưng chậm và dần bị loại bỏ khỏi khuyến nghị hiện hành), MD5 và SHA-1 (đã có kỹ thuật tấn công tìm collision, khuyến nghị hiện tại chuyển hẳn sang họ SHA-256/SHA-384 trở lên).
5. Tunnel Mode vs Transport Mode
AH/ESP ở Mục 4 có thể áp dụng theo hai cách khác nhau, tùy vào việc IP header gốc có bị bọc lại hay không.
💡 Hình dung như thế này: Transport Mode giống việc niêm phong nội dung một lá thư nhưng vẫn dùng nguyên phong bì cũ, địa chỉ người nhận vẫn in sẵn bên ngoài, ai cũng đọc được. Tunnel Mode giống việc bỏ cả lá thư lẫn phong bì cũ đó vào một thùng carton mới, dán nhãn địa chỉ hoàn toàn mới bên ngoài — địa chỉ thật của người nhận cuối cùng giờ nằm ẩn bên trong thùng, chỉ ai mở được thùng (đúng khóa) mới thấy.
- Transport Mode — chỉ bảo vệ payload (từ sau IP header trở đi), IP header gốc giữ nguyên, không mã hóa. Router giữa đường vẫn đọc được địa chỉ IP thật để định tuyến bình thường. Phù hợp khi bảo vệ giao tiếp trực tiếp giữa hai host trên cùng một mạng đáng tin cậy.
- Tunnel Mode — bọc toàn bộ gói IP gốc (cả header lẫn payload) vào bên trong, mã hóa hết, rồi thêm một IP header hoàn toàn mới ở ngoài cùng để định tuyến qua mạng công cộng. Đây là mode dùng cho VPN giữa hai mạng riêng (site-to-site), đúng kịch bản đã thấy ở Mục 1.
Một điểm rất đáng chú ý khi triển khai trên Junos: Junos OS luôn dùng Tunnel Mode, không có tùy chọn Transport Mode — dù bạn đang bảo vệ traffic giữa hai site hay traffic host-to-host, Junos đều bọc thêm một IP header mới.
6. IKE — Phase 1 và Phase 2
SA ở Mục 2 không tự nhiên xuất hiện — phải có một quá trình đàm phán để hai bên thống nhất được các tham số đó một cách an toàn, ngay cả khi họ chưa từng trao đổi gì với nhau trước đó. Đây là việc của IKE (Internet Key Exchange), chạy qua UDP port 500.
💡 Hình dung như thế này: IKE giống một cuộc đàm phán ký hợp đồng gồm hai bước tách biệt. Bước 1: hai bên gặp mặt, xác minh đúng danh tính của nhau, rồi thống nhất một "ngôn ngữ mật" riêng chỉ hai bên hiểu được — từ giờ mọi trao đổi tiếp theo đều dùng ngôn ngữ mật đó, không ai nghe lén được nữa. Bước 2: dùng đúng ngôn ngữ mật vừa thống nhất để đàm phán chi tiết hợp đồng thật (SA) — điều khoản cụ thể, hiệu lực bao lâu.
Phase 1 thiết lập một kênh an toàn gọi là IKE SA (còn gọi là ISAKMP SA): hai bên xác thực lẫn nhau (bằng Preshared Key hoặc certificate) và dùng thuật toán Diffie-Hellman để cả hai cùng tính ra một khóa bí mật chung — mà không cần gửi chính khóa đó đi qua mạng (ai chặn được toàn bộ traffic trao đổi vẫn không tính ngược lại được khóa). Phase 2 dùng chính kênh an toàn vừa tạo ở Phase 1 để đàm phán tiếp — lần này là các IPsec SA thật sự (SA đã nói ở Mục 2), tức thống nhất dùng AH hay ESP, mode nào, thuật toán gì cho traffic dữ liệu thật.
PFS (Perfect Forward Secrecy) — vì sao Phase 2 có thể tự làm lại Diffie-Hellman?
Mặc định, Phase 2 có thể "mượn" luôn khóa bí mật đã tính được từ Diffie-Hellman ở Phase 1 để tạo khóa cho IPsec SA — nhanh hơn, nhưng kéo theo một rủi ro: nếu khóa Phase 1 sau này bị lộ (dù nhiều năm sau), toàn bộ traffic đã ghi lại trước đó có thể bị giải mã ngược. PFS (Perfect Forward Secrecy), khi được bật, buộc Phase 2 phải chạy một lượt Diffie-Hellman hoàn toàn mới, độc lập với Phase 1 mỗi khi tạo hoặc rekey một IPsec SA.
💡 Hình dung như thế này: không có PFS giống việc dùng chung một chìa khóa gốc để làm ra mọi chìa khóa phòng trong khách sạn — lộ chìa gốc là mở được toàn bộ các phòng, kể cả phòng đã đóng từ lâu. Có PFS giống mỗi phòng có một chìa hoàn toàn độc lập, không liên quan gì tới chìa gốc — lộ một chìa chỉ ảnh hưởng đúng một phòng, không lan sang phòng khác.
Lợi ích cụ thể: nếu một IPsec SA bị compromise (lộ khóa), các SA khác — kể cả SA tạo ra sau đó từ cùng một Phase 1 — vẫn an toàn, vì mỗi SA có vật liệu khóa (key material) độc lập hoàn toàn. Cái giá phải trả là thêm một lượt tính toán Diffie-Hellman mỗi lần rekey, nhưng với phần cứng hiện đại, chi phí này gần như không đáng kể so với lợi ích bảo mật mang lại — vì vậy PFS gần như luôn nên bật trong triển khai thực tế.
Diffie-Hellman Group — chọn nhóm nào?
Độ mạnh của bước trao đổi khóa Diffie-Hellman (cả ở Phase 1 lẫn khi bật PFS ở Phase 2) phụ thuộc vào DH Group được chọn — con số càng lớn, kích thước khóa càng lớn, càng khó bị bẻ bằng brute-force, nhưng cũng tốn nhiều tài nguyên tính toán hơn.
| DH Group | Kích thước | Khuyến nghị |
|---|---|---|
| 1, 2, 5 | 768-bit, 1024-bit, 1536-bit | Không nên dùng — đã yếu |
| 14, 15, 16 | 2048-bit, 3072-bit, 4096-bit | Khuyến nghị cho triển khai mới |
| 19, 20, 21 | 256-bit, 384-bit, 521-bit (Elliptic Curve) | Khuyến nghị — ECC cho hiệu năng tốt hơn ở cùng mức an toàn |
Nhóm 19/20/21 dùng Elliptic Curve Cryptography (ECC) thay vì phép tính modular truyền thống — đạt cùng mức độ an toàn với kích thước khóa nhỏ hơn nhiều lần, nên thường được ưu tiên trên thiết bị cần cân bằng giữa bảo mật và hiệu năng.
IKEv1 vs IKEv2: IKEv2 là bản nâng cấp gọn hơn hẳn — chỉ cần 4 message (2 exchange) để hoàn tất thay vì tới 6-9 message của IKEv1, có hỗ trợ NAT-T tích hợp sẵn (không cần cấu hình thêm, khác IKEv1 cần bật thủ công — xem Mục 9), có thêm MOBIKE (cho phép một đầu tunnel đổi địa chỉ IP giữa chừng, ví dụ thiết bị di động chuyển từ Wi-Fi sang 4G, mà không làm rớt SA), và chống chịu tốt hơn trước tấn công DoS/replay nhờ cơ chế cookie chống giả mạo request. Vì những lý do này, triển khai mới hiện nay hầu như luôn chọn IKEv2.
7. Cấu hình IPsec VPN trên Junos (AutoKey IKE)
Junos hỗ trợ hai cách quản lý khóa: Manual Key (tự tay cấu hình toàn bộ tham số, không có negotiation — chỉ phù hợp mạng nhỏ tĩnh, gần như không dùng trong thực tế) và AutoKey IKE (dùng IKE để tự động đàm phán, hỗ trợ cả Preshared Key lẫn certificate) — phần này tập trung vào AutoKey IKE, cách làm phổ biến nhất.
Junos còn phân biệt route-based VPN (traffic đi qua tunnel dựa theo routing table, qua một pseudo-interface tên st0) và policy-based VPN (traffic được chọn theo security policy, không qua interface riêng). Route-based là cách khuyến nghị vì linh hoạt hơn hẳn — dùng được routing protocol, dễ mở rộng nhiều tunnel — nên đây là cách được trình bày dưới đây.
Cấu hình đầy đủ trên SRX-A gồm bốn nhóm lệnh:
1. IKE — Phase 1 (proposal, policy, gateway):
set security ike proposal ike-prop authentication-method pre-shared-keys
set security ike proposal ike-prop dh-group group14
set security ike proposal ike-prop encryption-algorithm aes-256-cbc
set security ike policy ike-pol proposals ike-prop
set security ike policy ike-pol pre-shared-key ascii-text "<khoá bí mật>"
set security ike gateway gw-to-B ike-policy ike-pol
set security ike gateway gw-to-B address 203.0.113.2
set security ike gateway gw-to-B external-interface ge-0/0/0
2. IPsec — Phase 2 (proposal, policy, vpn):
set security ipsec proposal ipsec-prop protocol esp
set security ipsec proposal ipsec-prop encryption-algorithm aes-256-gcm
set security ipsec policy ipsec-pol proposals ipsec-prop
set security ipsec policy ipsec-pol perfect-forward-secrecy keys group14
set security ipsec vpn vpn-to-B bind-interface st0.0
set security ipsec vpn vpn-to-B ike gateway gw-to-B
set security ipsec vpn vpn-to-B ike ipsec-policy ipsec-pol
Dòng perfect-forward-secrecy keys group14 chính là công tắc bật PFS đã nói ở Mục 6 — chỉ định luôn DH Group dùng riêng cho bước tính lại khóa ở Phase 2.
3. Tunnel interface (st0):
set interfaces st0 unit 0 family inet address 10.10.10.1/30
Khuyến nghị của Juniper: hai đầu st0 nên nằm cùng một subnet logic, vì bản chất đây là một liên kết point-to-point — giống hệt tinh thần của gr-0/0/0 ở GRE Tunnel, chỉ khác tên interface.
4. Routing — đưa traffic vào tunnel:
set routing-options static route 192.168.20.0/24 next-hop st0.0
Route này trỏ toàn bộ traffic hướng tới subnet phía site B (192.168.20.0/24) đi qua st0.0 — đúng tinh thần route-based VPN: không cần security policy riêng cho "traffic nào được vào tunnel", chỉ cần đúng route (bản chất route này chính là một policy BYPASS/PROTECT ngầm định trong SPD đã nói ở Mục 3).
8. Kiểm tra IPsec hoạt động
Vì IPsec có hai phase tách biệt (Mục 6), việc kiểm tra cũng cần soi đúng hai lớp: IKE SA (Phase 1) và IPsec SA (Phase 2) — một tunnel "lên" thật sự chỉ khi cả hai đều ở trạng thái tốt.
show security ike security-associations
# Output minh họa
Index Remote Address State Initiator cookie Responder cookie Mode
1234567 203.0.113.2 UP 93870456fa000011 723a20713700003e Main
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
show security ipsec security-associations
# Output minh họa
ID Gateway Port Algorithm SPI(in) SPI(out) Life
500024 203.0.113.2 500 ESP:aes-256-gcm 0x00002002 0x00001001 3600/unlim
(Output minh họa — cấu trúc và tên field đúng theo lệnh thật, số liệu cụ thể chỉ mang tính ví dụ.)
Field cần chú ý nhất trong hai output trên: State: UP/Matured ở lệnh đầu xác nhận Phase 1 đã xong; SPI(in)/SPI(out) ở lệnh sau chính xác là hai giá trị SPI của hai SA một chiều đã nói ở Mục 2 — nếu thấy IKE SA lên nhưng lệnh thứ hai trả về rỗng, gần như chắc chắn vấn đề nằm ở Phase 2 (proxy-id hoặc traffic-selector giữa hai đầu không khớp nhau, tức SPD ở Mục 3 chưa match đúng).
9. NAT Traversal (NAT-T) và MTU/Fragmentation
Có một vấn đề rất thực tế khi triển khai IPsec: ESP không mang theo số hiệu port như TCP/UDP — nó là một giao thức IP riêng (protocol 50). Điều này khiến một thiết bị NAT đứng giữa đường không thể phân biệt được ESP traffic của nhiều host nội bộ khác nhau để dịch địa chỉ đúng cách (NAT/PAT vốn dựa vào port để multiplex nhiều kết nối), và vì ESP Header cũng nằm trong vùng được xác thực (Mục 4), bất kỳ NAT nào cố sửa header cũng làm hỏng luôn giá trị xác thực.
💡 Hình dung như thế này: ESP giống một kiện hàng không ghi rõ "phòng số mấy" trên nhãn — nhân viên bưu cục trung chuyển (NAT) không biết chuyển tiếp cho đúng ai nếu có nhiều kiện hàng cùng lúc. NAT-T giải quyết bằng cách bỏ thêm kiện hàng đó vào một phong bì trung chuyển có ghi rõ số phòng (UDP port 4500) — nhân viên bưu cục giờ xử lý được bình thường, còn kiện hàng gốc bên trong vẫn nguyên vẹn, không bị động tới.
Cơ chế NAT-T: khi hai đầu IKE phát hiện có NAT nằm giữa đường (qua một cơ chế dò tại Phase 1), toàn bộ gói ESP được bọc thêm một lớp UDP header với cả source lẫn destination port đều là 4500. NAT giờ chỉ cần xử lý y hệt một gói UDP bình thường — dịch port như mọi kết nối UDP khác — mà không cần động chạm gì tới ESP header/payload bên trong, nên không phá vỡ giá trị xác thực.
Hệ quả trực tiếp lên MTU: đúng như nguyên tắc đã nói ở tài liệu "OSI Model & Packet Encapsulation" (Mục 6) — mọi header chen thêm vào giữa đều ăn vào chung ngân sách 1500 byte, không có ngoại lệ nào cho IPsec. Khi xếp đủ các lớp (Outer IP 20B + ESP Header ~8B + IV + ESP Trailer/Auth biến thiên + UDP 8B nếu có NAT-T), tổng overhead có thể lên tới 50-70 byte tùy thuật toán — đây chính là lý do trong thực tế, MTU cho traffic đi qua IPsec tunnel thường được hạ chủ động xuống khoảng 1400 byte thay vì để mặc định 1500, tương tự khuyến nghị đã thấy ở GRE Tunnel khi kết hợp GRE+IPsec.
10. Hạn chế và thách thức thực tế
Bốn điểm hay gây khó chịu nhất khi vận hành IPsec trong thực tế:
- NAT-T bắt buộc khi có NAT giữa hai đầu — quên bật, hoặc thiết bị NAT chặn luôn UDP 4500, tunnel sẽ không bao giờ lên được dù cấu hình Phase 1/2 hoàn toàn đúng.
- Overhead & hiệu năng — mỗi gói phải qua thêm bước mã hóa/giải mã và các lớp header bổ sung, khiến CPU tăng và throughput giảm so với traffic không mã hóa — đáng cân nhắc khi triển khai trên thiết bị công suất thấp hoặc traffic rất lớn.
- Phân mảnh gói (fragmentation) — hệ quả trực tiếp của Mục 9: nếu không chủ động hạ MTU/MSS cho traffic qua tunnel, gói dễ bị phân mảnh giữa đường hoặc bị drop hoàn toàn nếu DF bit được bật.
- Cấu hình phức tạp, 2 phase — mọi tham số ở Phase 1 lẫn Phase 2 (thuật toán mã hóa, DH group, lifetime, proxy-id...) đều phải khớp tuyệt đối giữa hai đầu; sai lệch dù chỉ một tham số cũng khiến toàn bộ negotiation thất bại mà thông báo lỗi nhiều khi không chỉ thẳng ra tham số nào sai.
Theo kinh nghiệm triển khai thực tế: khi một tunnel IPsec "không chịu lên", thứ tự kiểm tra hợp lý nhất là đi từ Mục 8 trở ra — trước tiên xem IKE SA (Phase 1) đã Matured/UP chưa, nếu chưa thì kiểm tra lại preshared key và proposal có khớp không; nếu Phase 1 đã xong mà Phase 2 vẫn trống, gần như chắc chắn vấn đề nằm ở proxy-id/traffic-selector (tức SPD, Mục 3) chứ hiếm khi do thuật toán mã hóa.
Nguồn tham khảo
Nguồn gốc: AWS — "What is IPsec?" (link); Huawei — IPsec Encyclopedia (link); Juniper Networks — "IPsec Basics" (link).
- SA là thỏa thuận một chiều, giao tiếp 2 chiều cần tối thiểu 2 SA; thành phần SA gồm giao thức, mode, thuật toán, khóa, lifetime — Juniper: IPsec Basics.
- SPD quyết định Protect/Discard/Bypass dựa theo Selector; SAD lưu SA đang active, tra theo dest IP + protocol + SPI; gói không khớp policy nào bị discard mặc định — RFC 4301, rfc-editor.org/info/rfc4301.
- AH xác thực toàn bộ gói IP (không mã hóa); ESP mã hóa + xác thực, vùng Auth (ICV) không phủ IP header — Huawei: IPsec Encyclopedia.
- AES-GCM (AEAD) là lựa chọn khuyến nghị hiện nay; DES/3DES/MD5/SHA-1 bị coi là yếu, nên chuyển sang SHA-256 trở lên — CNSA Suite 2.0 Profile for IPsec (draft).
- PFS buộc Phase 2 tính lại Diffie-Hellman độc lập với Phase 1, cô lập rủi ro nếu một khóa bị lộ — Fortinet: Understanding Perfect Forward Secrecy (PFS), IBM: Does IKE support Perfect Forward Secrecy?.
- DH Group 1/2/5 (768-1536 bit) không khuyến nghị; Group 14/15/16 (2048-4096 bit) và Group 19/20/21 (ECC 256-521 bit) khuyến nghị — CNSA Suite 2.0 Profile for IPsec (draft), Juniper: IPsec Basics.
- Junos OS luôn dùng Tunnel Mode cho IPsec, không có Transport Mode — Juniper: IPsec Basics.
- IKEv2: 4 message (2 exchange) so với IKEv1 tới 6-9 message; NAT-T tích hợp sẵn; hỗ trợ MOBIKE; chống DoS/replay tốt hơn — 2026, ExpressVPN: IKEv2 vs IKEv1.
- ESP (protocol 50) không có port number nên NAT không xử lý được; NAT-T bọc ESP trong UDP port 4500 — Microsoft Learn: Traversing NATs and NAPTs with UDP-Encapsulated ESP Packets.
- Route-based VPN trên Junos dùng interface
st0, traffic forward theo routing table thay vì policy; hai đầu st0 nên cùng subnet logic vì là point-to-point — Juniper: Route-Based IPsec VPNs. - Output
show security ike security-associationsvàshow security ipsec security-associations— Juniper: show security ike security-associations, Juniper: show security ipsec security-associations. - NAT-T cộng thêm 8 byte UDP header vào tổng overhead, khiến MTU thực tế qua tunnel IPsec thường phải hạ xuống — 2026, Huawei: IPsec Encyclopedia — Packet Fragmentation.