Công nghệ VPN được xây dựng hướng tới 3 mục tiêu chính: cung cấp truy nhập từ xa mọi lúc, mọi nơi tới tài nguyên trên internet; kết nối các thiết bị của một nhóm, một đơn vị với nhau không kể khoảng cách địa lý thông qua internet, kiểm soát truy nhập của người dùng, nhà cung cấp và các thực thể bên ngoài tới những tài nguyên cụ thể.
Trong đó, IKE (Internet Key Exchange) là giao thức đường hầm mã hóa được VPN sử dụng nhằm bảo đảm tính ổn định cho lưu lượng internet. Giao thức VPN này còn được gọi là IKEv2/IPsec, nhưng vì IKEv2 luôn luôn triển khai cùng lớp mã hóa IPsec, nên được rút gọn chỉ là IKEv2. IKEv2 được coi là nhẹ và ổn định hơn OpenVPN trong khi vẫn giữ được một số khả năng tùy chỉnh. Nhưng nó chỉ khả dụng qua UDP, bị chặn bởi một số tường lửa.
IKEv2 là một trong những giao thức mới nhất và có những điểm mạnh đáng kể, đặc biệt là tốc độ của nó. Nó rất phù hợp cho các thiết bị di động trên tất cả các nền tảng. IKEv2 sẽ xác thực cả thiết bị của người dùng với máy chủ VPN và thương lượng loại bảo mật nào sẽ được sử dụng giữa hai thực thể này, trong một quy trình được gọi là liên kết bảo mật. Nó sẽ tạo ra các khóa mã hóa giống nhau được sử dụng để mã hóa và giải mã tất cả dữ liệu đi qua đường hầm VPN. Mục tiêu của IKE là tạo ra cùng một khóa đối xứng (symmetric key) nhằm tạo điều kiện cho các bên giao tiếp độc lập. Key được tạo dùng để mã hóa và giải mã các gói IP thông thường, được sử dụng để truyền dữ liệu giữa các VPN đồng cấp. IKE được gọi là đường hầm mã hóa vì nó tạo ra một “đường hầm” hay một luồng an toàn VPN khi các bên đạt được thỏa thuận về phương pháp mã hóa hay tính toàn vẹn và xác thực cả hai bên.
IKE hoạt động trên các phương pháp mã hóa dữ liệu được chấp nhận rộng rãi, chẳng hạn như ISAKMP, SKEME hoặc OAKLEY. Trong đó, ISAKMP là giao thức làm nhiệm vụ thiết lập, thỏa thuận và quản lý chính sách bảo mật trao đổi các thông số bảo mật; Oakley áp dụng thuật toán trao đổi key Diffie–Hellman (phương thức chuyển tiếp bí mật hoàn hảo cho key, bảo vệ danh tính và xác thực thông qua môi trường chưa bảo mật) giúp thực hiện việc trao đổi tài liệu key thông qua một kết nối không bảo mật.
Tổng quan phiên bản IKE
IKE có hai phiên bản, 1 và 2. Phiên bản đầu tiên được công bố vào năm 1998. IKEv1 ban đầu được thiết kế để thay thế khả năng tương tác cho giao thức IPSec VPN độc quyền của Cisco. Bản chất phiên bản này vẫn hiệu quả và vẫn được sử dụng rộng rãi, tuy nhiên do sự phát triển của công nghệ nên phiên bản này mắc phải một số lỗ hổng bảo mật nghiêm trọng và đòi hỏi sự thay thế.
Phiên bản IKEv2 được công bố vào năm 2005, bản cập nhật cuối được xây dựng dạng tiêu chuẩn hóa do Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF) công bố tại RFC 7296 vào năm 2014. Cả IKEv1 và IKEv2 đều được xây dựng trên IKE, giao thức được sử dụng để thiết lập một hiệp hội bảo mật (IKE Security Association (SA)). Nhưng IKEv2 cung cấp trải nghiệm VPN tốt hơn:
- IKEv2 cung cấp kết nối VPN ổn định và nhất quán hơn IKEv1 do hỗ trợ MOBIKE (Mobility and Multi-homing Protocol).
- Sử dụng khóa mã hóa cho cả hai đầu của kết nối VPN, IKEv2 an toàn hơn IKEv1.
- Với khả năng truyền tải NAT tích hợp, IKEv2 thiết lập kết nối nhanh hơn nhiều so với IKEv1.
- IKEv2 chiếm ít băng thông hơn và ít dữ liệu hơn.
Xét về ưu điểm và nhược điểm của IKEv2 trong triển khai VPN thì IKEv2 có ưu điểm là:
- Một trong những giao thức VPN nhanh nhất. Nhanh hơn L2TP và PPTP.
- An toàn cao vì nó mã hóa bằng các cypher cao cấp, bao gồm AES và Camellia, và các thuật toán mã hóa 256-bit.
- Cung cấp kết nối mạnh mẽ và ổn định, cho phép người dùng duy trì kết nối VPN khi chuyển đổi giữa các mạng.
- Giao thức VPN duy nhất được hỗ trợ trên các thiết bị BlackBerry.
Và nhược điểm là:
- IKEv2 sử dụng Cổng UDP 500, có thể khiến tường lửa hoặc quản trị viên mạng ngăn VPN hoạt động.
- Chỉ được hỗ trợ trực tiếp phiên bản hoàn chỉnh trên Mac và iOS nhưng Windows, Android hoặc Linux không dược hỗ trợ như vậy.
Một số tình huống triển khai IKEv2
Trường hợp 1: Kết nối hai cổng bảo mật ở chế độ đường hầm
Trong trường hợp này, không có điểm cuối của kết nối IP nào triển khai IPsec, nhưng các nút mạng giữa hai cổng bảo vệ lưu lượng truy cập cho từng phần của quá trình. Sự bảo vệ là xuyên suốt quá trình và phụ thuộc vào việc định tuyến thông thường để gửi các gói thông qua các điểm cuối đường hầm để xử lý. Mỗi điểm cuối sẽ thông báo tập hợp địa chỉ "đằng sau" nó và các gói tin sẽ được gửi ở chế độ đường hầm trong đó tiêu đề IP bên trong sẽ chứa địa chỉ IP của các điểm cuối thực tế.
Hình 1: Kết nối hai cổng bảo mật ở chế độ đường hầm
Trường hợp 2: Kết nối theo chế độ trao đổi điểm cuối đến điểm cuối
Trong trường hợp này, cả hai điểm cuối của kết nối IP đều triển khai IPsec, theo yêu cầu của các máy chủ căn cứ theo giao thức kiến trúc bảo mật cho Internet (Rfc 4301). Chế độ truyền tải thường được sử dụng mà không có tiêu đề IP bên trong. Một cặp địa chỉ sẽ được thương lượng để các gói được bảo vệ bởi SA này. Các điểm cuối có thể triển khai các kiểm soát truy cập lớp ứng dụng dựa trên danh tính đã xác thực IPsec của những người tham gia. Kịch bản này cho phép bảo mật đầu cuối tuân theo nguyên tắc kiến trúc của Interenet (Rfc 1958), tính minh bạch của Interent (Rfc 2775) và một phương pháp hạn chế các vấn đề cố hữu về độ phức tạp trong các mạng mà một số nguyên tắc và triết lý kiến trúc Internet (Rfc 3439) lưu ý. Mặc dù trường hợp này có thể không hoàn toàn áp dụng được cho Internet IPv4, nhưng nó đã được triển khai thành công trong các tình huống cụ thể trong mạng nội bộ bằng IKEv1. Đồng thời kịch bản này sẽ được kích hoạt rộng rãi hơn trong quá trình chuyển đổi sang IPv6 và khi áp dụng IKEv2.
Có thể trong trường hợp này, một hoặc cả hai điểm cuối được bảo vệ sẽ nằm sau nút dịch địa chỉ mạng (network address translation - NAT), trong trường hợp đó, các gói đường hầm sẽ phải được đóng gói UDP để số cổng trong tiêu đề UDP có thể được sử dụng xác định các điểm cuối riêng lẻ "đằng sau" NAT.
Hình 2: Kết nối theo chế độ trao đổi điểm cuối đến điểm cuối
Trường hợp 3: Kết nối theo chế độ đường hầm cho điểm cuối tới cổng bảo mật
Trong trường hợp này, một điểm cuối được bảo vệ (thường là máy tính chuyển vùng di động) kết nối trở lại mạng chung với nhiều điểm kết nối cá nhân (mạng công ty, cơ quan, tổ chức) thông qua một đường hầm được bảo vệ bằng IPsec. Nó có thể chỉ sử dụng đường hầm này để truy cập thông tin trên mạng đó hoặc nó có thể chuyển toàn bộ lưu lượng truy cập trở lại qua mạng để tận dụng sự bảo vệ do tường lửa của mạng chung cung cấp chống lại các cuộc tấn công dựa trên Internet. Trong cả hai trường hợp, điểm cuối được bảo vệ sẽ muốn một địa chỉ IP được liên kết với cổng bảo mật để các gói được chuyển đến nó sẽ đi đến cổng bảo mật và được chuyển trở lại đường hầm. Địa chỉ IP này có thể tĩnh hoặc có thể được cấp phát động bởi cổng bảo mật. Để hỗ trợ cho trường hợp thứ hai, IKEv2 bao gồm một cơ chế (cụ thể là tải trọng cấu hình) để trình khởi tạo yêu cầu địa chỉ IP thuộc sở hữu của cổng bảo mật để sử dụng trong suốt thời gian SA của nó.
Hình 3: Kết nối theo chế độ đường hầm cho điểm cuối tới cổng bảo mật
Trong trường hợp này, các gói tin sẽ sử dụng chế độ đường hầm. Trên mỗi gói từ điểm cuối được bảo vệ, tiêu đề IP bên ngoài sẽ chứa địa chỉ IP nguồn được liên kết với vị trí hiện tại của nó (tức là địa chỉ sẽ nhận lưu lượng truy cập được định tuyến trực tiếp đến điểm cuối), trong khi tiêu đề IP bên trong sẽ chứa địa chỉ IP nguồn được chỉ định bởi cổng bảo mật (tức là địa chỉ sẽ nhận lưu lượng truy cập được định tuyến đến cổng bảo mật để chuyển tiếp đến điểm cuối). Địa chỉ đích bên ngoài sẽ luôn là địa chỉ của cổng bảo mật, trong khi địa chỉ đích bên trong sẽ là đích cuối cùng của gói tin. Trong trường hợp này, có thể điểm cuối được bảo vệ sẽ nằm sau NAT, địa chỉ IP được nhìn thấy bởi cổng bảo mật sẽ không giống với địa chỉ IP được gửi bởi điểm cuối được bảo vệ và các gói sẽ phải được đóng gói UDP để được định tuyến đúng cách.
Ngoài 3 trường hợp chính kể trên, thực chất có rất nhiều tình huống kết nối khác. Ví dụ như mạng con có thể thực hiện tất cả các truy cập bên ngoài thông qua cổng bảo mật từ xa bằng đường hầm IPsec, nơi các địa chỉ trên mạng con được phần còn lại của Internet chuyển đến cổng bảo mật. Một ví dụ khác nữa là mạng gia đình của ai đó hầu như đang ở trên Internet với các địa chỉ IP tĩnh mặc dù kết nối được cung cấp bởi một ISP chỉ định một địa chỉ IP được chỉ định động duy nhất cho cổng bảo mật của người dùng (trong đó địa chỉ IP tĩnh và một chuyển tiếp IPsec được cung cấp bởi một bên thứ ba ở nơi khác). Tuy nhiên ba trường hợp cụ thể dưới là ba trường hợp chính và cơ bản nhất để tiến hành kết nối có sử dụng IKEv2.
Lưu ý triển khai cụ thể của IKEv2
IKE thường tiếp nhận và gửi phản hồi trên cổng UDP 500, mặc dù thông báo IKE cũng có thể được nhận trên cổng UDP 4500 với định dạng hơi khác. Vì UDP là một giao thức datagram (không đáng tin cậy), IKE xử lý việc khôi phục định nghĩa của nó khỏi các lỗi truyền, bao gồm mất gói, phát lại gói và giả mạo gói. IKE được thiết kế để hoạt động miễn là ít nhất một trong một loạt các gói được truyền lại đến đích trước khi hết thời gian và kênh không chứa đầy các gói giả mạo và phát lại để làm cạn kiệt dung lượng mạng hoặc CPU của một trong hai điểm cuối. Ngay cả khi không có các yêu cầu hiệu suất tối thiểu đó, IKE vẫn được thiết kế để không hoạt động hoàn toàn (như thể mạng đã bị hỏng).
Mặc dù các thông điệp IKEv2 có mục đích ngắn gọn, nhưng chúng chứa các cấu trúc không có giới hạn tối đa cố định về kích thước (cụ thể là chứng chỉ số) và bản thân IKEv2 không có cơ chế phân mảnh các thông điệp lớn. IP xác định cơ chế phân mảnh các bản tin UDP quá khổ, nhưng việc triển khai khác nhau ở kích thước bản tin tối đa được hỗ trợ. Hơn nữa, việc sử dụng phân mảnh IP mở ra một triển khai cho các cuộc tấn công từ chối dịch vụ (DoS). Bên cạnh đó, số triển khai NAT hoặc tường lửa có thể chặn các đoạn IP.
Tất cả các triển khai IKEv2 cần phải có khả năng gửi, nhận và xử lý các tin nhắn IKE có độ dài lên đến 1280 octet. Khuyến nghị tối ưu nhất là xử lý gửi, nhận và xử lý các tin nhắn có độ dài lên đến 3000 octet. Việc triển khai IKEv2 cần lưu ý về kích thước thư UDP tối đa được hỗ trợ và có thể rút ngắn thư bằng cách loại bỏ một số chứng chỉ hoặc đề xuất bộ mật mã nếu điều đó sẽ giữ thư dưới mức tối đa. Việc sử dụng các định dạng "Hash và URL" thay vì bao gồm các chứng chỉ trong trao đổi nếu có thể tránh được hầu hết các vấn đề. Tuy nhiên, việc triển khai và cấu hình cần lưu ý rằng nếu việc tra cứu URL chỉ có thể thực hiện được sau khi Child SA được thiết lập, các vấn đề đệ quy có thể ngăn kỹ thuật này hoạt động.
Tải trọng UDP của tất cả các gói chứa thông điệp IKE được gửi trên cổng 4500 phải bắt đầu bằng tiền tố là bốn số không; nếu không, người nhận sẽ không biết cách xử lý chúng.
Kết luận
Trong bài viết này, tiêu chuẩn mạng ảo hóa IKEv2 được giới thiệu đến bạn đọc một cách cơ bản từ tổng quan đến một số tình huống triển khai cơ bản. Đây là một tiêu chuẩn được sử dụng phổ biến đối với kết nối mạng ảo hóa đặc biệt khi ngày nay IPv6 đang được triển khai rộng rãi và việc làm việc trực tuyến cần kết nối vào mạng nội bộ.
Thông qua việc giới thiệu giao thức này, bài đọc đưa ra các cơ sở tri thức từ tổng quan, lợi ích đến những chú ý cơ bản trong triển khai IKEv2 cho việc thiết lập mạng ảo. Việc thiết lập mạng ảo sử dụng IKEv2 đã được một số bên cung cấp dịch vụ rộng rãi và dễ dàng cài đặt cho người dùng.
Lê Nhật
Tài liệu tham khảo
- C. Kaufman (Microsoft), P. Hoffman (VPN Consortium), Y. Nir (Check Point), P. Eronen (Independent), T. Kivinen (INSIDE Secure), RFC 7296, October 2014 Internet Key Exchange Protocol Version 2 (IKEv2), ISSN: 2070 - 1721.