DEP是什么

DEP是很多使用WAN链接各个分分支机构不可避免要考虑的方案。

DEP指的是IPSec双方不再使用IP地址进行相互验证，而是使用主机名负载进行验证的一种方式。在这种方式中，Initiator以不定地址向核心节点的Responder的固定地址发起请求。由于Initiator的地址不固定，因此就有了Dynamic End Point的名字。

因为一般的不适用固定IP的PPPoE服务相对价格低廉，而固定IP的专线服务，一般价格可以达到PPPoE服务的十倍以上，并且PPPoE拥有相对更大的下行带宽，可以显著的改善客户的使用体验。所以，掌握DEP的配置，就是每个SRX工程师所应当掌握的技能。

实验当中，我们使用两台J4350，软件版本为11.1R1.14，该实验的命令在其他所有版本当中没有变化。相应的配置脚本，大家可以根据页末的链接，去易思拓在线网络教育论坛的对应帖子当中去下载。

DEP在SRX当中，只能由Route-based IPSec去完成，Policy-based IPSec不能配置成为DEP。

拓扑和接口配置

如图所示，两台设备使用Ge-0/0/1.0进行互联，设备接口地址按照设备编号，Device1一侧的地址都是1，Device2一侧的地址都是2。为了测试两测的可达性，配置了lo0口作为标记，lo0的地址通过St0传送，以此来验证IPSec Tunnel的正常工作。

由于加密流量无法通过IDP或者SCREEN的审查，所以为了增加网络流量管理的灵活性，我们将St0口放在单独的一个zone里，名为×××。其他相关接口的zone如下表。

尽管在接口配置当中，使用了固定的IP地址配置，但是IKE和IPSec的配置完全遵循了DEP的准则，就是作为Center的Device2是不使用IP地址来识别Device1，也就是远程DEP接入用户的。

IKE和IPSec配置

IKE的配置当中，Device1作为Center端，在IKE policy当中，指明IKE的工作模式是积极模式（Aggressive mode），至于为什么这里不能用主模式，请翻阅我们以前的专题。在Gateway配置当中，使用Dynamic选项来配置主机名；同理，在作为分支机构Branch的配置当中，也把自己的主机名作为关键的认证信息包含在IKE的第一个数据包当中请求通过验证。

------------------------Center Configuration----------------------------

lab@Device1# show security ike
proposal ROUTE_IKE_PRO {
   authentication-method pre-shared-keys;
   dh-group group2;
   authentication-algorithm sha1;
   encryption-algorithm des-cbc;
}
policy ROUTE_IKE_POLICY {
   mode aggressive;
   proposals ROUTE_IKE_PRO;
   pre-shared-key ascii-text "$9$t1JXOBEMWxdwg1Rxd"; ## SECRET-DATA
}
gateway ROUTE_IKE_GW {
   ike-policy ROUTE_IKE_POLICY;
   dynamic {
       hostname "cisco@cisco.com";
       connections-limit 100;
   }
   external-interface ge-0/0/1.0;
}

---------------------------------Branch Configuration---------------------

lab@Device2# show security ike
proposal ROUTE_IKE_PRO {
   authentication-method pre-shared-keys;
   dh-group group2;
   authentication-algorithm sha1;
   encryption-algorithm des-cbc;
}
policy ROUTE_IKE_POLICY {
   mode aggressive;
   proposals ROUTE_IKE_PRO;
   pre-shared-key ascii-text "$9$j7q.5CA0Ihrmf0I"; ## SECRET-DATA
}
gateway ROUTE_IKE_GW {
   ike-policy ROUTE_IKE_POLICY;
   address 192.168.12.1;
   local-identity hostname "cisco@cisco.com";
   external-interface ge-0/0/1.0;
}

IPSec的配置，Center和Branch的配置都是一样的，IKE的配置在这里被引用。在这里st0.0被绑定为route-based IPSec的接口。

------------------------IPSec configuration------------------------------

lab@Device1# show security ipsec
proposal ROUTE_IPSEC_PRO {
   protocol esp;
   authentication-algorithm hmac-sha1-96;
   encryption-algorithm des-cbc;
}
policy ROUTE_IPSEC_POLICY {
   proposals ROUTE_IPSEC_PRO;
}
*** ROUTE_IPSEC_××× {
   bind-interface st0.0;
   ike {
       gateway ROUTE_IKE_GW;
       ipsec-policy ROUTE_IPSEC_POLICY;
   }
   establish-tunnels immediately;
}

验证IKE和IPSec 的工作

如图中红框所示，积极模式的IKE已经正常工作，并针对这个IKE，生成了两个方向的IPSec的SA。由于我们的ST0.0接口配置的地址是13.0.0.1和13.0.0.2，无论在Device1还是Device2，这两个地址都是可达的。

基本的OSPF配置

在这里，是为了验证st0.0接口对于OSPF的良好支持。当设备配置了st0.0接口，并将其加入OSPF区域当中的时候，系统会自动的把OSPF的类型改为point-to-point  broadcast模式，并将相应的配置同步到OSPF当中，因而无须人力参与，OSPF邻居便可自动建立完成。

在本试验中，我们把st0.0和lo0.0口简单的宣告进OSPF区域当中，并由OSPF负责传递Device1和Device2的lo0.0路由。

[edit]
lab@Device1# show protocols ospf
area 0.0.0.0 {
   interface st0.0;
   interface lo0.0;
}

最终验证

最终验证主要通过两个方面。首先，两台设备的lo0.0接口应该能ping通，并且IPSec的状态数据应该随着时间的流逝而增加，因为OSPF会不断的发送hello来验证对端的状态。

配置文件下载链接，点击这里。

转载的请注明原出处：易思拓在线网络培训--http://www.5iit.cn