在你的组网中,IPSec 感兴趣流(ACL)只匹配源网段 192.168.1.0/24 而不指定目的网段是行不通的,且会导致 IPSec 隧道无法建立或流量转发异常。
以下是详细的原因分析和正确的配置建议:
1. 为什么不可行?
IPSec 协商机制要求(镜像 ACL)
IPSec 隧道建立依赖于两端设备对“哪些流量需要加密”达成一致。这通过 ACL(访问控制列表) 来定义,且要求两端的 ACL 规则必须互为镜像。
- 东站防火墙:源=192.168.1.0/24,目的=?
- 总公司防火墙:源=192.168.1.0/24,目的=?
如果你只配置源地址,不配置目的地址(默认为 any 或 0.0.0.0/0):
- 协商失败:如果一端配置了具体的目的地址(例如为了指向对端),另一端配置为
any,IPSec 协商时,两端计算的流量范围不一致,会导致 IKE 第二阶段(IPSec SA)协商失败。 - 流量匹配错误:如果两端都配置为
source 192.168.1.0/24 且 destination any,设备会认为“所有从 192.168.1.0 发出的流量”都需要加密。这包括访问互联网的流量、访问本地设备的流量等。这些流量会被错误地加密并尝试通过隧道发送,导致正常业务中断。
同网段路由与环路风险
由于东站和总公司都是 192.168.1.0/24 网段:
- 如果不指定目的地址,防火墙可能会尝试加密发往本地网关或本地其他设备的流量。
- 更重要的是,IPSec 隧道建立后,系统需要知道哪些流量该走隧道。如果不精确匹配目的网段,路由表将无法正确区分“本地流量”和“隧道流量”。
2. 针对你组网的特殊建议(同网段互联)
由于两端内网网段相同(都是 192.168.1.0/24),直接建立 IPSec 隧道会有严重的路由冲突(设备不知道 192.168.1.x 到底是本地的还是对端的)。
强烈建议采用 NAT 穿越方案(NAT 映射),即在 IPSec 隧道内部做一层地址转换,将一端映射为不同的网段。
推荐方案:配置 NAT 使得两端逻辑上不同网段
假设:
- 东站:保持 192.168.1.0/24
- 总公司:保持 192.168.1.0/24
- IPSec 隧道内映射:将总公司的服务器映射为 10.1.1.0/24(虚拟网段)
正确的 ACL 配置示例(基于 NAT 方案)
东站防火墙配置:
你需要定义感兴趣流,告诉防火墙:“我要访问 10.1.1.0/24(总公司的映射网段)的流量,请加密。”
1# 定义感兴趣流:源是本地网段,目的是对端映射网段
2acl number 3001
3 rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 10.1.1.0 0.0.0.255
注意:这里必须同时指定 source 和 destination。
总公司防火墙配置:
你需要定义感兴趣流,告诉防火墙:“我要访问 192.168.1.0/24(东站的网段)的流量,请加密。”(同时需要在 IPSec 策略中配置 NAT 策略,将源 192.168.1.0 转换为 10.1.1.0 发送给东站,或者反之,具体取决于哪一侧做映射)。
3. 如果你坚持不做 NAT(不推荐)
如果你坚持不做 NAT,直接打通同网段,这在三层路由上是不支持的,除非你使用二层 over IPSec (L2 over IPSec) 或 VPLS 等复杂技术,但这通常要求物理链路支持二层透传,且极易产生广播风暴和 ARP 混乱。
修正后的 ACL 写法(仅理论修正,不解决同网段路由问题):
如果你仅仅是想修复 ACL 语法问题,必须补全目的地址。假设你认为对端也是 192.168.1.0/24(这在路由上是不通的):
1# 这种配置在路由层面是无效的,因为源和目的网段重叠
2acl advanced 3001
3 rule 0 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
暂无评论