
Mục lục bài viết 10 phần
VRF route leaking thường dùng để đưa DNS, logging hoặc dịch vụ quản trị dùng chung tới nhiều tenant. Một route “có trong bảng” chưa đủ: test plan phải chứng minh đúng prefix được trao đổi, sai tenant vẫn bị chặn, return path đi đúng security control và thay đổi policy không tạo cửa sổ rò rỉ.
Bài viết giúp bạn
- Route leaking đang giải quyết bài toán gì
- Topology và trust boundary
- Biến số phải kiểm soát
Route leaking đang giải quyết bài toán gì
#Mục tiêu phổ biến là reachability có chọn lọc giữa VRF hoặc tới shared services, không phải hợp nhất mọi route. Trước lab, lập intent matrix ghi source VRF, destination prefix/service, protocol/port, hướng, next hop bắt buộc và chủ sở hữu phê duyệt.
Trong BGP/MPLS L3VPN, Route Distinguisher làm route IPv4/IPv6 trùng prefix trở nên phân biệt; Route Target điều khiển phân phối/import theo policy. Không được coi RD là security policy, cũng không coi việc route không xuất hiện là bằng chứng duy nhất rằng traffic bị chặn.
Topology và trust boundary
#Topology mẫu gồm VRF-A, VRF-B có prefix trùng nhau, VRF-SHARED chứa DNS/NTP/logging, PE hoặc route reflector và firewall/service chain nếu kiến trúc yêu cầu kiểm soát. Mỗi VRF có endpoint phát traffic và capture point độc lập; shared service ghi source identity thực tế nhận được.
Đặt probe ở cả trước và sau điểm leak. Bằng chứng cần nối được: route advertisement → import policy → RIB/FIB → next hop → firewall session/log → response. RD làm route VPN phân biệt trong control plane, nhưng không tự giải quyết hai route trùng địa chỉ khi nhập vào cùng shared-services VRF. Cần NAT, context/VRF riêng hoặc phương án kiến trúc tương ứng. Nếu dùng NAT, ghi rõ mapping và không trộn lỗi NAT với lỗi route.

Biến số phải kiểm soát
#Chốt address family, RD/RT, import/export policy, route preference, ECMP, firewall state, NAT, recursive resolution và default route. Tách các lần chạy theo full route, selective prefix và default-only; không đổi nhiều biến trong cùng fault test.
Traffic profile phải có flow được phép và bị cấm, cả chiều đi lẫn chiều về. Với UDP kiểm tra request/response; với TCP kiểm tra handshake, phiên dài và reconnect. Dùng DSCP, packet size và connection count đại diện nhưng tránh để hiệu năng che mất sai policy.
KPI và chuỗi bằng chứng
#Mỗi pass/fail nên gắn event ID và timestamp. “Không có response” chỉ là kết quả; muốn kết luận fail-closed phải chỉ ra packet bị chặn ở policy/enforcement point, không phải rơi do DNS, MTU hoặc route về.
- Lớp: Control plane · KPI: Route đúng VRF/prefix/next hop · Bằng chứng tối thiểu: RIB diff + policy hit · Cảnh báo sai phổ biến: Có route nhưng sai origin
- Lớp: Data plane · KPI: Throughput, latency, loss · Bằng chứng tối thiểu: Probe hai đầu + capture · Cảnh báo sai phổ biến: Ping pass thay cho service
- Lớp: Security · KPI: Unauthorized reachability = 0 · Bằng chứng tối thiểu: Negative-flow log · Cảnh báo sai phổ biến: Chỉ kiểm allow path
- Lớp: Symmetry/state · KPI: Session completion · Bằng chứng tối thiểu: Firewall/session telemetry · Cảnh báo sai phổ biến: SYN đi được nhưng response sai VRF
- Lớp: Change · KPI: Exposure window, recovery · Bằng chứng tối thiểu: Timeline commit/withdraw · Cảnh báo sai phổ biến: Chỉ nhìn trạng thái cuối
Ma trận quyết định import/export
#Nếu thiết kế route target cho phép transit ngoài ý muốn, cần thêm test A→SHARED→B. Shared-services VRF không được mặc định thành điểm trung chuyển giữa tenant; kiểm tra uRPF, stateful policy và route redistribution tại đây.
- Source: VRF-A · Destination: DNS shared · Route được import?: Có, prefix cụ thể · Service được phép?: UDP/TCP 53 · Expected path: Qua firewall
- Source: VRF-A · Destination: VRF-B app · Route được import?: Không · Service được phép?: Không · Expected path: Không có FIB/deny
- Source: VRF-B · Destination: DNS shared · Route được import?: Có, prefix cụ thể · Service được phép?: UDP/TCP 53 · Expected path: Qua firewall
- Source: VRF-B · Destination: VRF-A overlap · Route được import?: Không · Service được phép?: Không · Expected path: Không resolve nhầm
- Source: SHARED · Destination: Tenant subnet · Route được import?: Chỉ route về cần thiết · Service được phép?: Established/approved · Expected path: Qua firewall
Test plan positive và negative
#- Bước 1: Export cấu hình/RIB/FIB baseline, chuẩn hóa thành danh sách machine-readable.
- Bước 2: Advertise một prefix hợp lệ, một prefix ngoài allowlist và hai prefix overlap.
- Bước 3: Xác nhận import đúng VRF, next hop và label/tunnel context theo kiến trúc.
- Bước 4: Phát DNS/TCP/UDP test flow được phép; đo latency, packet loss và session completion.
- Bước 5: Phát tenant-to-tenant, spoofed-source và port ngoài policy; yêu cầu tất cả fail đúng điểm.
- Bước 6: Thu route-policy counter, firewall log, endpoint log và pcap cùng event ID.
- Bước 7: Lặp với response path, ECMP member change và firewall failover nếu có.
- Bước 8: So diff sau rollback với baseline; không để route hoặc session orphan.

Fault injection và thay đổi cấu hình
#Các lỗi cần tách riêng: gắn nhầm RT, xóa prefix-list, route reflector mất kết nối, next hop unreachable, firewall failover và rollback giữa chừng. Đo exposure window từ commit đến khi unauthorized flow bị chặn lại; đây thường quan trọng hơn convergence trung bình.
Canary change nên dùng prefix test không phục vụ production và transaction/commit có rollback. Nếu platform không atomic, ghi rõ thứ tự thao tác sao cho deny được cài trước allow. Bài test pass khi cả reachability mong đợi phục hồi và đường trái phép vẫn đóng.
Runbook điều tra route leak
#- Chụp intent matrix và thay đổi gần nhất trước khi sửa.
- Xác định route nằm ở Adj-RIB-In, VPN RIB, VRF RIB và FIB nào.
- Kiểm tra RD/RT, policy hit, next-hop resolution và route preference.
- Theo dấu một flow allow và một flow deny ở hai chiều.
- Kiểm tra firewall/NAT state cùng asymmetric path.
- Thu hồi route/policy sai theo change plan, không xóa rộng toàn VRF.
- Re-run negative suite và so với baseline sau rollback.
Giới hạn kết luận
#Một test pass với IPv4 unicast không đại diện cho IPv6, multicast hoặc EVPN address family. Cũng không thể suy segmentation an toàn chỉ từ RT: route policy, ACL/firewall, identity và quản trị thay đổi đều nằm trong control set.
Kết quả lab phụ thuộc scale route, churn, topology RR/PE và software build. Với multi-vendor, cách hiển thị RIB/RT khác nhau; hãy so hành vi wire/data plane và intent thay vì ép tên lệnh giống nhau.
Khái niệm cần nhớ
#- VRF: bảng định tuyến và forwarding logic được tách biệt.
- Route Distinguisher: giá trị làm route VPN có prefix trùng nhau trở nên duy nhất.
- Route Target: extended community dùng để điều khiển import/export VPN route.
- Route leaking: trao đổi route có chủ đích giữa các miền định tuyến tách biệt.
- Overlapping prefix: cùng không gian địa chỉ xuất hiện ở nhiều tenant/VRF.
- Fail-closed: khi lỗi xảy ra, đường không được phép vẫn bị chặn.
Khái niệm cần nhớ
- Security efficacy
- Mức độ phát hiện hoặc ngăn chặn đúng nội dung kiểm thử trong phạm vi đã xác định.
- Goodput
- Lưu lượng ứng dụng hữu ích tới đích, không tính phần truyền lại hoặc overhead không tạo giá trị.
- False positive
- Lưu lượng hợp lệ bị nhận diện hoặc xử lý nhầm như một mối đe dọa.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo4 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
