Công nghệ mạng viễn thông - Dynamic Multipoint VPN

TRƯỜNG ĐH CÔNG NGHỆ THÔNG TIN -KHOA MẠNG MÁY TÍNH & TRUYỀN THÔNG  Dynamic Multipoint VPN  Đề tài môn: Công nghệ mạng viễn thông      Tháng 12 năm 2011  Chắc hẳn bạn đã từng nghe qua khái niệm về VPN. Đó là giải pháp để kết nối mạng giữa doanh nghiệp và người dùng cá nhân, hoặc với văn phòng, chi nhánh. VPN cho phép thông qua mạng internet, để thiết lập một mạng LAN ảo, khi đó cá nhân (host) được xem như là một host trong mạng LAN. Dữ liệu được truyền tải thông qua internet sẽ được đóng gói và mã hóa. Có nhiều giao thức để mã hóa dữ liệu này, phồ biến nhất là IPSec. Trong bài viết này, tôi xin giới thiệu đến các bạn một kỹ thuật mới có liên quan đến VPN đó là Dynamic Multipoint VPN. Multipoint có nghĩa là đa điểm, bạn hình dung nó giống với VNP dạng site-to-site, tức là kết nối giữa chi nhánh (branch) và trung tâm (central). Dynamic là động, có nghĩa là kết nối này hoàn toàn tự động. Để hiểu rỏ hơn về DMVPN, chúng ta sẽ đi vào việc nghiên cứu triển khai hệ thống mạng DMVPN này.  Phần 1: Tổng quan Để triển khai mạng DMVPN, chúng ta có hai cách thức triển khai. Đó là hub-and-spoke và spoke-and-spoke. Để hiểu được hai khái niệm này, trước tiên bạn nên hiểu hub là gì, và spoke là gì. Hub ở đây là trung tâm (central), tức là hệ thống mạng WAN đặt ở trung tâm của công ty. Còn Spoke chỉ chi nhánh, văn phòng. Nhìn vào hình 1.1 minh họa cho điều đó, Hub chính là phần Central Site, còn Spoke chính là phần Branches. / Hình 1. 1: Mô hình triển khai DMVPN Cũng trên hình 1.1, chúng ta thấy rõ đường màu xanh chính là kết nối giữa Spoke-and-Spoke, còn màu đỏ chính là kết nối giữa Hub-and-Spoke. Như vậy, Hub-and-Spoke là kết nối từ trung tâm đến chi nhánh, nó tương tự như khái niệm trong Site-to-Site. Khái niệm mới chính là ở chổ Spoke-and-Spoke, là kết nối giữa các chinh nhánh với nhau. Nếu như trong VPN, bạn chỉ nghe nhắc đến kết nối một Client đến một Site, hoặc một Site đến một Site, thì trong DMVPN, bạn sẽ tiếp tục có một khái niệm mới hơn, đó là kết nối giữ nhiều Hub đến nhiều Spoke, điều này lý giải tại sao nó có thêm chữ Multipoint. Có một vài tên gọi mà các bạn nên lưu tâm đến để tránh nhầm lẫn. Khi nói đến Hub và Spoke là ý đang nói đến router thực hiện chức năng DMVPN ở trung tâm và chi nhánh. Còn khi nói đến Site Central và Site Branch (hay gọi tắc là Central và Branch) là nói đến nhiều thiết bị có ở đó, Hub và Spoke nằm ở Central và Branch. Các thành phần của DMVPN Chúng ta sẽ cùng thảo luận về các thành phần cần thiết để triển khai một hệ thống mạng doanh nghiệp, sử dụng DMVPN để kết nối các văn phòng chi nhánh. Đầu tiên, không cần phải tính toán, đó là hệ thống Hub và Spoke. Ở hai phía phải có những thiết bị hổ trợ tốt trong việc tạo kết nối DMVPN. Có nhiều giải pháp để chúng ta lựa chọn, nhưng phổ biến nhất vẫn là Router của Cisco. Nhìn vào mô hình ở hình 1.1, chúng ta nhận thấy rằng, để kết nối được giữa Hub và Spoke nó phải kết nối thông qua Cloud. Cloud ở đây ám chỉ nhà cung cấp dịch vụ internet (ISP). Có nhiều giải pháp cho bạn sử dụng các dịch của ISP cung cấp. Cloud này có thể là Frame-Reply, ATM, Leased Lines. Kỹ thuật thiết kế Trong thiết kế DMVPN, có hai topology được đưa ra bàn luận: Dual hub-dual DMVPN cloud Dual hub-single DMVPN cloud Trước tiên bạn cần hiểu DMVPN cloud là gì, nó là tập hợp các router được cầu hình định tuyến để giao tiếp với nhau. Bạn có thể dùng giao thức mGRE hoặc PPP hoặc là cả hai để cấu hình giao tiếp với các router này, chúng phải có cùng subnet. Như vậy hai kỹ thuật đề cập ở trên có thể hiểu là đa hub đa DMVPN cloud và đa hub một DMVPN cloud. Nó được minh họa như trong hình 1.2 và 1.3 / Hình 1. 2: Dual DMVPN Cloud Topology Trong mô hình Dual hub dual DMVPN cloud, Hub 1 là trung tâm chính, nó kết nối với các Branch qua DMVPN cloud 1, và dĩ nhiên chúng có cùng subnet. Nó duy trì kết nối thường xuyên hơn. Trong khi đó, Hub 2 được khuyến cáo là để dự phòng trong trường hợp Hub 1 gặp chút trục trặc. Giữa Hub1 và Hub 2 được khuyến cáo kết nối với nhau trong mạng campus và không cùng subnet (cùng một net, tức là net được chia mạng con). Điều tất nhiên phải đảm bảo là cả hub 1 và hub 2 đều phải giao tiếp được với hệ thống mạng bên trong. Giải pháp này được biết đến với khả năng Failover, tức là hạn chế sự cố, luôn duy trì kết nối. / Hình 1. 3: Single DMVPN Cloud Topology Mô hình thứ hai, dual hub singel DMVPN cloud, bạn chỉ có một đường mạng để kết nối tất cả các hub và branch. Từ DMVPN Cloud bạn thấy chúng ta có hai kết nối về hai hub. Giải pháp này được biết đến với khả năng load balanced. DMVPN cloud hổ trợ cho cả hai mô hình triển khai hub-and-spoke và spoke-and-spoke. Trong hub-and-spoke, mỗi headend chứa một interface mGRE và mỗi branch có chứ cả p2p hoặc mGRE interface. Trong mô hình spoke-and-spoke cả hai đầu headend và branch đều có mGRE interface. Dual DMVPN Cloud Topology Với Dual Cloud chúng ta sẽ thảo luận cho hai model triển khai: Hub-and-spoke Spoke-to-spoke Hub-and-Spoke Với Dual DMVPN cloud trong model hub-and-spoke, có chứa hai headend (hub1 và hub2), mỗi cái có một hoặc nhiều tunnel mGRE kết nối đến tất cả các branch. Hình 1.4 minh họa cho chúng ta điều đó. / Hình 1. 4: Dual DMVPN Cloud Topology—Hub-and-Spoke Deployment Model Mỗi DMVPN cloud được đại diện bằng IP duy nhất trong subnet. Một DMVPN cloud được gọi là primary (cloud chính), chịu trách nhiệm cho mọi lượng mạng của Branch đi qua. Mỗi branch có chứa hai interface p2p GRE kết nối đến mỗi Hub riêng lẽ. Trong model triển khai này không có tunnel nào giữa các branch. Giao tiếp nội bộ giữa các branch được cung cấp thông qua hub. Thông số metric của giao thức định tuyến mà hệ thống sử dụng, được sử dụng để xác định đâu là primary hub. Kiến trúc hệ thống của trung tâm (system headend) Có hai kiến trúc dành cho hệ thống trung tâm được đưa ra triển khai là: Single Tier Dual Tier Single Tier Trong kiến trúc Single Tier, về mặt chức năng thì mGRE và Crypto cùng tồn tại trong một CPU của router. / Hình 1. 5: Single Tier Headend Architecture Hình 1.5 là giải pháp dual cloud với model hud-and-spoke. Tất cả các Headend đều có tunnel mGRE và Crypto được gộp chung lại trong một multiple GRE tunnel, để phục vụ cho các luồng dữ liệu của branch. Mặt khác, để kết thúc tunnel VPN tại trung tâm, headend có thể gửi một thông điệp để báo cho giao thức định tuyến đang được sử dụng tại branch như EIGRP, OSPF, bất kể đường nào được chọn trong cloud (cloud path – đường kết nối giữa các router trong cloud). Dual Tier Với kiến trúc dual tier, mGRE và Crypto không cùng tồn tại trong cùng CPU của router. / Hình 1. 6: Dual Tier Headend Architecture Hình 1.6 là giải pháp dual DMVPN cloud với model hub-and-spoke. Ở đây mGRE và Crypto tại headend nằm riêng lẽ nhau nhau, chúng phục vụ cho nhau và cho multiple mGRE tunnel để chuyển luồng lưu lượng mạng cho branch. Đầu cuối của VPN tunnel, Crypto sẽ nhận dữ liệu gửi từ branch và sau đó chuyển tiếp cho mGRE, để mGRE quảng bá cho các giao thức định tuyến tại branch như EIGRP hoặc OSPF. Router trong tất cả các mô hình của DMVPN đóng vai trò là điểm kết thức của tunnel. Đồng thời nó còn kiêm theo nhiều chức năng khác như Firewall. Địa chỉ ip mặt ngoài của router có thể là tĩnh hoặc động, và nó phải được “map” trong bản đồ của router. Hành động này có nghĩa là: Một inteface mặt ngoài của router có địa chỉ ip public của riêng nó, và một tunnel cũng có ip (public hoặc private), nó phải ảnh xạ để biết tunnel này được chuyển ra interface tương ứng. Spoke-and-Spoke Cũng giống như Hub-and-spoke, trong model này cũng có hai Hub ở trung tâm, mỗi hub có một hoặc nhiều tunnel kết nối đến tất cả các chi nhánh. Giao tiếp giữa các Branch được thực hiện thông qua Hub, trừ khi nó có một đường kết nối được tạo ra giữa hai Spoke. Đó chính là sự khác biệt của trường hợp này. Tunnel giữa Spoke and Spoke được gọi là dynamic, nó phải nằm trong một single DMVPN cloud hoặc cùng một subnet. Tunnel của spoke-and-spoke thì không ở giữa hai DMVPN cloud. / Hình 1. 7: Dual DMVPN Cloud Topology—Spoke-to-Spoke Deployment Model Kiến trúc hệ thống trung tâm Các Branch trong kiểu triển khai này kết nối với nhau thông qua tunnel riêng, và phải đi qua DMVPN Cloud. Giao thức thường xuyên thấy giữa các tunnel này là IPSec. Để giao tiếp với hệ thống trung tâm, chúng ta có giao thức Single Tier, trong đó các chức năng của mGRE và Crypto được gói gọn trong một router. Single DMVPN Cloud Topology Trong mô hình này, có hai headend được sử dụng, nhưng chúng có cùng một subnet. Các văn phòng chi nhánh sẽ kết nối với trung tâm thông qua giao diện mGRE. Và chúng cũng phải có cùng subnet để thực hiện giao tiếp nội bộ. Mô hình này không được khuyến cáo vì chúng không khả dụng và không chống lỗi được. Với kiểu triển khai Spoke-and-Spoke thì việc triển khai theo Single DMVPN này cần được cân nhắc kỹ. Hai headend phải được cấu hình DMVPN giống nhau, có địa chỉ IP cùng một subnet. Khi đó chúng sẽ hổ trợ cho chúng ta chức năng load balanced giữa hai trung tâm. / Hình 1. 8 Single DMVPN Cloud Topology Tóm tắt Như vậy khi nhắc đến topology để triển khai cho giải pháp DMVPN, chúng ta có sự tóm tắt như sau: - Mô hình triển khai dành cho: Hub-and-Spoke: Giữa trung tâm và chi nhánh. Trong Hub-and-Spoke có hai kiến trúc dành cho cloud. Dual Cloud: Có nhiều subnet Single Cloud: Có một subnet Trong cả hai kiến trúc thì ở trung tâm (header) có thể triển khai theo hai giải pháp: Single Tier: hai giao thức mGRE và Crypto trên cùng một router. Dual Tier: hai giao thức mGRE và Crypto ở hai router khác nhau. Spoke-and-Spoke: giữa các chi nhánh với nhau Phần 2: Các vấn đề khi triển khai DMVPN Cơ chế tunnel và địa chỉ ip Bạn có thể đã nghe thấy ở đâu đó người ta nói rằng: “VPN tạo tunnel để kết nối giao tiếp lại”. Và bạn nhìn thấy một hình minh họa dưới đây: / Hình 2. 1: Mô hình VPN với cơ chế Tunnel Như vậy tunnel là một cơ chế, mà người ta gọi là đường ống, nó có chức năng che dấu đi dữ liệu A nào đó bằng một lớp dữ liệu B khác. Mô hình là vậy để chúng ta dễ hiễu, thực chất công việc này trong truyền thông là gắn thêm vào dữ liệu một header riêng, để biết rằng đó là gói dữ liệu theo định dạng của B. Nhìn vào mô hình minh họa này, chúng ta cũng thấy có một vấn để được đề cập đến chính là địa chỉ IP. Bản thân gói dữ liệu gửi từ A, đã có địa chỉ ip của riêng nó và của đích mà nó cần đến. Khi được tunnel hóa đi, nó mang thêm vào một địa chỉ ip nguồn và đích của tunnel. Người ta gọi đây là ip tunnel, và giao tiếp giữa hai ip tunnel này gọi là Tunnel Interface. Như vậy, giữa hai đầu của tunnel, về mặt luận lý, bạn có thể hiểu nó là một sợ cáp mạng nối hai điểm cần giao tiếp với nhau. / Hình 2. 2: Địa chỉ ip Mục đích của việc tạo tunnel là để che dấu địa chỉ ip private bằng địa chỉ ip public, từ đó giúp hai hệ thống mạng private có thể giao tiếp được với nhau. Tại đầu gửi, địa chỉ ip private nằm trong gói dữ liệu, được gói thành một gói dữ liệu mới (đúng hơn là gắn thêm header) mang địa chỉ ip public, và thông qua tunnel nó được gửi đến đầu nhận có địa chỉ ip public. Tại đầu nhận gói dữ liệu được tháo ra để lấy dữ liệu bên trong và trả vào cho mạng private. Giao thức GRE Làm thế nào để có được tunnel? Như đã đề cập, tunnel thực chất là gắn thêm một header theo định dạng quy định vào trong gói tin cần gửi. Như vậy định dạng quy định này là gì?. Câu trả lời rằng nó là những giao thức đóng gói dữ liệu trong tunnel. Một vài giao thức có thể kể tên như PPTP (Point-to-Point Tunneling Protocol), L2TP (Layer 2 Tunneling Protocol), L2F (Layer 2 Forwarding), GRE (Generic Routing Encapsulation). Tất cả giao thức này đều sẽ gắn vào gói tin cần gửi những dữ liệu của riêng nó, và phía đầu nhận phải hiểu để bóc gói (Discapsulation) cho đúng. Thế nhưng cả ba giao thức PPTP, L2TP và L2F đều vướng phải một vấn đề là không thể định tuyến. Khi cơ chế tunnel được tạo ra, hai site kết nối với nhau thì chúng có thể nằm trong cùng một mạng LAN, và phía sau chúng có thể là hàng loạt các mạng LAN khác. Hai router giữa vai trò đầu cuối của VPN (nơi tạo ra tunnel) phải chịu trách nhiệm gửi cập nhật định tuyến bên trong mạng cho nhau. Chúng ta đều biết rằng, cập nhật định tuyến này gửi theo broadcast, mà đa phần môi trường mạng public không cho phép gói tin broadcast đi qua. GRE sẽ giải quyết vấn đề này. GRE được dùng trong việc đóng gói định tuyến, dành cho môi trường mạng non-broadcast (mạng không cho phép broadcast). GRE cung cấp một cơ chế đóng gói tất cả các giao thức của tầng mạng, gửi đến cho những giao thức của tầng mạng khác. GRE sử dụng để truyền tải các gói tin IP từ mạng private này đến mạng private khác, thông qua internet. GRE tunnel cũng cho phép các giao thực định tuyến hoạt động khi nó chuyển tiếp từ mạng private đến các router khác trên mạng internet. GRE cũng đóng gói dữ liệu multicast để chuyển qua internet. GRE không cung cấp cơ chế mã hoá, do đó nó cần IPSEC để mã hoá dữ liệu trên đường truyền. Một gói tin khi cần chuyển ra mạng public thông qua GRE, nó sẽ được đóng gói theo chuẩn của GRE, bằng cách thêm vào GRE header, có độ dài 32 đến 160 bits. / Hình 2. 3: Ví dụ về GRE Triển khai GRE có hai giải pháp, giải pháp Point-to-Point (ppp GRE) và giải pháp Multi-Point (mGRE). Đối với mô hinh DMVPN Hub-and-Spoke thì mGRE được lựa chọn trong cấu hình. Giao thức NHRP Hai router (đã tạo tunnel) kết nối với nhau xem nhau như trong mạng LAN. Điều đầu tiên để gửi được dữ liệu giữa hai router này là xác định địa chỉ IP. Đứng ở khía cạnh người gửi tại 2 router, nó chỉ biết địa chỉ ip private. Công việc việc thứ hai là xác định với ip này thì MAC là bao nhiêu, bằng giao thức ARP. Tuy nhiên, giao thức ARP không thể hoạt động, vì ở đây đang dùng cơ chế tunnel, nó không cho phép gói tin của ARP chạy qua để tìm MAC. Vì thế NHRP (Next Hop Resolution Protocol) ra đời. NHRP là giao thức giống giao thức ARP (giao thức phân giải địa chỉ) làm giảm những vấn đề mạng NBMA (Non-Broadcast Multiple Access). Với NHRP, các hệ thống học địa chỉ của các hệ thống khác được cố định đến mạng NBMA một cách linh động. Cho phép các mạng này thông trực tiếp với nhau mà traffic được dùng không cần qua hop trung gian. NHRP được thiết kế để trợ giúp IP dò đường cho quá trình truyền khối dữ liệu trên hệ thống mạng NBMA. NHRP không phải là giao thức dò đường. Đó chỉ là một giải pháp kỹ thuật về địa chỉ để sắp xếp lại các địa chỉ của IP trong quá trình chuyển dữ liệu sang các địa chỉ kiểu. Mạng NBMA trái ngược lại với mạng phát tán. Trên hệ thống mạng phát tán, nhiều máy tính cũng như các thiết bị cùng dùng chung một cáp mạng hay các thiết bị truyền thông khác. Khi một máy tính truyền đi các frame thông tin, tất cả các nút trên mạng cùng “lắng nghe “ các frame, nhưng chỉ nút nào mà địa chỉ của nó được chỉ định trên frame mới thật sự nhận được các frame nầy. Bởi vậy, các frame gọi là được phát tán. Mạng kiểu NBMA sử dụng các mạch hướng kết nối để phân phối các frame hay cell từ đầu nầy đến đầu kia của mạch. Không có trạm nào khác liên quan đến mạch nầy ngoại trừ 2 nút cuối của nó. Các dịch vụ chuyển dữ liệu trong IP phi kết nối (connectionless) không phải luôn luôn phù hợp với các liên kết hướng kết nối của ATM. Tunnel Protection Mode Tiêu biểu vẫn là IPSec, chúng ta có thể cấu hình crypto theo kiểu dynamic hoặc static ở cả hai đầu router header và branch.Trong các phiên bản IOS 13 (hoặc lớn hơn) hổ trợ hầu hết các cấu hình của IPSec. Cũng từ phiên bản 13 này, khái niệm IPSec profile được giới thiệu. IPSec Profile được áp dụng cho hầu hết các kết nối, chúng ta không cần phải sử dụng nhiều ACL cho mỗi interface. Tuy nhiên, chỉ có những subnet nào được cấu hình giao tiếp và được phép giao tiếp với IPSec thì mới sử dụng được profile này. Sử dụng giao thức định tuyến Trong thiết kế của DMVPN khuyến cáo sử dụng các giao thức định tuyến động để định tuyến từ headen đến branch. Việc sử dụng các giao thức định tuyến động có nhiều lợi thế hơn đóng góp trực tuyến bằng IPSec (IPSec Direct Encapsulation). Trong VPN, giao thức định tuyến phải đảm bảo cùng một lợi ích so với mạng truyền thống, nó bao gồm: Thông tin về topology của mạng Thông báo thay đổi trong cấu trúc của topology Trạng thái điều khiển từ xa của mỗi đối tượng Một số giao thức định tuyến có thể được sử dụng trong một thiết kế DMVPN bao gồm EIGRP, OSPF, RIPv2, và ODR (chỉ dùng trong hub-and-spoke). Giao thức EIGRP được khuyến cáo sử dụng nhiều nhất, bởi vì giao thức định tuyến động này duy trì định tuyến theo chu kỳ của CPU và băng thông mạng, cũng như thời gian hội tụ nhanh chóng của nó. EIGRP cung cấp một loạt các tùy chọn để tổng hợp địa chỉ (summarization) và quảng bá định tuyến mặc định (default route). Các giao thức định tuyến như OSPF cũng đã được xác minh là dễ sử dụng, nhưng không được thảo luận rất chi tiết. ODR có thể không được sử dụng trong mô hình triển khai spoke-to-spoke vì ODR không hỗ trợ chia tách tunnel (split tunneling). Giao thức định tuyến động làm tăng việc sử dụng CPU trên thiết bị mạng, do đó tác động này phải được xem xét khi tăng kích thước mạng. Cân nhắc sử dụng Crypto IPSec hổ trợ hai cơ chế mã hóa là transport và tunnel. Với cơ chế transport thì chỉ mã hóa phần dữ liệu (payload), còn phần header có chứa địa nguồn và đích thì không được mã hóa. Với cơ chế tunnel thì cả phần dữ liệu và header đều được mã hóa, giúp bảo vệ thông tin trong phần header. Cơ chế transport còn thêm vào 20 byte đệm trong tổng kích thước gói tin. Cả hai cơ chế này đều được sử dụng để triển khai trong DMVPN. Nếu crypto tunnel được sử dụng cho NAT hoặc PAT thì bắt buộc phải dùng cơ chế tunnel. Mặc khác, trong triển khai DMVPN, nếu triển khai dual tier với cả GRE tunnel và crypto tunnel thì cũng bắt buộc phải dùng cơ chế tunnel trong IPSec. IKE Call Admission Control Trước đây phiên bản IOS 12.3 không có một chương trình nào điều khiển và giới hạn số lượng và tốc độ khởi tạo các yêu cầu chứng thực của ISAKMP (giao thức dùng đề quản lý khóa và khởi tạo kết nối), đều đó dẫn đến sự quá tải của router và làm tràn ngậm băng thông mạng. IKE Call Admission Control (CAC) được giới thiệu trong phiên bản 12.3 đã giới hạn được số lượng chứng thực của ISAKMP cho phép đến và đi từ một router. Bằng cách giới hạn số lượng crypto động được tạo ra, chúng ta có thể ngăn chặn không cho router bị tràn ngậm các yêu cầu ISAKMP được tạo ra. Việc giới hạn này còn phụ thuộc vào nền tản công nghệ, mô hình mạng, ứng dụng và luồng dữ liệu truyền tải qua mạng. Nếu bạn chỉ định một giới hạn IKE CAC ít hơn số lượng hiện tại của hoạt động IKE SA, một lời cảnh báo được hiển thị, nhưng ISAKMP SA không chấm dứt. Một yêu cầu ISAKMP SA mới bị từ chối cho đến khi bộ đếm ISAKMP SA hoạt động là dưới mức giới hạn cấu hình. CAC cung cấp hai phương pháp tiếp cận để hạn chế IKE SA có thể dùng để triển khai trong mạng DMVPN. Đầu tiên, CAC bình thường là một giám sát tài nguyên toàn cục, thăm dò phản hồi ​​để đảm bảo rằng tất cả các quá trình bao gồm IKE không làm quá tải CPU của router hoặc bộ nhớ đệm. Người dùng có thể cấu hình một giới hạn tài nguyên, đại diện bởi một tỷ lệ phần trăm tài nguyên hệ thống từ 0 đến 100. Nếu người dùng xác định một giới hạn tài nguyên là 90%, sau đó IKE CAC loại bỏ các yêu cầu ISAKMP SA hệ thống tiêu thụ đến 90% hiệu suất. Tính năng này rất có giá trị trên các bộ định tuyến headend, có thể phân loại và mã hóa các gói dữ liệu trong các công cụ mã hoá phần cứng với tốc độ dòng. Điều này hữu ích trên các bộ định tuyến khi triển khai theo mô hình hub-and-spoke, bởi vì các bộ định tuyến chi nhánh thường đạt ngưỡng trước khi được nạp đầy đủ với ISAKMP SA. Cách tiếp cận thứ hai cho phép người sử dụng cấu hình một giới hạn xác thực IKE ISAKMP SA (IKE CAC). Khi giới hạn này được đạt tới, IKE CAC loại bỏ tất cả các yêu cầu ISAKMP SA mới. Các Yêu cầu then chốt của IPsec SA lại luôn được cho phép vì để bảo tồn tính toàn vẹn của phiên hiện tại. Chức năng này chủ yếu nhắm vào các bộ định tuyến ở chi nhánh trong một mô hình triển khai spoke-to-spoke. Bằng cách cấu hình một giới hạn số lượng các dynamic tunnel có thể được tạo ra, người sử dụng có thể ngăn chặn một bộ định tuyến không bị tràn ngập nếu nó đột nhiên tràn ngập các yêu cầu SA. Ý tưởng CAC IKE phụ thuộc rất nhiều vào các nền tảng cụ thể và công nghệ crypto, cấu trúc liên kết mạng, và những thiết lập được triển khai. Tham khảo thêm về IKE CAC tại: Phần 3: Demo cấu hình Lab 1: IPsec + GRE Hub and Spoke Trong bài lab này chúng ta sử dụng mô hình mạng như sau: / Đây là kiến trúc Hub and Spoke, đơn hub nhiều DMVPN Cloud. Từ Hub kết nối đến các Spoke bằng những subnet khác nhau. Cấu hình Hub ! Khởi tạo cryto với khóa là cisco47 crypto isakmp policy 1 authentication pre-share crypto isakmp key 6 cisco47 address 0.0.0.0 0.0.0.0 ! ! Lựa chọn phương thức mã hóa là DES và MD5, tiếp cận theo kiểu transport crypto ipsec transform-set trans esp-des esp-md5-hmac mode transport !Tạo cryto map có tên là vpnmap1 crypto map vpnmap1 local-address FastEthernet1/0 crypto map vpnmap1 10 ipsec-isakmp set peer 172.17.0.2 set transform-set trans match address 101 crypto map vpnmap1 20 ipsec-isakmp set peer 172.17.0.3 set transform-set trans match address 102 !Tạo các tunnel để spoke giao tiếp interface Tunnel1 bandwidth 1000 ip address 10.0.0.1 255.255.255.252 ip mtu 1400 delay 1000 tunnel source FastEthernet1/0 tunnel destination 172.17.0.2 ! interface Tunnel2 bandwidth 1000 ip address 10.0.0.5 255.255.255.252 ip mtu 1400 delay 1000 tunnel source FastEthernet1/0 tunnel destination 172.17.0.3 !Cấu hình cho interface vật lý interface Loopback1 ip address 192.168.0.1 255.255.255.0 ! interface FastEthernet1/0 ip address 172.17.0.1 255.255.255.0 duplex auto speed auto crypto map vpnmap1 !Cấu hình định tuyến router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.0.0 no auto-summary !Cấu hình accesslist access-list 101 permit gre host 172.17.0.1 host 172.17.0.2 access-list 102 permit gre host 172.17.0.1 host 172.17.0.3 Spoke 1 crypto isakmp policy 1 authentication pre-share crypto isakmp key 6 cisco47 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set trans esp-des esp-md5-hmac mode transport ! crypto map vpnmap1 local-address FastEthernet1/0 crypto map vpnmap1 10 ipsec-isakmp set peer 172.17.0.1 set transform-set trans match address 101 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Tunnel0 bandwidth 1000 ip address 10.0.0.2 255.255.255.252 ip mtu 1400 delay 1000 tunnel source FastEthernet1/0 tunnel destination 172.17.0.1 ! interface FastEthernet1/0 ip address 172.17.0.2 255.255.255.0 duplex auto speed auto crypto map vpnmap1 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.1.0 no auto-summary ! access-list 101 permit gre host 172.17.0.2 host 172.17.0.1 Spoke 2 crypto isakmp policy 1 authentication pre-share crypto isakmp key 6 cisco47 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set trans esp-des esp-md5-hmac mode transport ! crypto map vpnmap1 local-address FastEthernet1/0 crypto map vpnmap1 10 ipsec-isakmp set peer 172.17.0.1 set transform-set trans match address 101 ! interface Loopback1 ip address 192.168.2.1 255.255.255.0 ! interface Tunnel0 bandwidth 100 ip address 10.0.0.6 255.255.255.252 ip mtu 1400 delay 1000 tunnel source FastEthernet1/0 tunnel destination 172.17.0.1 ! interface FastEthernet1/0 ip address 172.17.0.3 255.255.255.0 duplex auto speed auto crypto map vpnmap1 ! router eigrp 1 network 10.0.0.0 0.0.0.255 network 192.168.2.0 no auto-summary ! access-list 101 permit gre host 172.17.0.3 host 172.17.0.1 Kiểm tra Dùng lệnh show ip route trên Hub, chúng thấy rằng đã định tuyến cho mạng 192.168.1.0/24 và 192.168.2.0/24 qua interface là Tunnel1 10.0.0.2 và Tunnel2 10.0.0.6 HUB#show ip route [output cut] Gateway of last resort is not set 172.17.0.0/24 is subnetted, 1 subnets C 172.17.0.0 is directly connected, FastEthernet1/0 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.0 is directly connected, Tunnel1 C 10.0.0.4 is directly connected, Tunnel2 C 192.168.0.0/24 is directly connected, Loopback1 D 192.168.1.0/24 [90/2944000] via 10.0.0.2, 00:17:21, Tunnel1 D 192.168.2.0/24 [90/2944000] via 10.0.0.6, 00:17:19, Tunnel2 Tương tự như vậy các định tuyến trên Spoke2 và Spoke1 cũng qua hai địa chỉ ip của tunnel. SPOKE1#show ip route [output cut] Gateway of last resort is not set 172.17.0.0/24 is subnetted, 1 subnets C 172.17.0.0 is directly connected, FastEthernet1/0 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.0 is directly connected, Tunnel0