技术点详解—IPSec方案部署

通过前面几期的介绍可以发现IPSec所涉及的参数很多,在具体方案部署过程中有许多灵活选择的地方,本期专栏就专门对IPSec在几种典型环境中的方案部署进行介绍。

一、              常规IPSec方案

上图所示网络环境是最基本的IPSec应用场景:

1.       响应方无论在何种环境都是固定的公网地址;

2.       发起方也是固定的公网地址;

3.       双方都是用IKE主模式进行协商;

4.       双方都互相指定对端IP地址,即双方都可以发起协商,没有固定的发起方、响应方;

5.       双方只能使用隧道模式,因为兴趣流192.168.1.0/24ßà192.168.0.0/24和IPSec隧道端点不一致。

由于只有大型企业才有可能为所有分支机构申请一个固定IP地址,商务领航客户通常是中小型企业,固定地址的情况并不多见,所以该场景更多出现在实验室环境中,在该方案中,如果有多个发起方,那么响应方需要对每个发起方制定IPSec策略。

二、              发起方公网地址不固定情况下的IPSec部署

上面这个场景比较常见:

1.       响应方地址固定,如6.16.5.6;

2.       多个发起方使用动态接入互联网方式,如PPPoE拨号,这种方式中,发起方每次拨号地址有可能不一致,所以在响应方中无法使用指定对端IP地址方式限制对端身份;

3.       发起方则必须要指定响应方IP,否则无法发起协商;

4.       双方可以使用预共享密钥方式对身份进行确认及保护;

5.       双方依然只能使用隧道模式;

6.       兴趣流的指定是比较有意思的事情,发起方是必须要配置兴趣流的,图中只举了一个发起方配置兴趣流的示例,那么响应方呢?响应方没有配置,而是采用由发起方指定的方式,即在协商过程中,响应方得知发起方的兴趣流是192.168.1.0/24à192.168.0.0./24,会自动为该响应方生成反向兴趣流192.168.1.0/24ß192.168.0.0./24,那么为什么要这么使用呢?

a)       发起方地址是动态的;

b)       响应方无法及时提前获知发起方地址,因此没有指定发起方的IP地址;

c)       由于响应方的兴趣流爷是与发起方相关的,而响应方中发起方的身份标识是IP地址,故响应方无法提前为发起方指定兴趣流;

d)       替代方法就是响应方在协商过程中,动态地识别发起方,并接受发起方的兴趣流;

e)       这种方式还能在响应方配置工作带来简化,不需要为每个发起方制定IPSec策略。

三、              部分发起方通过NAT网关连接到互联网

在上图中,有部分发起方躲在NAT网关后面连接互联网,如发起方Spartacus,在这种情况下,我们的IPSec方案该如何制定呢?

1.       大体上和方案二类似;

2.       IKE协商模式要修改成野蛮模式(Aggressive Mode);

3.       需要在IKE协商模式中打开NAT穿越,目前大部分厂家实现中,NAT穿越都变成默认选项。

针对这种发起方地址动态变化的情况,还有一个相对来说更加安全的解决方案,即响应方需要指定发起方。

我们从方案的标题可以看出,有的方案是“响应方指定发起方”,有的是“不指定”,具体区别在于如下两点:

1.       响应方指定对端IP地址或者指定对端名字,即指定响应方的固定身份标识,而不是动态身份;

2.       响应方为特定的响应方指定兴趣流用于协商。

在上一期专栏中介绍在IPSec中最常用的身份标识是IP地址,而在发起方动态IP或者存在NAT网关的情况下,就无法为发起方指定IP地址了,因此方案中使用指定名字方式作为身份标识,而使用名字作为身份标识则必须使用IKE的野蛮模式:

1.       响应方为每个发起方指定名字;

2.       响应方为每个发起方指定兴趣流。

如果不指定发起方,那么只要与共享密钥泄露,任意发起方都能够与响应方建立IPSec会话,指定发起方后,除掌握预共享密钥外,还必须掌握发起方IP地址(仿冒IP地址只能作为攻击手段,而非通信手段)或者名字才可以发起协商,因此安全性要比不指定发起方要高。

四、              企业分支使用GRE Over IPSec进行网络互连

为什么要使用GRE Over IPSec来互连呢,有如下好处:

1.       分支网络和总部网络都比较复杂,需要使用路由协议进行互联;

2.       IPSec隧道在承载路由协议上不如GRE隧道方便;

3.       GRE隧道不能提供加密保障,因此需要和IPSec进行结合;

4.       GRE Over IPSec方案的优点在于,使用GRE在两个网关之间搭建一个隧道,运行路由协议及传输正常数据,使用IPSec对整个GRE隧道进行加密。

在这个方案中,特殊之处在于:

1.       发起方、响应方的IP地址都是固定不变的,采取了响应方指定发起方的配置方式;

2.       发起方、响应方的GRE隧道源地址和目的地址和IPSec隧道的源地址、目的地址一致,因此可以使用传输模式,提高传输效率,可以对比一下图中推荐的兴趣流配置与GRE隧道配置。

同样,如果发起方地址不是固定的,或者发起方躲在NAT网关后面,那么可以采取如下方式。

GRE隧道的特点是要求隧道的源、目的必须是固定的,因此在这种环境中:

1.       所有网关设置Loopback地址,如响应方设置环回接口地址为192.168.1.1/32,两个发起方分别为192.168.1.2/24和192.168.1.3/24;

2.       使用Loopback接口地址分别在响应方和各发起方之间建立GRE隧道;

3.       由于IPSec隧道是使用连接互联网地址建立的,因此与兴趣流不一致,只能使用隧道模式;

4.       由于是发起方地址动态获得,所以使用IKE野蛮模式+指定名字方式;

5.       以上两种方式可以混合,即根据发起方地址类型,分别配置身份标志类型、封装模式和兴趣流,可以有部分发起方和响应方是指定IP地址+传输模式的,另外一部分则使用指定名字+隧道模式。

五、              对外出员工采用L2TP Over IPSec方案

在之前的L2TP专栏中,我们了解到了L2TP主要是为单个外出员工提供远程接入企业网络的方案,而L2TP本身不提供加密服务,因此L2TP结合IPSec就能够为外出员工提供安全可靠的远程接入解决方案:

1.       外出员工的特点就是地址不固定,即采用IKE野蛮模式;

2.       兴趣流是L2TP流量,即发起方到响应方的UDP 1701流量,因此也就表明了兴趣流也不是固定的,响应方只能采取由对端指定兴趣流方案;

3.       由于如上两点原因,响应方可以采取不指定发起方;

4.       由于有部分发起方要穿越NAT,必须要使用隧道模式。

本期将常见的IPSec应用场景进行了介绍,并对各个场景中对IPSec配置方案有影响的地方进行分析。IPSec专题介绍,到此告一段落。

IPSec方案部署(多业务场景)的更多相关文章

  1. CDN 边缘规则,三秒部署、支持定制、即时生效,多种规则覆盖常用业务场景

    2017年的最后一周,又拍云进行了一次重要升级,将自定义 Rewrite 升级为"边缘规则".互联网应用场景的日益多样化,简单.方便.快速的根据不同应用场景实现不同的功能变得越来越 ...

  2. GOF业务场景的设计模式-----观察者模式

    定义:定义对象间一种一对多的依赖关系,使得当每一个对象改变状态,则所有依赖于它的对象都会得到通知并自动更新. 在软件系统中经常会有这样的需求:如果一个对象的状态发生改变,某些与它相关的对象也要随之做出 ...

  3. 整理分布式锁:业务场景&分布式锁家族&实现原理

    1.引入业务场景 业务场景一出现: 因为小T刚接手项目,正在吭哧吭哧对熟悉着代码.部署架构.在看代码过程中发现,下单这块代码可能会出现问题,这可是分布式部署的,如果多个用户同时购买同一个商品,就可能导 ...

  4. 受教了,memcache比较全面点的介绍,受益匪浅,适用memcached的业务场景有哪些?memcached的cache机制是怎样的?在设计应用时,可以通过Memcached缓存那些内容?

    基本问题 1.memcached的基本设置 1)启动Memcache的服务器端 # /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 ...

  5. 双态运维分享之:业务场景驱动的服务型CMDB

    最近这几年,国内外CMDB失败的案例比比皆是,成功的寥寥可数,有人质疑CMDB is dead?但各种业务场景表明,当下数据中心运维,CMDB依然是不可或缺的一部分,它承载着运维的基础,掌握运维的命脉 ...

  6. React Hooks简单业务场景实战(非源码解读)

    前言 React Hooks 是React 16.7.0-alpha 版本推出的新特性.从 16.8.0 开始,React更稳定的支持了这一新特性. 它可以让你在不编写 class 的情况下使用 st ...

  7. 【智能合约】编写复杂业务场景下的智能合约——可升级的智能合约设计模式(附Demo)

    智能合约的现状 以太坊在区块链上实现了智能合约的概念,用于:同质化通证发行(ERC-20).众筹.投票.存证取证等等,共同点是:合约逻辑简单,只是业务流程中的关键节点,而非整个业务流程.而智能合约想解 ...

  8. 老猿学5G随笔:5G的三大业务场景eMBB、URLLC、mMTC

    5G的三大业务场景eMBB.URLLC.mMTC: eMBB:英文全称Enhanced Mobile Broadband,即增强移动宽带,是利用5G更好的网络覆盖及更高的传输速率来为用户提供更好的上网 ...

  9. 腾讯游戏 K8s 应用实践|更贴近业务场景的 K8s 工作负载:GameDeployment & GameStatefulSet

    引言 蓝鲸容器服务(Blueking Container Service,以下简称BCS)是腾讯 IEG 互动娱乐事业群的容器上云平台,底层基于腾讯云容器服务(Tencent Kubernetes E ...

随机推荐

  1. Elatsicsearch分片和副本相关知识

    1.分片和副本 1.1什么是分片 简单来讲就是咱们在ES中所有数据的文件块,也是数据的最小单元块,整个ES集群的核心就是对所有分片的分布.索引.负载.路由等达到惊人的速度. 分片是把索引数据切分成多个 ...

  2. [转] 携程App网络服务通道治理和性能优化@2016

    App网络服务的高可靠和低延迟对于无线业务稳定发展至关重要,过去两年来我们一直在持续优化App网络服务的性能,到今年Q2结束时基本完成了App网络服务通道治理和性能优化的阶段性目标,特此撰文总结其中的 ...

  3. python内置方法补充bin

    bin(x) 英文说明:Convert an integer number to a binary string. The result is a valid Python expression. I ...

  4. nginx rewrite标签配置以及用户认证配置

    一.nginx  rewrite标签 rewrite 实现URL的改写主要是实现伪静态 1.  rewrite指令语法 指令语法:rewrite regex replacement[flag] 默认值 ...

  5. day6 装饰器总结

    装饰器:开放封闭原则,为一个函数加上新的功能,不改变原函数,不改变调用方式 def fun2(wtf): def fun3(): print('i am pythoner!!! ') wtf() re ...

  6. POJ3660 暑假集训-最短路H题floyd

      http://acm.hust.edu.cn/vjudge/contest/view.action?cid=82829#rank#include<iostream> #include& ...

  7. EntityFramework 学习 一 Migration from Entity Framework 4.1/4.3 to Entity Framework 5.0/6.0

    To migrate your existing Entity Framework 4.x project to Entity Framework 5.0 using VS2012, first ta ...

  8. bzoj 3038: 上帝造题的七分钟2 线段树||hdu 4027

    3038: 上帝造题的七分钟2 Time Limit: 3 Sec  Memory Limit: 128 MBSubmit: 1066  Solved: 476[Submit][Status][Dis ...

  9. Hadoop- HDFS的API操作

    1.引入依赖 <dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop- ...

  10. php: +1天, +3个月, strtotime(): +1 day, +3 month

    php: +1天, +3个月, strtotime():  +1 day, +3 month 比如,我现在当前时间基础上+1天: strtotime("+1 day"); 比如我现 ...