Tweet
Tại sao Cisco lại mã hóa Underlay thay vì Overlay? Khám phá kiến trúc Secure Underlay with IPsec
Trong nhiều năm, khi nhắc đến bảo mật cho các mạng Overlay như VXLAN hay EVPN, phần lớn kỹ sư mạng thường nghĩ đến việc mã hóa chính các đường hầm Overlay. Tuy nhiên, Cisco đang theo đuổi một hướng tiếp cận khác: bảo vệ toàn bộ lớp Underlay bằng IPsec.
Thoạt nhìn, điều này có vẻ trái ngược với cách triển khai VPN truyền thống. Nhưng khi phân tích sâu hơn, đây là một kiến trúc rất hợp lý, đặc biệt đối với các Campus Fabric, SD-Branch và Hybrid Cloud hiện đại.
Ý tưởng cốt lõi
Hãy quan sát sơ đồ.
Trụ sở chính (Headquarter) kết nối với nhiều chi nhánh thông qua Internet hoặc Public/Private Cloud. Các Catalyst 9300X/9400X tại trung tâm và Catalyst 9350 tại chi nhánh thiết lập các đường hầm IPsec Tunnel Mode trực tiếp với nhau.
Bên trên lớp Underlay đã được mã hóa này là Overlay Fabric, nơi các giao thức như VXLAN EVPN hoặc các dịch vụ Layer 3 hoạt động bình thường.
Nói cách khác:
Đây là sự phân tách rất rõ giữa hai lớp chức năng:
Vì sao mã hóa Underlay lại có nhiều ưu điểm?
Nếu mã hóa trực tiếp từng Overlay Tunnel, mỗi dịch vụ hoặc mỗi Overlay có thể phải xử lý việc bảo mật riêng.
Ngược lại, khi Underlay đã được mã hóa, toàn bộ lưu lượng phía trên đều tự động được bảo vệ.
Bao gồm:
Tất cả đều truyền qua cùng một hạ tầng IPsec an toàn.
Điều này giúp giảm đáng kể độ phức tạp trong vận hành và cấu hình.
Tunnel Mode và ESP
Trong kiến trúc này, Cisco sử dụng:
Tunnel Mode đóng gói toàn bộ gói IP gốc vào bên trong một gói IP mới trước khi mã hóa. Vì vậy, cả địa chỉ IP nguồn và đích của gói tin gốc đều được bảo vệ khỏi người quan sát trên mạng trung gian.
Đây là chế độ được sử dụng gần như mặc định cho các kết nối Site-to-Site VPN.
ESP là thành phần chịu trách nhiệm:
Khác với AH (Authentication Header), ESP còn cung cấp khả năng mã hóa nên trở thành lựa chọn phổ biến trong hầu hết các triển khai IPsec hiện đại.
IKEv2 – Trái tim của IPsec
Mọi đường hầm đều được thiết lập thông qua IKEv2.
IKEv2 đảm nhiệm các công việc:
So với IKEv1, IKEv2 có quá trình bắt tay (handshake) đơn giản hơn, phục hồi kết nối nhanh hơn và hoạt động hiệu quả hơn trong môi trường có NAT.
AES-GCM đang dần thay thế AES-CBC
Slide cho thấy Cisco hỗ trợ:
Đây là một chi tiết rất đáng chú ý.
Trong quá khứ, AES-CBC gần như là lựa chọn mặc định. Tuy nhiên, CBC chỉ thực hiện chức năng mã hóa, vì vậy cần kết hợp thêm HMAC để đảm bảo tính toàn vẹn của dữ liệu.
Ngược lại, AES-GCM thuộc nhóm thuật toán Authenticated Encryption with Associated Data (AEAD). Nó kết hợp cả mã hóa và xác thực trong cùng một thuật toán, giúp:
Chính vì vậy, AES-GCM hiện được xem là lựa chọn ưu tiên trong các thiết kế IPsec mới.
Tại sao Cisco sử dụng Static Virtual Tunnel Interface (SVTI)?
Một điểm khác biệt lớn của kiến trúc này là Cisco không còn sử dụng Crypto Map truyền thống.
Thay vào đó là Static Virtual Tunnel Interface (SVTI).
Mỗi đường hầm IPsec xuất hiện như một interface Layer 3 thông thường.
Điều này mang lại rất nhiều lợi ích:
OSPF và BGP chỉ đơn giản xem Tunnel Interface như một liên kết Layer 3 bình thường.
Không cần thêm GRE để vận chuyển các gói tin định tuyến như trong nhiều thiết kế IPsec trước đây.
Hỗ trợ đầy đủ IPv4, IPv6 và VRF
Giải pháp không chỉ hỗ trợ IPv4 mà còn hỗ trợ IPv6 ngay từ lớp Underlay.
Ngoài ra, IPsec còn VRF Aware, nghĩa là mỗi VRF có thể sở hữu các đường hầm IPsec riêng biệt.
Đây là tính năng rất quan trọng trong các môi trường:
Nhờ đó, mỗi miền định tuyến vẫn được cách ly hoàn toàn dù cùng sử dụng chung hạ tầng vật lý.
Multicast và NAT đều được hỗ trợ
Một ưu điểm khác là giải pháp vẫn hỗ trợ Multicast Routing.
Điều này đặc biệt hữu ích đối với:
Trong khi đó, NAT Traversal (NAT-T) giúp IPsec hoạt động ổn định khi một hoặc cả hai đầu kết nối nằm phía sau thiết bị NAT.
ESP sẽ được đóng gói vào UDP cổng 4500 để vượt qua NAT mà không làm gián đoạn đường hầm.
Phần cứng tăng tốc mã hóa
Cisco nhấn mạnh khả năng triển khai trên:
Các nền tảng này tích hợp Crypto Hardware Acceleration, cho phép xử lý IPsec trực tiếp trên phần cứng thay vì phụ thuộc hoàn toàn vào CPU.
Nhờ đó, hệ thống vẫn duy trì thông lượng cao ngay cả khi toàn bộ lưu lượng WAN đều được mã hóa.
Đây là yếu tố quan trọng khi triển khai các Campus Fabric hoặc SD-Branch với hàng nghìn người dùng và lưu lượng lớn.
Một Fabric thống nhất từ Campus đến WAN
Điểm đáng chú ý nhất của kiến trúc này là khả năng mở rộng Fabric vượt ra ngoài phạm vi một tòa nhà hay một trung tâm dữ liệu.
Cisco cho phép hình thành một Fabric Cluster trải rộng qua WAN, trong đó các chi nhánh có thể tham gia vào cùng một miền Fabric với trụ sở chính. Ngoài ra, kiến trúc còn hỗ trợ "stitch" – tức kết nối liền mạch Fabric WAN với EVPN Fabric tại Data Center.
Kết quả là doanh nghiệp có thể xây dựng một hạ tầng thống nhất từ Campus, WAN đến Data Center mà vẫn duy trì khả năng mã hóa, phân đoạn mạng và định tuyến nhất quán.
Kết luận
Thay vì chỉ xem IPsec là một công nghệ VPN kết nối Site-to-Site, Cisco đã đưa IPsec trở thành lớp bảo mật nền tảng cho toàn bộ Underlay. Khi mọi kết nối giữa các nút Fabric đều được mã hóa, các dịch vụ Overlay như VXLAN, EVPN, OSPF hay BGP có thể hoạt động phía trên một hạ tầng truyền tải an toàn, trong suốt và thống nhất.
Đây là một cách tiếp cận phù hợp với xu hướng Zero Trust, nơi mọi kết nối giữa các thiết bị mạng đều được xác thực và mã hóa, bất kể chúng đi qua mạng riêng, Internet hay hạ tầng Public Cloud. Đối với các doanh nghiệp đang triển khai Campus Fabric, SD-Branch hoặc Hybrid Cloud, Secure Underlay with IPsec không chỉ tăng cường bảo mật mà còn đơn giản hóa thiết kế và vận hành, tạo nền tảng vững chắc để mở rộng mạng lưới trong tương lai.
Trong nhiều năm, khi nhắc đến bảo mật cho các mạng Overlay như VXLAN hay EVPN, phần lớn kỹ sư mạng thường nghĩ đến việc mã hóa chính các đường hầm Overlay. Tuy nhiên, Cisco đang theo đuổi một hướng tiếp cận khác: bảo vệ toàn bộ lớp Underlay bằng IPsec.
Thoạt nhìn, điều này có vẻ trái ngược với cách triển khai VPN truyền thống. Nhưng khi phân tích sâu hơn, đây là một kiến trúc rất hợp lý, đặc biệt đối với các Campus Fabric, SD-Branch và Hybrid Cloud hiện đại.
Ý tưởng cốt lõi
Hãy quan sát sơ đồ.
Trụ sở chính (Headquarter) kết nối với nhiều chi nhánh thông qua Internet hoặc Public/Private Cloud. Các Catalyst 9300X/9400X tại trung tâm và Catalyst 9350 tại chi nhánh thiết lập các đường hầm IPsec Tunnel Mode trực tiếp với nhau.
Bên trên lớp Underlay đã được mã hóa này là Overlay Fabric, nơi các giao thức như VXLAN EVPN hoặc các dịch vụ Layer 3 hoạt động bình thường.
Nói cách khác:
IPsec bảo vệ hạ tầng truyền tải (Underlay), còn Overlay chỉ tập trung cung cấp dịch vụ mạng.
Đây là sự phân tách rất rõ giữa hai lớp chức năng:
- Underlay chịu trách nhiệm kết nối và bảo mật.
- Overlay chịu trách nhiệm ảo hóa mạng và cung cấp dịch vụ.
Vì sao mã hóa Underlay lại có nhiều ưu điểm?
Nếu mã hóa trực tiếp từng Overlay Tunnel, mỗi dịch vụ hoặc mỗi Overlay có thể phải xử lý việc bảo mật riêng.
Ngược lại, khi Underlay đã được mã hóa, toàn bộ lưu lượng phía trên đều tự động được bảo vệ.
Bao gồm:
- VXLAN
- EVPN
- OSPF
- BGP
- PIM
- IPv4
- IPv6
- Multicast
Tất cả đều truyền qua cùng một hạ tầng IPsec an toàn.
Điều này giúp giảm đáng kể độ phức tạp trong vận hành và cấu hình.
Tunnel Mode và ESP
Trong kiến trúc này, Cisco sử dụng:
- IPsec Tunnel Mode
- ESP (Encapsulating Security Payload)
- IKEv2
Tunnel Mode đóng gói toàn bộ gói IP gốc vào bên trong một gói IP mới trước khi mã hóa. Vì vậy, cả địa chỉ IP nguồn và đích của gói tin gốc đều được bảo vệ khỏi người quan sát trên mạng trung gian.
Đây là chế độ được sử dụng gần như mặc định cho các kết nối Site-to-Site VPN.
ESP là thành phần chịu trách nhiệm:
- Mã hóa dữ liệu
- Đảm bảo tính toàn vẹn
- Xác thực nguồn gửi
- Chống tấn công Replay
Khác với AH (Authentication Header), ESP còn cung cấp khả năng mã hóa nên trở thành lựa chọn phổ biến trong hầu hết các triển khai IPsec hiện đại.
IKEv2 – Trái tim của IPsec
Mọi đường hầm đều được thiết lập thông qua IKEv2.
IKEv2 đảm nhiệm các công việc:
- Xác thực hai đầu kết nối
- Thương lượng thuật toán mã hóa
- Sinh và trao đổi khóa
- Thiết lập Security Association (SA)
- Gia hạn khóa khi cần
So với IKEv1, IKEv2 có quá trình bắt tay (handshake) đơn giản hơn, phục hồi kết nối nhanh hơn và hoạt động hiệu quả hơn trong môi trường có NAT.
AES-GCM đang dần thay thế AES-CBC
Slide cho thấy Cisco hỗ trợ:
- AES-128-CBC
- AES-128-GCM
- AES-256-GCM
Đây là một chi tiết rất đáng chú ý.
Trong quá khứ, AES-CBC gần như là lựa chọn mặc định. Tuy nhiên, CBC chỉ thực hiện chức năng mã hóa, vì vậy cần kết hợp thêm HMAC để đảm bảo tính toàn vẹn của dữ liệu.
Ngược lại, AES-GCM thuộc nhóm thuật toán Authenticated Encryption with Associated Data (AEAD). Nó kết hợp cả mã hóa và xác thực trong cùng một thuật toán, giúp:
- Giảm số bước xử lý
- Tăng hiệu năng
- Giảm tải CPU
- Phù hợp với các nền tảng có phần cứng tăng tốc mã hóa
Chính vì vậy, AES-GCM hiện được xem là lựa chọn ưu tiên trong các thiết kế IPsec mới.
Tại sao Cisco sử dụng Static Virtual Tunnel Interface (SVTI)?
Một điểm khác biệt lớn của kiến trúc này là Cisco không còn sử dụng Crypto Map truyền thống.
Thay vào đó là Static Virtual Tunnel Interface (SVTI).
Mỗi đường hầm IPsec xuất hiện như một interface Layer 3 thông thường.
Điều này mang lại rất nhiều lợi ích:
- Dễ cấu hình
- Dễ giám sát
- Dễ troubleshoot
- Chạy trực tiếp các giao thức định tuyến
OSPF và BGP chỉ đơn giản xem Tunnel Interface như một liên kết Layer 3 bình thường.
Không cần thêm GRE để vận chuyển các gói tin định tuyến như trong nhiều thiết kế IPsec trước đây.
Hỗ trợ đầy đủ IPv4, IPv6 và VRF
Giải pháp không chỉ hỗ trợ IPv4 mà còn hỗ trợ IPv6 ngay từ lớp Underlay.
Ngoài ra, IPsec còn VRF Aware, nghĩa là mỗi VRF có thể sở hữu các đường hầm IPsec riêng biệt.
Đây là tính năng rất quan trọng trong các môi trường:
- Multi-Tenant
- EVPN
- SDA Fabric
- MPLS VPN
- Hybrid Cloud
Nhờ đó, mỗi miền định tuyến vẫn được cách ly hoàn toàn dù cùng sử dụng chung hạ tầng vật lý.
Multicast và NAT đều được hỗ trợ
Một ưu điểm khác là giải pháp vẫn hỗ trợ Multicast Routing.
Điều này đặc biệt hữu ích đối với:
- IPTV
- Video Distribution
- PIM
- Các ứng dụng yêu cầu truyền multicast qua WAN
Trong khi đó, NAT Traversal (NAT-T) giúp IPsec hoạt động ổn định khi một hoặc cả hai đầu kết nối nằm phía sau thiết bị NAT.
ESP sẽ được đóng gói vào UDP cổng 4500 để vượt qua NAT mà không làm gián đoạn đường hầm.
Phần cứng tăng tốc mã hóa
Cisco nhấn mạnh khả năng triển khai trên:
- Catalyst 9300X
- Catalyst 9400X
- Cisco Catalyst 9350
Các nền tảng này tích hợp Crypto Hardware Acceleration, cho phép xử lý IPsec trực tiếp trên phần cứng thay vì phụ thuộc hoàn toàn vào CPU.
Nhờ đó, hệ thống vẫn duy trì thông lượng cao ngay cả khi toàn bộ lưu lượng WAN đều được mã hóa.
Đây là yếu tố quan trọng khi triển khai các Campus Fabric hoặc SD-Branch với hàng nghìn người dùng và lưu lượng lớn.
Một Fabric thống nhất từ Campus đến WAN
Điểm đáng chú ý nhất của kiến trúc này là khả năng mở rộng Fabric vượt ra ngoài phạm vi một tòa nhà hay một trung tâm dữ liệu.
Cisco cho phép hình thành một Fabric Cluster trải rộng qua WAN, trong đó các chi nhánh có thể tham gia vào cùng một miền Fabric với trụ sở chính. Ngoài ra, kiến trúc còn hỗ trợ "stitch" – tức kết nối liền mạch Fabric WAN với EVPN Fabric tại Data Center.
Kết quả là doanh nghiệp có thể xây dựng một hạ tầng thống nhất từ Campus, WAN đến Data Center mà vẫn duy trì khả năng mã hóa, phân đoạn mạng và định tuyến nhất quán.
Kết luận
Thay vì chỉ xem IPsec là một công nghệ VPN kết nối Site-to-Site, Cisco đã đưa IPsec trở thành lớp bảo mật nền tảng cho toàn bộ Underlay. Khi mọi kết nối giữa các nút Fabric đều được mã hóa, các dịch vụ Overlay như VXLAN, EVPN, OSPF hay BGP có thể hoạt động phía trên một hạ tầng truyền tải an toàn, trong suốt và thống nhất.
Đây là một cách tiếp cận phù hợp với xu hướng Zero Trust, nơi mọi kết nối giữa các thiết bị mạng đều được xác thực và mã hóa, bất kể chúng đi qua mạng riêng, Internet hay hạ tầng Public Cloud. Đối với các doanh nghiệp đang triển khai Campus Fabric, SD-Branch hoặc Hybrid Cloud, Secure Underlay with IPsec không chỉ tăng cường bảo mật mà còn đơn giản hóa thiết kế và vận hành, tạo nền tảng vững chắc để mở rộng mạng lưới trong tương lai.
Attached Files