Internet Protocol Security (IPsec) là giao thức cho phép tạo đường hầm ảo (virtual tunnel), các gói IP đi qua đường hầm này sẽ được mã hóa để bảo mật và toàn vẹn dữ liệu gói tin giữa hai đầu đường hầm (IPsec gateways - GWs). Một IPsecVPN (IPsec virtual private network) có thể kết nối nhiều mạng riêng (private networks - NWs) khác nhau trên internet tạo thành nhóm liên kết an toàn riêng (Closed User Group – CUG). Thông thường, một IP-VPN sử dụng IPsec được gọi là IPsecVPN. IPsecVPN hiện đang là mô hình được triển khai cho việc kết nối an toàn các mạng riêng (NWs) của dịch vụ ĐTĐM và các mạng riêng của người dùng trên internet, ví dụ như Windows Azure hay Amazon VPC.

Với sự phát triển nhanh chóng của ĐTĐM đã xuất hiện nhiều nhà cung cấp dịch vụ ĐTĐM khác nhau trên toàn thế giới. Một người dùng đầu cuối của các tổ chức sẽ có nhu cầu kết nối không chỉ với máy chủ riêng (private server) mà còn cần kết nối đến rất nhiều nhà cung cấp dịch vụ ĐTĐM khác thông qua IPsecVPN như hình vẽ sau:

Khi người dùng cần kết nối tới nhiều nhà cung cấp dịch vụ ĐTĐM khác nhau như hình vẽ trên thì sẽ có nhiều thách thức với mô hình triển khai IPsecVPN.

Hiện nay, có hai kiến trúc IPsecVPN đang được triển khai phổ biến là Full-Mesh IPsecVPN và Hub-and-Spoke IPsecVPN. 

Full-Mesh IPsecVPN là mô hình kết nối các mạng riêng trực tiếp với nhau thông qua IPsec, giao dịch giữa các mạng riêng là giao dịch IPsec trực tiếp. Một số ưu điểm của kiến trúc này là tất cả các kế nối giữa các mạng riêng sẽ có đường đi ngắn nhất, không có hiện tượng tắc nghẽn kiểu nút cổ chai (bottleneck). Nhược điểm của kiến trúc này là mỗi cổng kết nối IPsec cần có một chính sách trao đổi khóa internet (Internet key exchange – IKE/IPsec) bao gồm các thông tin thuật toán mã hóa, thông tin xác thực hay các thông tin về băng thông. Một cách thông thường, mỗi cổng IPsec chia sẻ chính sách IKE/IPsec cho tất cả các cổng IPsec mà nó cần kết nối.

Mô hình Hub-and-Spoke IPsecVPN.

Hub-and-Spoke IPsecVPN là mô hình kết nối tất cả các mạng riêng sử dụng IPsec thông qua một cổng kết nối trung tâm Hub-Gateway (Hub-GW) và các giao dịch giữa các mạng riêng này sẽ được chuyển qua Hub-GW. Theo đó, trong mô hình Hub-and-Spoke IPsecVPN tất cả các mạng riêng có thể kết nối được với các mạng riêng khác với chỉ một kết nối IPsec tới Hub-GW. Mỗi cổng kết nối IPsec sẽ chỉ cần một chính sách IKE/IPsec có thể kết nối tới tất cả các cổng kết nối IPsec khác, đó là một ưu điểm của mô hình này. Tuy nhiên, theo mô hình này các giao dịch đều đi qua Hub-GW nên có hai nhược điểm, thứ nhất là các giao dịch phải đi vòng qua Hub-GW và cần được định tuyến trên Hub-GW; thứ hai là tại Hub-GW có thể xảy ra hiên tượng tắc nghẽn theo kiểu nút cổ chai khi số lượng giao dịch qua Hub-GW là lớn.

Các mô hình đám mây lai (Hyprid-Cloud) và đám mây tích hợp (inter-cloud) đã cho phép nhiều dịch vụ đám mây và nhiều máy chủ dễ dàng kết nối với nhau để sử dụng chung tài nguyên. Với kịch bản như vậy thì các yêu cầu cần thiết của việc triển khai IPsecVPN cho các dịch vụ ĐTĐM về một số vấn đề được chỉ ra như sau:

Yêu cầu 1: Số lượng lớn các thành viên tham gia kết nối IPsecVPN (numbers of CUG members): IPsecVPN cần có khả năng kiểm soát số lượng lớn các kết nối đường hầm IPsec, vì với dịch vụ ĐTĐM thì số lượng này sẽ tăng lên nhanh chóng.

Yêu cầu 2: Luồng thông tin giữa các thành viên tham gia kết nối đường hầm IPsec trực tiếp (traffic between CUG members): IPsecVPN cần có khả năng kiểm soát với số lượng lớn các giao dịch giữa các thành viên tham gia kết nối đường hầm IPsec.

Yêu cầu 3: Thêm mới thành viên tham gia kết nối IPsec vào hệ thống (addition CUG members): IPsecVPN cần có khả năng thêm các kết nối từ các mạng riêng vào dịch vụ ĐTĐM một cách dễ dàng mà không ảnh hưởng đến các thiết lập trước đó.

Yêu cầu 4: Thời gian giữ hậm tối thiểu (minimum delay): IPsecVPN cần có khả năng giảm thời gian dữ chậm gói tin truyền giữa các cổng kết nối IPsec đến mức nhỏ nhất.

Yêu cầu 5: Kiểm soát giao dịch (traffic control): IPsecVPN cần có khả năng chỉ cho phép các gói tin cần thiết, hợp lệ truyền qua đường hầm IPsec. 

Trong phần này chúng ta sẽ phân tích các kiến trúc IPsecVPN hiện tại theo các yêu cầu đưa ra ở phần trên.

Theo kiến trúc Full-Mesh các giao dịch giữa các cổng IPsec là trực tiếp nên các gói tin qua đường hầm sẽ là ngắn nhất và không bị dữ chậm nên nó đáp ứng yêu cầu 2 và 4. Tuy nhiên kiến trúc này sẽ không đáp ứng yêu cầu 1, 3 và 5, vì với số lượng lớn các kết nối đường hầm IPsec thì việc kiểm soát các chính sách IKE/IPsec tại mỗi cổng kết nối là rất phức tạp, việc thay đổi đường hầm sẽ ảnh hưởng đến các kết nối trước đó và việc áp dụng các luật lọc gói tin tại các cổng kết nối cũng sẽ gặp nhiều khó khăn. 

Theo mô hình Hub-and-Spoke, mỗi mạng riên chỉ cần một kết nối duy nhất đến trung tâm Hub-GW là có thể giao dịch được với các mạng riêng khác. Ngược với mô hình Full-Mesh, mô hình Hub-and-Spoke sẽ thỏa mãn yêu cầu 1, 3 và 5, nhưng không thỏa mãn yêu cầu 2 và 4. 

Bảng bên thể hiện sự khác nhau giữa hai mô hình dựa theo 5 yêu cầu ở phần trên

Qua phân tích hai mô hình IPsecVPN hiện tại ở trên, nhóm nghiên cứu ở Nhật Bản đã đề xuất mô hình IPsecVPN động tận dụng được các ưu điểm của cả hai mô hình trên như hình sau. 

Theo mô hình đề xuất, khi số lượng cổng kết nối IPsec tham gia chưa nhiều thì hệ thống sẽ làm việc theo mô hình Hub-and-Spoke, nhưng khi số lượng kết nối tăng lên nhiều thì các yêu cầu kết nối mới sẽ được chuyển sang kết nối trực tiếp mà không đi qua Hub-GW, do đó mô hình này còn được gọi là mô hình lai (hybrid) 

Để triển khai mô hình đề xuất, cần áp dụng phương pháp thiết lập kết nối IPsec động sử dụng MOBIKE mở rộng.

Hoạt động của MOBIKE có thể được mô tả tóm tắt như sau: nếu có một kết nối IPsec trên địa chỉ A và B, và một địa chỉ C thông báo cho B một thông báo hợp lệ của IKEv2 bao gồm “UPDATA_SA_ADDRESSES” sau đó kết nối IPsec sẽ chuyển từ địa chỉ thành C và B. C phải có giá trị liên kết an toàn (SA – security association) IKE hợp lệ để thông báo cho C theo IKEv2, và đó là điều cần thiết cho việc thông báo cho mỗi đầu kết nối MOBIKE_SUPPORTED khi IKE/IPsec được thiết lập. Chức năng chính của MOBIKE là cho phép chuyển mạch kết nối giữa nhiều giao diện khác nhau sử dụng IKE/IPsec. 

Quá trình hoạt động của mô hình này có thể được mô tả theo các trạng thái như sau:

-Trạng thái thông thường: khi mạng A kết nối với mạng E thông qua Hub-GW theo mô hình Hub-and-Spoke.

-Khi số lượng các giao dịch IPsec qua Hub-GW tăng lên đáng kể: lưu lượng thông tin giao dịch giữa mạng A và mạng E tăng, Hub-GW thiết lập một kết nối VPN mở rộng từ chính nó tới địa chỉ của cổng mạng E. Có 2 vấn đề cần lưu ý: thứ nhất là do không thể thiết lập kết nối IKE/IPsec giữa hai điểm cùng địa chỉ, Hub-GW cần phải có địa chỉ IP “A2” cho kết nối mở rộng, ngoài địa chỉ “A1”. Kết nối IKE/IPsec giữa “U” và “A2” cần có cùng chính sách kết nối như kết nối giữa “U” và “A1”; thứ hai là thông báo MOBIKE_SUPPORTED phải được gửi khi bắt đầu kết nối IKEv2/IPsec do đó MOBIKE có thể gửi sau.

-Yêu cầu thực hiện MOBIKE: Hub-GW gửi thông báo cho mạng A với nội dung là các thông tin về kết nối an toàn IKE/IPsec mở rộng và yêu cầu thực hiện kết nối MOBIKE tới mạng E theo kết nối an toàn trên, yêu cầu được định nghĩa là “DO_MOBIKE_WITH_THIS_SA”

-Tạo kết nối trực tiếp thông qua MOBIKE: GW trong mạng A, khi nhận được thông báo “DO_MOBIKE_WITH_THIS_SA”, sẽ gửi thông báo cho mạng E với nội dung là “UP_DATE_SA_ADDRESSES” theo kết nối IKE SA nhận được. GW mạng E trả lời yêu cầu kết nối từ mạng A và địa chỉ kết nối IKE/IPsec mở rộng sẽ chuyển từ U tời A2 thành từ U tới S.

-Bắt đầu trao đổi thông qua kết nối trực tiếp: Lúc này, dữ liệu trao đổi từ mạng nội bộ E với đám mây A sẽ được truyền trực tiếp mà không bị giữ chậm tại Hub-GW.

Bài viết này đã giới thiệu về các yêu cầu đối với IPsec VPN khi triển khai ứng dụng vào trong các dịch vụ ĐTĐM, một số hạn chế của các mô hình VPN truyền thống khi ứng dụng vào ĐTĐM. Từ đó, bài viết đã giới thiệu một đề xuất mô hình MOBIKE để thiết lập các đường hầm liên kết an toàn sử dụng IPsec VPN đáp ứng được các yêu cầu khi triển khai cho các dịch vụ ĐTĐM.

Tài liệu tham khảo 1. Network Service Systems Laboratories, NTT Corporation, Japan; “Dynamic IP-VPN architecture with secure IPsec tunnels”; 2007 2. Wen-Hwa Liao, Shuo-Chun Su, Tatung University, Taipei, Taiwan; “A Dynamic VPN Architecture for private Cloud Computing”; Fourth IEEE international Conference; 2011. 3. Dayananda M S, Ashwin Kumar, Dept. of CSE, RITM, Bengaluru, India; “Architecture for inter-cloud services using IPsec VPN”; Second International Conference on Advanced Computing & Communication Technologies, 2012.