📚 课程目录第3章边界路由策略与过滤框架

3. 边界路由策略与过滤框架

在BGP边界安全工程中，策略与过滤框架是控制路由“进出边界”的核心手段。它要解决的不是“能不能通”，而是“哪些前缀允许被通告、哪些前缀允许被接收、接收后如何修改属性、修改后如何影响选路”。如果只依赖邻居的“善意”，边界路由就会成为攻击面：前缀劫持、路由泄漏、超长掩码注入、伪造源AS等问题都可能穿透网络。因此，工程化设计必须把前缀列表、AS路径过滤、社区属性和路由映射组合成一套可维护、可审计、可回滚的过滤体系，并明确部署位置。

四类工具的职责边界

前缀列表（prefix-list）负责“前缀+掩码长度”的精确匹配，适合做白名单式准入。例如只允许接收 203.0.113.0/24 及其更具体前缀，或只允许通告本AS的聚合块。AS路径过滤（AS-path filter）负责“来源AS与路径合法性”，常用正则表达式匹配路径中是否出现私有AS、是否包含客户/对等/上游的合法序列。社区属性（community）负责“打标签与策略传递”，把路由来源、地理区域、客户类型、安全等级编码进路由，供后续策略引用。路由映射（route-map）负责“组合条件与动作”，把前缀列表、AS路径、社区、下一跳、MED、local-preference等条件串起来，执行permit/deny与set动作。

四者不是并列关系，而是“条件层—标签层—执行层”的协作：前缀列表和AS路径过滤提供准入条件，社区提供可传递的元数据，route-map把条件与动作绑定，最终在邻居的inbound或outbound方向生效。

工程化设计的关键参数与示例

以Cisco IOS风格为例，假设本地AS为65000，需要接收客户AS 65001的路由，并只允许其自有前缀 203.0.113.0/24 和 198.51.100.0/24，同时拒绝私有AS和超长掩码。可以这样组织：

! 前缀列表：只允许客户自有块，掩码长度精确匹配
ip prefix-list PL-CUSTOMER-65001 permit 203.0.113.0/24
ip prefix-list PL-CUSTOMER-65001 permit 198.51.100.0/24
ip prefix-list PL-CUSTOMER-65001 deny 0.0.0.0/0 le 32

! AS路径过滤：拒绝包含私有AS 64512-65534的路径
ip as-path access-list 10 deny _64[5-9][0-9][0-9]_
ip as-path access-list 10 deny _65[0-4][0-9][0-9]_
ip as-path access-list 10 deny _6553[0-5]_
ip as-path access-list 10 permit ^65001$

! 社区属性：标记客户来源
ip community-list standard CL-CUSTOMER permit 65000:100

! 路由映射：组合条件与动作
route-map RM-IN-CUSTOMER permit 10
 match ip address prefix-list PL-CUSTOMER-65001
 match as-path 10
 set community 65000:100 additive
 set local-preference 200
route-map RM-IN-CUSTOMER deny 20

这段配置的工程含义是：只有同时满足“前缀在白名单内”和“AS路径合法”的路由才会被permit，并被打上 65000:100 的客户标签，同时提升本地优先级。任何不满足条件的前缀都会命中最后的deny 20，被丢弃。注意，route-map末尾隐含deny any，因此显式写deny 20是为了审计清晰，也便于后续插入新条目。

部署位置的选择逻辑

部署位置不是“随便挂一个route-map”，而是由流量方向和信任边界决定。inbound方向应优先执行前缀过滤和AS路径过滤，因为这是防止外部非法路由进入本地RIB的第一道闸门。如果先打社区再过滤，非法路由可能已经携带标签进入策略链，增加误判风险。outbound方向则应先匹配本地路由来源，再设置社区和属性，最后通告给邻居。对于客户、对等、上游三类邻居，必须使用独立的route-map和独立的prefix-list，避免“一套策略打天下”导致客户前缀被错误通告给上游，或上游路由被错误反射给对等体。

一个常见的工程错误是：在inbound方向只做前缀过滤，不做AS路径过滤。攻击者可以伪造源AS，把不属于客户的前缀伪装成客户路由。因此，前缀列表和AS路径过滤必须同时生效，形成“前缀+路径”的双重校验。另一个错误是：在outbound方向忘记附加 no-export 或 no-advertise 社区，导致内部路由泄漏到全局互联网。社区属性在这里不仅是标签，更是策略传递的载体。

可维护性与审计

工程化设计还要求策略可读、可审计、可回滚。建议为每个邻居分配独立的策略命名空间，例如 RM-IN-CUSTOMER-65001、RM-OUT-PEER-65002，并在route-map描述中写明用途、创建日期和负责人。前缀列表应尽量使用精确匹配，避免使用 le 32 这类宽泛条件，除非确实需要接收更具体前缀。AS路径正则表达式应先在实验室验证，再上生产，因为正则写错可能导致合法路由被误杀。社区属性应建立全局编号规范，例如 65000:1xx 表示客户，65000:2xx 表示对等，65000:3xx 表示上游，65000:9xx 表示安全黑名单。

部署检查要点： inbound先过滤后打标签；outbound先匹配后设置；客户/对等/上游策略分离；前缀列表精确匹配；AS路径过滤拒绝私有AS和保留AS；社区编号全局统一；route-map末尾显式deny并记录日志。

最后，策略框架不是一次性配置，而是持续运营的对象。每次新增邻居、变更前缀或调整社区，都应同步更新prefix-list、as-path filter和route-map，并在变更后通过 show ip bgp neighbors neighbor routes 和 show route-map 验证实际生效结果。只有把过滤、标签、执行三层绑定在正确的部署位置上，边界路由安全才能从“配置正确”走向“运行可控”。