KIẾN TRÚC BẢO MẬT MPLS
2.1 Tách biệt không gian địa chỉ
Để phân biệt được không gian địa chỉ giữa các VPN khác nhau, MPLS không sử dụng địa chỉ Ipv4 (hoặc Ipv6) trên mặt phẳng điều khiển. Thay vào đó, đưa ra khái niệm địa chỉ VPN-Ipv4 hoặc VPN-Ipv6. Một địa chỉ VPN-Ipv4 bao gồm 8 byte RD (Route Distinguisher) tiếp theo là 4 byte địa chỉ Ipv4. Được minh họa trong hình[]. Tương tự, một địa chỉ VPN-Ipv6 gồm 8 byte cho trường RD theo sau là 16 byte cho địa chỉ Ipv6. [Hình 5]
Mục đích của RD là cho phép toàn bộ không gian địa chỉ Ipv4 được sử dụng trong những mục đích khác nhau. Trên router, một RD có thể định nghĩa một tuyến VPN. Do kiến trúc của MPLS IP VPN, chỉ có các router PE mới biết những tuyến VPN. Do đó các router PE sử dụng địa chỉ VPN-Ipv4 để phân biệt giữa các VPN, và cũng để phân biệt giữa không gian địa chỉ của mạng lõi (mạng lõi sử dụng địa chỉ IP thuần túy trên mặt phẳng điều khiển). [Hình 6] minh họa không gian địa chỉ khác nhau được sử dụng cho một mạng lõi MPLS IP VPN.
2.2 Tách biệt lưu lượng
Lưu lượng VPN bao gồm lưu lượng trên mặt phẳng dữ liệu và mặt phẳng điều khiển VPN. Đối với người sử dụng thì lưu lượng VPN của họ không được trộn lẫn (mix) với lưu lượng của người sử dụng khác hoặc với lưu lượng của mạng lõi. Lưu lượng VPN được đóng gói trong một LSP và gởi từ PE đến PE, do đó mạng lõi không
bao giờ nhìn thấy lưu lượng VPN. [Hình 7] minh họa những loại lưu lượng khác nhau trên mạng lõi MPLS.
Mỗi giao tiếp chỉ có thể thuộc về một VRF (Virtual Routing Forwarding) tùy thuộc vào cấu hình trên nó. Ví dụ: VPN khách hàng có tên là “red” được kết nối tới PE trên giao diện Fast Ethernet. Lệnh ip vrf forwarding xác định VRF. [Hình 8] minh họa cấu hình này.
Tách biệt lưu lượng trên router PE được thực thi dựa vào loại giao tiếp đối với những gói đến rotouter.
- Non – VRF interface: Nếu những gói vào interface được kết hợp với bảng định tuyến toàn cục (không dùng lệnh ip vrf forwarding) thì việc chuyển tiếp được quyết định dựa trên bảng định tuyến toàn cục, và gói này được xử lý như gói IP bình thường. Chỉ có lưu lượng lõi mới sử dụng non-vrf interface.
- VRF interface: Nếu gói vào một interface được liên kết với một VRF dùng lệnh ip vrf forwarding thì việc chuyển tiếp được quyết định bảng chuyển tiếp (hay cơ sở thông tin chuyển tiếp FIB - Forwarding Information Base) của VRF đó. Chặng kế của router luôn trỏ đến router khác, và những mục trong bảng FIB chứa cách thức đóng gói cho những gói trên mạng lõi.
Sự tách biệt lưu lượng giữa các VNP khác nhau được thực hiện bằng cách đóng gói những gói nhận được với trường header cụ thể. Có những lựa chọn khác nhau cho cách đóng gói và chuyển tiếp những gói VPN trên lõi – qua 1 LSP (Label Switch Path), một đường ống IPsec, một đường ống GRE (Generic Routing Encapsulation),… Tất cả các phương thức này nhầm mục đích là tạo ra sự tách biệt lưu lượng giữa các VPN. [Hình 9] sau đây chỉ cách đóng gói trên mạng lõi.
Router P không có vai trò chủ động trong việc giữ lưu lượng từ các VPN tách biệt mà chúng chỉ kết nối các router PE lại với nhau qua các LSP hoặc bằng những phương thức khác được mô tả ở trên. Một trong những chìa khóa thuận lợi của kiến trúc MPLS VPN là các router P không giữ thông tin VPN. Điều này hỗ trợ tính mềm dẻo của mạng lõi và giúp cho mạng lõi bảo mật hơn vì mạng lõi được che dấu.
Tóm lại người dùng VPN có thể yên tâm rằng lưu lượng của họ được tách biệt đối với lưu lượng của người dùng khác và mạng lõi vì:
- Một interface trên một PE chỉ có thể thuộc vào một VRF đơn hoặc lõi.
- Liên kết giữa PE – CE trên interface này tùy thuộc vào VPN luận lý của người dùng. Nghĩa là các VPN khác không thể truy cập tới nó.
- Trên PE, thông tin địa chỉ của VPN thì được giữ như là địa chỉ VPN-IPv4, mỗi VPN điều được phân biệt duy nhất qua trường RD (Route Distinguisher). Địa chỉ VPN-IPv4 chỉ được lưu giữ trên các router PE để ánh xạ các tuyến.
Nhà cung cấp dịch vụ SP (Service Provider) có thể mông đợi mạng lõi của họ tách biệt với VPN người dùng vì: địa chỉ sử dụng giữa PE và P là địa chỉ IPv4 còn các VPN thì sử dụng địa chỉ VPN-IPv4, do đó không thể truy cập đến các router PE và P.
Sau đây là một số mô hình phổ biến minh họa sự tách biệt lưu lượng:
+ Tách biệt hoàn toàn giữa VPN và truy cập internet cho một site đơn
Truy cập VPN và internet là hoàn toàn tách biệt. [Hình 10] minh họa về sự tách biệt. Ưu điểm của việc tách biệt này là chống lại tấn DoS. Ngay cả nếu doanh nghiệp là đích đến của các cuộc tấn công DoS dựa trên dịch vụ internet thì dịch vụ VPN vẫn không bị ảnh hưởng. Bất lợi của tùy chọn này là làm tăng chi phí cho doanh nghiệp, cần cung cấp và duy trì nhiều đường tách biệt và router phục vụ cho việc truy cập VPN và internet.
+ Truy cập internet và VPN đều hội tụ ở nhà cung cấp dịch vụ
Một vài nhà cung cấp dịch vụ cung cấp truy cập internet và VPN có điểm hội tụ tài biên nhà cung cấp (ranh giới giữa nhà cung cấp và khách hàng). Với một router đơn ở phía nhà cung có thể ánh xạ 2 dịch vụ tách biệt là truy cập VPN và internet. Trong kiến trúc này, lưu lượng VPN và internet được xử lý tại router biên của nhà cung cấp. Nếu nhìn theo mức luận lý thì 2 dịch vụ sẽ được kết nối tới 2 router biên, mỗi router phục vụ cung cấp một dịch vụ. Nhưng ở mức vật lý thì chỉ có một router chịu trách nhiệm ánh xạ các interface để phân biệt các dịch vụ khác nhau. Điều này sẽ giảm bớt những đợt tấn công DoS từ bên ngoài, vì nếu ta giảm bớt được kết nối vật lý thì nguy cơ tấn công cũng giảm, và với sự tách biệt biệt hoàn toàn đó thì thiết lập luật chống lại các cuộc tấn giữa 2 loại lưu lượng cũng dễ dàng hơn.[Hình 11]
+ Một đường đơn (single line) phục vụ cho 2 dịch vụ VPN và internet
Với mô hình này thì chi phí sẽ giảm đi rất nhiều. Vì chúng ta biết rằng số giao diện trên thiết bị kết nối trong mạng WAN tỉ lệ thuật với chi phí cho thiết bị đó nên giảm số cổng vật lý cũng giảm chi phí đáng kể. Nhưng có điều bất lợi là hiệu suất thực thi của thiết bị đó sẽ giảm đi, vì nó phải xử lý nhiều việc nên phần nào tốc độ về xử lý cũng giảm xuống.
Để có thể phân biệt được các dịch vụ ở mức luận lý (logic) thì các giao tiếp này phải được cấu hình các giao tiếp phụ/con (subinterface) trên cả router CE và PE. Mỗi subinterface tương ứng phục vụ cho một dịch vụ. [Hình 12]
Comment