设为首页 收藏本站
查看: 895|回复: 0

[经验分享] cisco *** 学习笔记--第三天

[复制链接]

尚未签到

发表于 2018-7-17 06:19:42 | 显示全部楼层 |阅读模式
  IPSec *** 网络穿越和高可用性
  第一部分  IPSec *** 网络穿越问题
  1.1 IPSec 流量放行问题(中间设备)
  放行加密点之间的ISAKMP和ESP 流量
  site1:202.100.1.1
  site2:202.100.2.1
access-list out extended permit udp host 202.100.1.1 eq isakmp host 202.100.2.1 eq isakmp  
access-list out extended permit esp host 202.100.1.1 host 202.100.2.1
  
access-group out in interface outside
  1.2 IPSec 流量放行问题(加解密设备)
  site1:202.100.1.1
  site2:61.128.1.1
ip access-list extended inbound  
permit upd host 远端ip eq isakmp host 本端ip eq isakmp
  
permit esp host 远端ip host 本端ip
  
ip access-list extended outbound
  
permit esp host 本端ip host 远端ip
  
interface f0/0
  
ip access-group inbound in
  
ip access-group outbond out
  1.3 入方向crypto MAP对流量的处理
是否感兴趣流是否加密有无mapactionN/A是有解密是不有drop是不没有forwardN/A是没有解密  1.4 NAT-T 技术介绍
  NAT-T技术默认是开启的
NAT对ESP的影响:  
在传输模式的ESP,NAT修改了外层IP地址,由于TCP/UDP校验和的计算包含IP源目地址,所以TCP/UDP的
  
校验和需要更新,但是现在TCP/UDP已经加密,中间路由器无法更新TCP/UDP的校验和,所以TCP的校验和
  
检查最终会失败
  
隧道模式的ESP,不受1:1转换的影响(动态一对一,静态一对一),但是不能穿越PAT,因为PAT转换,
  
多个内部地址复用一个外部地址,并且使用传输层端口来区分不同流量,很遗憾ESP没有传输层端口
  NAT-T技术的三个步骤
第一步决定双方是否都支持NAT Traversal  
    决定双方是否支持NAT-T和判断peers之间是否有NAT存在的任务在IKE第一阶段完成,NAT-T能力探
  
    测使用IKE第一阶段1-2个包交换来实现,双方互相交换NAT-T的vendor ID来表示本端是否支持NAT-T
  
第二步决定两个peers 之间是否有NAT存在
  
    为了决定peers之间是否有NAT存在,peer会发送一个hash负载(源目IP和端口计算),如果双方计算
  
    的hash和接收的hash值匹配,那么peers之间就没有NAT存在(就采用ESP封装),如果hash值不匹配,
  
    那么peers就需要使用NAT-T技术封装穿越NAT
  
    hash负载也叫NAT-D负载,他在MM模式的3-4个包发送,也在AM的2-3个包发送
  
第三步决定如何使用UDP封装
  第二部分 IPSec ***高可用性
  2.1 基本IPSec ***配置
  crypto isakmp policy 10  
    authentication pre-share
  
    crypto isakmp key cisco address 202.100.1.1
  
    crypto ipsec transform-set ***trans esp-des esp-md5-hmac
ip access-list extended ***  
  permit ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255
crypto map ***-map 10 ipsec-isakmp  
set peer 202.100.1.1
  
set transform-set ***trans
  
match address ***
interface f0/0  
crypto map ***-map
  inside 暂时添加一条路由
  ip route 0.0.0.0 0.0.0.0 10.1.1.10
  2.2  Reverse Route injection ( RRI)
  哪台路由器处于active(有IPSEC SA)就会有如下的RRI
  static route 1.1.1.0/24 next hop 202.100.1.1
  RRI介绍
RRI能够为远端隧道终点保护的网络和主机,在路由表内动态的插入相应的静态路由,这些被保护的主机  
和网络也被叫为“remote proxy identities”
  
基于“remote proxy”的网络和掩码产生每一条路由,这些网络的下一跳为远端隧道终点。使用远端***
  
路由器为下一跳,能够引导流量被加密
  RRI配置(ACTIVE)
crypto map ***-map 10  
set reverse-route tag 10(为RRI动态产生的路由打上tag10)
  
reverse-reoute(启用RRI)
  
route-map static-to-ospf permit 10
  
match tag 10 (配置上tag 10的路由)
  
router ospf 1
  
redistribute static subnets route-map static-to-ospf (重分布静态路由到身后动态路由协议)
  2.4 Dead Peer Detection
  ***使用一个keepalive机制叫做DPD,来检查远端隧道IPSec路由器的可用性。如果网络发生不寻常的忙碌或者不稳定,我们能够设置一个时间来等待,并且判断远端设备是否“Active”。DPD技术能够和其他高可用性技术配合使用,尽快的清除有问题的IPSec SA,和正常工作的peer建立IPSec隧道
  DPD有两种工作模式:

  •   Periodic
  •   on-demand(默认)
DPD Periodic  周期性的检测dead peers  
crypto isakmp keepalive 10 periodic
  
周期性频繁的发送信息结果就是通讯双方会加解密更多的数据包,增加设备的资源消耗
DPD on-demand  基于流量形式的不同而采取不同的发送方式  
crypto isakmp keepalive 10
  
默认情况下DPD连续5次无响应,会认为链路故障
  
如果一台路由器发送了出方向的流量,在一定时间内对端路由器没有回送相应的解密流量,这个时候DPD被发送来询问对端状态。
  
如果一台路由器没有流量要发送,那么它也不会发送DPD信息
  default peer
使用“set peer ”命令我们可以配置第一个peer为default peer  
如果配置了default peer,下一次连接会直接向default peer发起
  
如果default peer 没有响应,在“peer list”里边的下一个peer 会成为current peer
  idle timers
  阻止闲置peer消耗资源

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-537823-1-1.html 上篇帖子: CISCO数据中心虚拟化之vPC技术和配置 下篇帖子: Cisco 交换机启用netflow
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表