云主机对外暴露管理接口、API 或支付回调后，安全组和 ACL 看起来只放行了固定来源，攻击者却通过伪造源地址，把恶意请求伪装成可信网段。更棘手的是，伪造包可能绕过入口规则，直接触发业务进程，造成越权访问、异常重试或资源耗尽。
真正有效的防护不是简单加一条白名单，而是判断“这个源地址是否有权从当前入口抵达”，并在云主机、边缘节点和上游网络分别建立过滤与观测边界。<
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：ufovps（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。>
普通 ACL 通常按源地址、目的地址、端口和协议匹配。攻击者发送 SYN、RST 或应用层请求时，把 IP 头中的源字段改成内部地址、白名单地址或另一个客户网段。若入口设备只验证五元组，不验证报文路径，报文就可能被放行，后续连接甚至可能借助已建立会话形成反向劫持。
入口流量过滤、反向路径过滤和 BCP38 前缀过滤解决的层次不同。反向路径过滤检查到达接口的源前缀，是否能通过同一接口返回；BCP38 则要求报文源前缀与宣告该前缀的合法客户边界一致。前者适合发现路径不一致，后者适合在网络边界限制伪造地址，但两者都不能替代业务层认证。
第一层在云主机或主机侧启用入口流量过滤，按实际网卡、路由表和可信来源收敛规则，同时保留本机回环、监控探针和容器网络所需流量。第二层在边缘节点检查会话是否跨越合法路径，对 TCP 连接使用握手报文建立会话，避免后续 ACK 混入。第三层由上游网络执行 BCP38 前缀过滤，只允许从授权客户边界发来的前缀进入，并把违规报文计数、采样日志上报。
判断是否生效，不能只看“连接成功”。应在云主机侧检查安全组命中计数，在边缘侧核对会话方向和反向路径结果，在上游侧核对前缀宣告与丢弃原因。监测应记录源前缀、入口接口、丢弃位置、规则编号和时间戳，形成可关联的反欺骗日志；只记录“非法来源”而不保留路径信息，排查会非常困难。
常见误拦截来自多出口 NAT、任播回流、IPv6 临时地址、容器和边缘节点的双向路由，以及健康检查使用固定地址。排查时应先还原真实路径，再临时放行已确认的合法前缀，并用连接跟踪确认没有会话劫持。不要为了消除告警而关闭反向路径过滤，也不要把云厂商地址段全部视为可信。对外提供远程接入的随身服务器场景，更应把管理入口与业务入口分开，启用强认证和来源日志。
反向路径过滤（通常由 Linux 的 rp_filter 参数实现）不是简单查看路由表，而是把数据包的源地址送入 FIB，检查到达接口是否存在对应路由，再据此接受或丢弃。严格模式（rp_filter=1）要求源地址的最佳回程路径必须指回入接口；宽松模式（rp_filter=2）只要求能找到该源地址的可达路由。
严格模式适合对称路由环境，但在等价多路径、策略路由、ECMP 哈希不对称、隧道或 SD-WAN 环境中，合法流量也可能因最佳路径与入接口不同而被丢弃。宽松模式能降低误杀，却只能发现“完全不可达”的源地址，不能证明源地址确实属于当前客户，因此应配合接口方向、邻居关系和前缀策略判断。
部署时必须核对实际生效位置：主机参数、全局 sysctl、接口级覆盖和容器网络命名空间可能并不相同；IPv4 与 IPv6 的策略也应分别验证。反向路径过滤不能替代入口流量过滤，因为它验证的是回程路由，而不是地址授权范围。
BCP38 的核心原则是：运营商只接受源地址属于已分配给该客户前缀的入站流量，并在边界设备按客户、接口或 VRF 维护允许列表。它适合解决源地址伪造中“冒用他人地址”的问题，但需要地址分配、路由对象、租户边界和设备配置保持同步。前缀变更、回收、迁移或新增第二地址却未更新列表，都会造成误拦截。
常见坑包括把过滤方向写反、遗漏无编号接口、把任意互联网前缀加入白名单、在共享边界上误用全局 ACL，以及忽略 NAT、IPv6 地址轮换和 anycast 场景。测试不能只看能否访问业务地址，还应覆盖默认路由、ICMP、已建立连接和高流量方向，确认控制平面与数据平面策略一致。
反欺骗日志至少应记录时间、入口接口、源/目的地址与端口、命中的允许前缀、判定原因和动作，并区分前缀不匹配、源地址不可达、ACL 拒绝及路由异常。计数器按前缀、接口和原因聚合，采样日志保留足够上下文，避免只留下“某个包被丢弃”而无法定位责任边界。
最终，源地址校验只能缩小源地址伪造的可利用空间，不能证明发送者的真实身份。可靠边界应由路由可达性、地址授权范围和可审计日志共同界定，并通过持续验证而非一次性配置长期维持。
