IPsec实验.doc

IPsec 实验 一、验证双隧道负载功能 R1：R3配置双隧道 R1双隧道关键配置 R3 双隧道关键配置： 查看R3、R1上隧道统计数据 通过以上数据可以明显看出，数据包直走test 隧道 操作一：将R1端隧道顺序调整为 test1 test 调整两端 flow 匹配tunnel 顺序后 ,发生了收发各走2条隧道的情况, 说明在flow 中先匹配靠前的tunnel ,如果前面的tunnel 一直存在,则后面的隧道一直处于备份状态; 操作二：在操作一的环境下，两端设置的flow 走隧道的先后顺序相反，这样收发就是走不同隧道，验证set track-aware 和set peer-track-aware命令，保证数据流收发走隧道一致（一条隧道）； set track-aware 命令解释:当同一安全策略对应多条隧道，且隧道工作在非负载均衡的情况下，安全策略根据隧道TRACK状态进行选择，优先选择TRACK状态不为DOWN的隧道。 set peer-track-aware 命令解释:安全策略应用PEER-TRACK，本端会根据接收数据的隧道来选择反向隧道，保证该安全策略的数据接收与发送使用同一条隧道; 在R1配置 set track-aware 在R3配置 set peer-track-aware 另一条隧道有一个包 这个我认为应该是检测报文,检测之后就切换到正常的隧道了; 操作三: 将R1与R3两端配置 负载 ,验证负载功能 全局调整负载方式: 同时还要调整两端的负载方式 idle time 默认为 off 关闭状态的 ，也就是一旦建立不会down 调整idle为5s ，也可以针对in 和 out 方向的流量设置idle time 5S 后隧道没有流量自动断开 扩展认证 DPD 功能时间 观察验证 DPD 报文格式 抓包没分析出相应字段 ,觉得 发送和应答有一样 IPSEC使用DPD（dead peer detection）功能来检测对端peer是否存活，类似到其它协议中的hello或keepalive机制，目前我司 DPD支持两种机制： 1）on-demand 机制，该机制在隧道闲置时间超过指定配置的时间，且此时有报文发送，才会刺激发送 DPD探测消息。 2）periodic机制，该机制是在超过配置的时间后就会主动发送 DPD 探测消息。 periodic 机制验证 ： 1 是每次发一个包 延迟是20秒 2 我认为应该是最大重试次数 60 是超时时间 下面抓包是隧道空闲时，DPD报文抓包 下面抓包是隧道由数据时DPD报文抓包 总结：只有在隧道空闲时，DPD 报文 periodic 这个机制才会生效,也就是说数据报文也有保活的作用 on-demand 机制 1 是发一次包 ，延迟20秒 最大重试次数2次 超时 60s 这个功能解释的是:当隧道空闲超时时间到了,而且有新数据到达隧道,就会触发DPD报文的检测 ,那么既然我司设备可以用数据包保活,那DPD这个功能就没有用了,不会再发送on-demand 机制的DPD包,因为数据包已经保活了; 实际抓包也是这样的. ipsec flow 流 backup 和 bypass bypass：有隧道走隧道，没隧道走路由 backup：有路由走路由 ，没路由走隧道。但是有个前提，路由出口必须是backup配置的接口，否则无效 默认