Mạng lưới định tuyến Internet toàn cầu vận hành dựa trên giao thức BGP (Border Gateway Protocol). Mỗi giây trôi qua, hơn một trăm nghìn Hệ tự trị (Autonomous System - AS) liên tục trao đổi các bản tin định tuyến để xác định cách các gói tin IP đi qua các nhà mạng trung gian nhằm tới đích đến. Trong nhiều thập kỷ, mô hình định tuyến phân tán này hoạt động dựa trên sự tin tưởng ngầm định giữa các kỹ sư mạng. Bất kỳ nhà vận hành mạng nào cũng có thể công bố các dải tiền tố IP hoặc đường dẫn trung chuyển mà không cần bằng chứng toán học chứng minh quyền hạn.

Việc triển khai Hạ tầng khóa công khai tài nguyên (RPKI) cùng cơ chế Xác thực nguồn gốc lộ trình (Route Origin Validation - ROV, quy định tại RFC 6811) đã đánh dấu bước tiến lớn trong nỗ lực bảo vệ định tuyến Internet. ROV cho phép các nhà mạng kiểm tra xem Hệ tự trị đang quảng bá một dải tiền tố IP có thực sự được ủy quyền thông qua đối tượng ủy quyền nguồn gốc ROA (Route Origin Authorization) hay không.

Dẫu vậy, ROV tồn tại một điểm mù mang tính cấu trúc: cơ chế này chỉ kiểm tra duy nhất Hệ tự trị nguồn gốc (AS nằm ở ngoài cùng bên phải trong thuộc tính AS_PATH của BGP). ROV hoàn toàn không thể xác thực xem chuỗi các Hệ tự trị trung gian vận chuyển gói tin có phải là đường dẫn trung chuyển hợp lệ hay không. Những kẻ tấn công hoặc các mạng bị cấu hình sai có thể tự ý chèn thêm các nút mạng trên đường đi, hoặc gây ra hiện tượng rò rỉ lộ trình BGP nghiêm trọng, âm thầm bẻ hướng luồng lưu lượng quốc tế đi qua các nhà mạng nước ngoài không mong muốn.

Để khắc phục lỗ hổng này, nhóm đặc trách kỹ thuật Internet (IETF) đã chuẩn hóa cơ chế ASPA (Autonomous System Provider Authorization - Ủy quyền nhà cung cấp Hệ tự trị) theo tiêu chuẩn RFC 9319 và các đặc tả SIDROPS liên quan. ASPA mang đến giải pháp xác thực mật mã học cho các chặng BGP trung gian, triệt tiêu tận gốc hiện tượng rò rỉ lộ trình và giả mạo đường dẫn trên các mạng viễn thông toàn cầu.

+-------------------------------------------------------------------------+
|                KHOẢNG TRỐNG TOÀN VẸN ĐƯỜNG DẪN BGP: ROV VÀ ASPA         |
+-------------------------------------------------------------------------+
|                                                                         |
|  Dải IP: 198.51.100.0/24   AS gốc sở hữu: AS65001                       |
|                                                                         |
|  Bản tin BGP AS_PATH lan truyền trên mạng:                             |
|  [Nhà mạng Tier-1 AS100] -> [AS200 rò rỉ trái phép] -> [Khách AS65001] |
|                                                                         |
|  1. Xác thực nguồn gốc ROV:                                             |
|     - Chỉ nhìn vào duy nhất AS65001 ở cuối chặng.                       |
|     - Khớp dải IP trong chứng thư ROA -> Trạng thái: HỢP LỆ (VALID)!    |
|     - Hệ quả: ROV hoàn toàn mù trước việc AS200 có được phép hay không! |
|                                                                         |
|  2. Cơ chế xác thực ASPA:                                               |
|     - Kiểm tra quan hệ khách hàng - nhà cung cấp trên từng chặng.       |
|     - Đối chiếu xem AS65001 có ủy quyền cho AS200 làm nhà cung cấp?    |
|     - Phát hiện trung chuyển trái phép / vi phạm quy tắc valley-free!   |
|     - Trạng thái: INVALID -> Loại bỏ lộ trình rò rỉ ngay ngoài cửa ngõ! |
+-------------------------------------------------------------------------+

Giới hạn của cơ chế xác thực nguồn gốc (ROV)

Để hiểu rõ vì sao ASPA lại mang tính sống còn, cần phân tích những phạm vi mà ROV bảo vệ được và chưa bảo vệ được. Khi một mạng xuất bản một bản ghi ROA trong kho dữ liệu RPKI, đối tượng mật mã này sẽ liên kết chặt chẽ một dải tiền tố IP (chẳng hạn 203.0.113.0/24) kèm theo độ dài tiền tố tối đa cho phép với số hiệu AS nguồn gốc được ủy thác (ví dụ AS64496).

Khi bộ định tuyến biên nhận được một bản tin cập nhật lộ trình BGP, ROV sẽ tiến hành kiểm tra hai điều kiện:

  1. Tiền tố IP và độ dài tiền tố được công bố có nằm trong giới hạn của bản ghi ROA đã ký số hay không?
  2. Số hiệu AS nằm ở cuối cùng bên phải của chuỗi AS_PATH có trùng khớp với AS được ghi nhận trong ROA không?

Nếu cả hai điều kiện thỏa mãn, lộ trình được đánh dấu là Valid. Nếu một AS lạ mạo danh quảng bá dải IP đó, lộ trình sẽ bị gắn nhãn Invalid và lập tức bị từ chối.

Tuy nhiên, ROV không hề xác thực các AS đứng trước AS gốc. Một kẻ tấn công hoặc một doanh nghiệp kết nối đa nhà mạng (multihomed) bị lỗi cấu hình có thể tạo ra một bản tin BGP trong đó AS nguồn gốc hoàn toàn chính xác, nhưng đường dẫn trung chuyển bị xáo trộn. Một mạng trung gian có thể chen ngang vào chuỗi đường dẫn, hoặc một nhà mạng có thể nhận lộ trình từ một đối tác ngang hàng rồi quảng bá sai quy định sang đối tác khác, gây xung đột chính sách thương mại và chặn bắt lưu lượng mà không hề kích hoạt cảnh báo lỗi của ROV.

Bản chất của sự cố rò rỉ lộ trình BGP (RFC 7908)

Tiêu chuẩn RFC 7908 định nghĩa rò rỉ lộ trình BGP là sự lan truyền các bản tin định tuyến vượt ra ngoài phạm vi dự kiến ban đầu. Trong định tuyến liên miền, mối quan hệ thương mại giữa các Hệ tự trị thường tuân theo mô hình cổ điển của Lixin Gao và Jennifer Rexford (mô hình Gao-Rexford):

  • Khách hàng tới Nhà cung cấp (Customer-to-Provider): Khách hàng trả phí cho nhà cung cấp để mua quyền trung chuyển Internet toàn cầu.
  • Nhà cung cấp tới Khách hàng (Provider-to-Customer): Nhà cung cấp chuyển tiếp dữ liệu đến và đi cho các khách hàng trả phí của mình.
  • Ngang hàng (Peer-to-Peer): Hai nhà mạng trao đổi dữ liệu qua lại nhằm phục vụ khách hàng của đôi bên mà không thu phí trung chuyển của nhau.

Theo quy tắc thương mại thông thường, đường đi định tuyến bắt buộc phải tuân thủ nguyên lý không thung lũng (valley-free). Một mạng không bao giờ được cung cấp dịch vụ trung chuyển miễn phí giữa hai nhà cung cấp của mình, hoặc giữa hai đối tác kết nối ngang hàng. Một khi lộ trình định tuyến đã đi xuống một chặng (từ nhà cung cấp xuống khách hàng, hoặc giữa hai bên ngang hàng), nó không bao giờ được phép đi ngược lên một nhà cung cấp hoặc bên ngang hàng khác.

+-----------------------------------------------------------------------+
|                    VI PHẠM NGUYÊN TẮC ĐỊNH TUYẾN VALLEY-FREE          |
+-----------------------------------------------------------------------+
|        [Nhà mạng quốc tế A]                [Nhà mạng quốc tế B]       |
|                 │                                   ▲                 |
|                 │ (Từ Nhà cung cấp xuống)           │ (LỘ TRÌNH RÒ RỈ)|
|                 ▼                                   │                 |
|      +---------------------------------------------------------+      |
|      |               Doanh nghiệp đa nhà mạng AS300            |      |
|      |    Vô tình quảng bá lại lộ trình học được từ mạng A     |      |
|      |    thẳng sang cổng kết nối của nhà mạng B!              |      |
|      +---------------------------------------------------------+      |
+-----------------------------------------------------------------------+

Rò rỉ lộ trình xảy ra thường xuyên do sai sót thao tác quản trị: kỹ sư mạng cấu hình nhầm bộ lọc xuất lộ trình (export route map) trên thiết bị biên, hoặc một bộ lọc chính sách tự động gặp trục trặc trong quá trình bảo trì định kỳ. Khi Doanh nghiệp AS300 làm rò rỉ lộ trình từ Nhà mạng A sang Nhà mạng B, các mạng lân cận sẽ lầm tưởng rằng AS300 sở hữu một đường truyền kết nối trực tiếp tối ưu.

Lưu lượng dữ liệu quốc tế vốn dành cho các đường cáp quang xuyên lục địa bỗng nhiên đổ dồn vào các đường truyền nội bộ nhỏ bé của AS300. Hậu quả tức thì là mạng bị nghẽn nghiêm trọng, độ trễ tăng vọt lên hàng nghìn mili-giây và tỷ lệ rớt gói tin đạt mức báo động.

Trong các sự cố thực tế từng ghi nhận trên thế giới—như vụ rò rỉ năm 2019 khiến dữ liệu di động của nhiều nước châu Âu bị hút về mạng của một công ty sản xuất thép khu vực, hoặc các sự cố chuyển hướng lưu lượng đám mây—hàng tỷ gói tin mã hóa đã bị cuốn vào đường vòng mà các quy tắc kiểm tra ROA thông thường không thể nhận biết.

Cơ chế hoạt động của ASPA: Ủy quyền nhà cung cấp bằng mật mã

ASPA giải quyết triệt để khiếm khuyết mang tính hệ thống này bằng cách thiết lập một chuỗi ủy quyền có thể xác minh được về mặt mật mã học cho các quan hệ giữa các Hệ tự trị. Theo tiêu chuẩn RFC 9319, một Hệ tự trị sẽ khởi tạo và ký số bản ghi ASPA trong kho lưu trữ RPKI.

Một bản ghi ASPA chứa đựng một tuyên bố giản dị nhưng được bảo vệ bằng chữ ký số nghiêm ngặt:

  • AS Khách hàng (Customer AS - CAS): Hệ tự trị phát hành chứng thư ủy quyền.
  • Tập hợp AS Nhà cung cấp (Provider AS Set - PAS): Danh sách đầy đủ các Hệ tự trị thượng nguồn mà AS Khách hàng ủy thác cung cấp dịch vụ trung chuyển và lan truyền các bản tin định tuyến của mình.

Bản ghi ASPA hỗ trợ độc lập cho cả hai giao thức địa chỉ IPv4 và IPv6. Do đối tượng ASPA nằm trong cấu trúc chứng thư X.509 hiện hữu của RPKI, chúng thừa hưởng trọn vẹn hạ tầng phân phối và xác thực bảo mật như các bản ghi ROA. Mọi bộ định tuyến biên có chạy phần mềm kiểm định RPKI (như Routinator, StayRtr hay rpki-client) đều có thể tải về và đối soát bảng dữ liệu ASPA một cách tự động.

Thuật toán xác thực ASPA: Cưỡng chế nguyên tắc Valley-Free

Khi một bộ định tuyến biên có hỗ trợ ASPA tiếp nhận một bản tin quảng bá lộ trình BGP, thiết bị sẽ so khớp toàn bộ chuỗi số hiệu AS trong thuộc tính AS_PATH với cơ sở dữ liệu ASPA đã được nạp sẵn.

Thuật toán xác thực lần lượt phân tích từng cặp AS liền kề (AS(i), AS(i+1)) trên suốt tuyến đường:

  1. Chuỗi hướng lên (Khách hàng lên Nhà cung cấp): Khi luồng dữ liệu đi từ AS gốc lên các nhà mạng trung chuyển, mỗi chặng AS(i) -> AS(i+1) phải thể hiện mối quan hệ Khách hàng - Nhà cung cấp hợp lệ, trong đó AS(i+1) có tên trong bản ghi ASPA của AS(i).
  2. Điểm đỉnh (Apex): Lộ trình đạt tới tầng cao nhất của chuỗi truyền dẫn (nhà mạng Tier-1 toàn cầu hoặc liên kết ngang hàng song phương).
  3. Chuỗi hướng xuống (Nhà cung cấp xuống Khách hàng): Khi bản tin đi từ nhà cung cấp xuống mạng nhận, mỗi chặng AS(i) -> AS(i+1) phải thể hiện mối quan hệ Nhà cung cấp - Khách hàng hợp lệ, nghĩa là AS(i) phải nằm trong bản ghi ASPA của AS(i+1).

Nếu thuật toán phát hiện bất kỳ bước chuyển nào từ hướng xuống quay ngược lại hướng lên (vi phạm quy tắc valley-free khi lộ trình bị rò rỉ ngang hàng hoặc giữa hai nhà cung cấp), hoặc nếu tồn tại một chặng trung gian mà mạng phía dưới chưa từng ủy thác cho nhà mạng phía trên, thuật toán sẽ trả về kết quả Invalid.

Các bộ định tuyến BGP kích hoạt ASPA sẽ tự động hủy bỏ các lộ trình rơi vào trạng thái Invalid, bảo đảm các bản tin rò rỉ không thể ghi đè lên các tuyến đường truyền dẫn đường trục chính thức.

Xác thực đường dẫn chiều lên và chiều xuống

Hướng mà bộ định tuyến tiếp nhận bản tin BGP sẽ quyết định phương thức áp dụng thuật toán kiểm tra ASPA:

Loại cổng kết nối tiếp nhận Cấu trúc AS_PATH kỳ vọng Hướng kiểm tra ASPA Mục tiêu phòng vệ chính
Từ Khách hàng Chuỗi hoàn toàn hướng lên (Khách -> Nhà cung cấp...) Xác thực từ Khách hàng lên Nhà cung cấp Ngăn khách hàng làm rò rỉ lộ trình từ các nhà mạng khác của họ
Từ Đối tác ngang hàng Chuỗi lên, một chặng ngang hàng, rồi chuỗi xuống Kiểm tra đối xứng quy tắc valley-free Chống rò rỉ lộ trình ngang hàng và thao túng AS_PATH
Từ Nhà cung cấp Chuỗi lên tới đỉnh, sau đó chuỗi xuống Xác thực hướng xuống về phía AS nguồn gốc Ngăn nhà mạng trung chuyển chuyển tiếp lộ trình khách hàng bị rò

Bằng cách áp dụng các phép kiểm tra toán học phù hợp với vai trò của từng cổng kết nối, thiết bị biên loại bỏ hoàn toàn nhu cầu phải đàm phán các thỏa thuận bảo mật song phương phức tạp với các mạng đối tác ở xa. Các lộ trình vi phạm ủy quyền sẽ bị chặn đứng ngay tức thì ở tốc độ xử lý phần cứng.

Rò rỉ lộ trình đe dọa các đường hầm VPN như thế nào

Các mạng riêng ảo VPN thiết lập các đường hầm mã hóa băng qua các hạ tầng mạng vật lý trung gian công cộng. Mặc dù các giao thức hiện đại như WireGuard hay IPsec mã hóa toàn diện nội dung dữ liệu, chúng vẫn là các gói tin IP chịu sự chi phối trực tiếp của các quyết định định tuyến BGP bên dưới.

Khi một sự cố rò rỉ lộ trình BGP hoặc chiếm quyền đường dẫn xảy ra trên tuyến kết nối giữa thiết bị người dùng và máy chủ VPN, đường hầm sẽ đối mặt với ba rủi ro nghiêm trọng:

  1. Nghẽn mạng gây gián đoạn đường truyền: Các lộ trình rò rỉ thường đẩy lưu lượng khổng lồ vào các mạng khu vực có năng lực truyền dẫn hạn chế. Tình trạng phình bộ đệm (bufferbloat) và rớt gói tin hàng loạt sẽ làm đứt các gói tin duy trì kết nối UDP keepalive, bóp nghẹt băng thông TCP và khiến đường hầm VPN liên tục bị ngắt kết nối.
  2. Phân tích lưu lượng và nhận diện thời gian truyền: Dù dữ liệu được mã hóa, kẻ nghe lén có thể định tuyến dòng lưu lượng đi qua mạng do họ kiểm soát để tiến hành phân tích độ trễ gói tin, kích thước dữ liệu và thu thập nhật ký metadata nhằm liên kết hoạt động của người dùng với các máy chủ đích.
  3. Hiện tượng hố đen dữ liệu (Blackholing): Các mạng gây rò rỉ lộ trình thường công bố đường đi mà thực tế không có cổng kết nối ra ngoài để tới đích, khiến các gói tin VPN bị biến mất hoàn toàn vào hố đen mạng cho tới khi bảng định tuyến toàn cầu hội tụ trở lại.

RiceGuard và kiến trúc Anycast chống suy thoái định tuyến

Hạ tầng mạng lưới tại VPNRice được thiết kế dựa trên triết lý chủ động phòng vệ trước các biến động định tuyến Internet. Bằng cách kết hợp giao thức đường hầm hiệu năng cao RiceGuard với kiến trúc BGP Anycast phân tán, hệ thống bảo vệ lưu lượng người dùng cách ly khỏi các bất ổn mạng công cộng.

+-----------------------------------------------------------------------+
|                    LÁ CHẮN ĐỊNH TUYẾN CHỦ ĐỘNG RICEGUARD              |
+-----------------------------------------------------------------------+
|  [ Lưu lượng người dùng từ thiết bị ]                                 |
|         │                                                             |
|         ▼                                                             |
|  [ Địa chỉ IP Anycast biên ]  -> Phân tán trên các mạng Tier-1        |
|         │                                                             |
|         ▼                                                             |
|  [ Bộ lọc RPKI ROV + ASPA ]   -> Kiểm định AS_PATH trước khi tiếp nhận|
|         │                                                             |
|         ▼                                                             |
|  [ Nhân đường hầm RiceGuard ] -> Mã hóa ChaCha20-Poly1305 tốc độ dây  |
|         │                                                             |
|         ▼                                                             |
|  [ Đường trục truyền dẫn sạch]-> Triệt tiêu đường vòng / Độ trễ thấp  |
+-----------------------------------------------------------------------+

RiceGuard thiết lập các tầng bảo vệ chuyên sâu:

  • Bộ lọc nghiêm ngặt tại các cổng Tier-1: Các máy chủ biên của VPNRice chỉ kết nối với các đối tác trung chuyển có triển khai đầy đủ cơ chế RPKI ROV và kích hoạt bộ lọc ASPA trên toàn bộ cổng giao tiếp.
  • Dự phòng Anycast địa lý: Bằng cách công bố cùng một dải tiền tố IP từ nhiều trung tâm dữ liệu phân tán khắp các châu lục, nếu một sự cố rò rỉ lộ trình xảy ra ở một khu vực, hệ thống Anycast sẽ tự động điều hướng lưu lượng sang các nút biên lân cận an toàn.
  • Khôi phục trạng thái tức thì: Nhờ cơ chế đóng gói UDP gọn nhẹ không phụ thuộc vào bắt tay rườm rà, RiceGuard tái thiết lập phiên truyền bảo mật trong vài mili-giây ngay khi tuyến đường BGP bên dưới ổn định trở lại.

Người dùng có thể cài đặt các ứng dụng kết nối bảo mật cho máy tính và điện thoại tại trang tải xuống VPN.

Triển khai thực tế: Khởi tạo và xuất bản bản ghi ASPA

Để kích hoạt tính năng bảo vệ ASPA, quản trị viên Hệ tự trị cần công bố các bản ghi ủy quyền thông qua các Cơ quan quản lý Internet khu vực (RIR) như APNIC, RIPE NCC, ARIN, LACNIC hoặc AFRINIC.

Bản ghi ASPA có thể được tạo qua cổng quản trị RPKI trực tuyến của RIR hoặc thông qua hệ thống máy chủ chứng thực RPKI nội bộ theo chuẩn RFC 8181.

Cấu trúc dữ liệu của bản ghi ASPA

Cấu trúc định dạng JSON chuẩn của một bản ghi ASPA dành cho Hệ tự trị doanh nghiệp (AS65100) ủy quyền cho các nhà mạng trung chuyển như sau:

{
  "customer_asid": 65100,
  "providers": [
    {
      "provider_asid": 174,
      "afi": "both"
    },
    {
      "provider_asid": 2914,
      "afi": "both"
    },
    {
      "provider_asid": 3356,
      "afi": "both"
    }
  ]
}

Trong cấu trúc này:

  • customer_asid xác định số hiệu AS sở hữu các dải IP.
  • providers liệt kê danh sách các nhà mạng viễn thông được ủy thác trung chuyển (Cogent AS174, NTT AS2914 và Lumen AS3356).
  • afi xác định quyền hạn áp dụng đồng thời cho cả hai họ địa chỉ IPv4 và IPv6.

Bất kỳ thông báo lộ trình nào thể hiện AS65100 đi qua một hệ thống trung gian không được cấp phép sẽ ngay lập tức bị các bộ định tuyến toàn cầu gắn nhãn Invalid và loại bỏ.

Cấu hình bộ định tuyến: Kích hoạt kiểm định ASPA trên BIRD và FRR

Các phần mềm định tuyến mã nguồn mở phổ biến hiện nay như BIRD (từ phiên bản 2.15 trở đi) và FRRouting (FRR) đã tích hợp sẵn mô-đun kiểm định ASPA nội bộ.

Cấu hình mẫu cho BIRD 2

Trong tệp cấu hình của BIRD, giao thức RPKI kết nối tới phần mềm kiểm định cục bộ (thông qua giao thức RTR cổng 8282):

# Kết nối tới dịch vụ xác thực RPKI RTR nội bộ
protocol rpki rpki_validator {
    rtr 127.0.0.1 port 8282;
    retry 300;
    refresh 600;
    aspa 4; # Kích hoạt ASPA cho IPv4
    aspa 6; # Kích hoạt ASPA cho IPv6
}

# Bộ lọc BGP áp dụng kiểm tra ASPA
filter ebgp_in_filter {
    # Kiểm tra nguồn gốc tiền tố IP trước
    if roa_check(rpki_validator, net, bgp_path.last) = ROA_INVALID then {
        reject "Loai bo: Nguon goc ROV khong hop le";
    }

    # Kiểm tra tính hợp lệ của chuỗi đường dẫn ASPA
    if aspa_check(rpki_validator, bgp_path, 0) = ASPA_INVALID then {
        reject "Loai bo: Chuoi ASPA khong hop le (Phat hien ro ri lo trinh)";
    }

    accept;
}

Bằng cách đặt aspa_check trực tiếp trong bộ lọc đầu vào, các đường dẫn sai trái sẽ bị ngắt bỏ trước khi chiếm dụng bộ nhớ của bảng định tuyến nội bộ (RIB).

So sánh ASPA và BGPSec: Tính khả thi trong thực tiễn

Trong nhiều năm, tiêu chuẩn BGPSec (RFC 8205) từng được kỳ vọng là giải pháp tối hậu cho an ninh định tuyến. BGPSec đòi hỏi mọi bộ định tuyến trên đường đi phải ký số lên bản tin BGP UPDATE trước khi chuyển tiếp cho chặng tiếp theo.

Tuy nhiên, BGPSec gặp phải những rào cản triển khai không thể vượt qua trong thực tế:

  • Tải xử lý phần cứng quá lớn: Việc ký số và xác thực từng bản tin cập nhật liên tục ở tốc độ hàng trăm gigabit vượt quá năng lực xử lý của các chip xử lý trên bộ định tuyến hiện nay.
  • Phình to kích thước gói tin: Việc chèn thêm chữ ký số sau mỗi chặng làm khung bản tin BGP bị vượt ngưỡng MTU, đòi hỏi phân mảnh gói TCP phức tạp.
  • Rào cản triển khai đồng bộ: BGPSec yêu cầu mọi nhà mạng trên toàn thế giới phải đồng thời nâng cấp thiết bị; chỉ cần một nhà mạng trung gian không hỗ trợ, toàn bộ chuỗi chữ ký số sẽ bị đứt gãy.

ASPA mang lại cách tiếp cận thực tế và khả thi hơn rất nhiều:

  1. Không can thiệp vào định dạng bản tin BGP: Không làm thay đổi cấu trúc gói tin BGP UPDATE trên đường truyền.
  2. Chi phí xử lý cực thấp: Bộ định tuyến biên chỉ cần tra cứu nhanh trên bảng dữ liệu bộ nhớ đệm cục bộ đã được tính toán từ trước.
  3. Bảo vệ độc lập ngay từ đầu: Chỉ cần nhà cung cấp dịch vụ của bạn bật tính năng kiểm tra ASPA, toàn bộ lưu lượng của bạn đã được bảo vệ mà không cần chờ đợi toàn bộ mạng Internet toàn cầu nâng cấp.

Danh mục kiểm tra bảo mật định tuyến cho kỹ sư mạng

Các kỹ sư hạ tầng mạng và quản trị viên hệ thống có thể nâng cấp mức độ an toàn định tuyến theo các bước sau:

  1. Xuất bản chứng thư ROA chuẩn: Đăng ký đối tượng Route Origin Authorization cho toàn bộ dải IP thuộc quyền quản lý tại các cơ quan quản trị Internet khu vực.
  2. Công bố bản ghi ASPA: Khai báo danh sách các nhà mạng viễn thông trung chuyển chính thức của doanh nghiệp lên hệ thống RPKI.
  3. Kích hoạt lọc ROV tại cổng biên: Cấu hình bộ định tuyến biên tự động hủy bỏ các bản tin rơi vào trạng thái ROA_INVALID.
  4. Cập nhật phần mềm kiểm định ASPA: Nâng cấp các trình xác thực RPKI nội bộ (như Routinator 0.13+, StayRtr, hoặc rpki-client) để truyền bảng ASPA xuống thiết bị mạng.
  5. Giám sát lộ trình liên tục: Sử dụng các công cụ quan sát định tuyến BGP toàn cầu để phát hiện kịp thời các trường hợp dải IP của tổ chức bị điều hướng qua các đường dẫn bất thường.

Bảo vệ không gian định tuyến toàn cầu đòi hỏi chúng ta phải đi xa hơn việc chỉ kiểm tra nguồn gốc dải IP. Bằng cách áp dụng cơ chế xác thực chuỗi đường dẫn thông qua ASPA, cộng đồng mạng Internet đang từng bước loại bỏ hoàn toàn các rủi ro từ sự cố rò rỉ lộ trình BGP, mang lại nền tảng truyền dẫn ổn định và an toàn cho các mạng đường hầm mã hóa trên toàn thế giới.