各位晚上好自上次更新已经有了20多天没更新了罪过罪过。不过确实有一个令人振奋的消息需要主动的推送给大家。上周历经9个小时完成了Hillstone-HCSE的考试并通过了。这期间让我感触最深的就是细心和经验非常关键痴迷命令行的网工在考试中是有优势的因为命令行集中体现了思路、逻辑、快的三个特点所以这一次考试也算给自己在山石的售后近两年一个完美的交代。
————————Allen
当然了今晚不是傲娇的过来说一说我考试过了也是带了一个山石特有的×××场景的干货过来了大家都或多或少知晓市面上主流的×××应用场景和配置手法无非就是L2TP/PPTP/IPSEC/SSL这样的功能当然也不排除万金油的GRE今天给大家介绍山石特有的一个***场景pnp***具体的大家往下看。
上大菜~~~~~~
PnP×××解决了哪些需求
IPSec×××配置复杂维护成本高对网管人员技术要求高针对该问题Hillstone 为企业用户提供了一种简单易用的×××技术——PnP-×××即即插即用×××。通过PnP-×××技术在部署×××时在中心Server端做好配置接入端只需填入简单的几项配置即可实现到中心端的×××连接。
PnP××× 的工作流程如下
1. 客户端发起连接请求并传送自己的 ID 以及密码到服务器端。
2. 服务器端收到请求后验证客户端传送的 ID和密码验证通过即下发预配置的 DHCP 地址池、DHCP 掩码、DHCP 网关、WINS、DNS 和隧道路由
等信息到客户端。
3. 客户端把收到的信息下发到相应的功能模块。
4. 客户端 PC 自动获取 IP 地址、IP 地址掩码和网关地址等网络参数并正常接入 ××× 网络。
官方原文截图【留意标红的地方】
其实在笔者玩过这么多年各种×××的互联对接需求后对山石网科的pnp***的理解转化为通俗语言就是如下一番这样的理解
即把分支侧的DHCP的配置隧道访问的配置。全部使用了由总部下发的配置的手段实现即分支不需要养技术员所有的维护全部由总部直接进行即可。
贴上今天演示的拓扑图：
需求说明
1. 通过×××功能实现总部和分支之间的内网直接访问
2. 分支网内配置DHCP
3. 分支和分支实现内网互访
PS：上图虚线为笔者个人准备配置的pnp-***思路逻辑链接图。
介绍下山石网科pnp-***的配置思路---
– 第一步配置认证服务器和添加用户
– 第二步配置IKE×××
*配置P1提议可选
*配置ISAKMP网关
*配置P2提议可选
*生成pnp客户端秘钥
*配置隧道
– 第三步配置Tunnel接口并添加×××路由
*新建Tunnel接口,绑定安全域及IPSec隧道
*添加通过Tunnel接口访问对端的路由
– 第四步配置访问策略
下面为大家献上个人整理的CLI命令行的配置总结。---【笔者亲测配置后的效果绝对没有错误放心刷配置都可以】
第一步：
3A服务器配置
aaa-server pnp*** type local -------------配置本地 AAA 认证服务器-pnp***
user shanghai -------------使用上海地区命名pnpclient账户，容易区分
password shanghaiuser
ike-id fqdn shanghai
dhcp-pool-gateway 192.168.20.1
------------为上海分支定义dhcp的gateway、mask、可用ip地址范围
dhcp-pool-netmask 255.255.255.0 ------------同上
dhcp-pool-address 192.168.20.2 192.168.20.100 ------------同上
split-tunnel-route 192.168.10.0/24
------------为上海分支下发目的明细路由，在上海分支client拨入success后，route会存在V*路由
dns 114.114.114.114 8.8.8.8
------------为上海分支下发dns服务器ip，（在分支pc网卡dns会呈现为20.1，并接口起dns-proxy）
wings x.x.x.x （option）
exit
aaa-server pnp*** type local -------------配置本地 AAA 认证服务器-pnp***
user shenzhen -------------使用深圳地区命名pnpclient账户，容易区分
password shenzhen
ike-id fqdn shenzhen
dhcp-pool-gateway 192.168.40.1
------------为深圳分支定义dhcp的gateway、mask、可用ip地址范围
dhcp-pool-netmask 255.255.255.0 ------------同上
dhcp-pool-address 192.168.40.2 192.168.40.100 ------------同上
split-tunnel-route 192.168.40.0/24
------------为深圳分支下发目的明细路由，在深圳分支client拨入success后，route会存在V*路由
dns 114.114.114.114 8.8.8.8
------------为深圳分支下发dns服务器ip，（在分支pc网卡dns会呈现为40.1，并接口起dns-proxy）
wings x.x.x.x （option）
exit
第二步：
自定义算法------pfs组必须为group2，否则会出错
hostname(config)# isakmp proposal test1
hostname(config-isakmp-proposal)# group 2
hostname(config-isakmp-proposal)# exit
hostname(config)# ipsec proposal test2
hostname(config-ipsec-proposal)# group 2
hostname(config-ipsec-proposal)# exit
配置ipsec-***第一阶段参数：
isakmp peer "test1"
mode aggressive ---使用野蛮模式
type usergroup ---类型使用用户组
isakmp-proposal "test1" ---调用自定义算法
pre-share 123456 ---常规配置，后面生成rootkey需要此参数，切勿与user password混淆
aaa-server "pnp***" ---调用前面定义的AAA本地认证服务器
interface aggregate1 ---公网出接口
exit
配置ipsec-***第二阶段参数：
tunnel ipsec "test" auto
isakmp-peer "test1" ----关联第一阶段
ipsec-proposal "test2" ----调用自定义的第二阶段算法
生成客户端秘钥：
hostname(config)# exec generate-user-key rootkey 123456 userid shanghai ----rootkey是第一阶段的pre-share参数，切勿混淆
userkey: kyZAKmLWCc5Nz75fseDiM2r+4Vg=【生成输出物】
该参数填入参考：
第三步：
配置独立zone，和tunnel接口，并关联pnp***
NAV-BBBBBBBB(config)# zone pnp
NAV-BBBBBBBB(config-zone-pnp)# exit
interface tunnel5
zone "pnp"
tunnel ipsec "test"
总部Server端指定去往分支的tunnel路由
ip route 192.168.20.0/24 tunnel5
ip route 172.16.119.0/24 tunnel5
第四步：
最后配置总部与分支的policy即可实现互访
总部侧------------
分支和分支之间，策略即：pnp 到 pnp
总部和分支之间，策略即：dmz 到 dmz （both双向均需要添加）
分支侧------------
web-ui中-IPSEC ××× ---右上角---pnp client，找到并点击设置pnp，参考如下：
分支到总部之间，策略即：内网接口所在zone到tunnel接口所在zone（both双向均需要添加）
到这里，我们按照PNP-***的配置思路全部配置完毕，即：这个时候，我们即可进行测试了。而且当然通过远程管理进入到分支的防火墙底层中，show inter 、show config等等，你会发现。
分支的内网DHCP-POOL已经配置完成、内网主机已经自动获取成功。也自动创建了一个zone属于×××的tunnel接口，并存在我们在总部设置的split route的路由信息。
这个也就是我们前面介绍的PNP×××的工作流程中的第三部完成的，【客户端把收到的信息下发到相应的功能模块】，说句实话，挺神奇的。
我在总部show查看×××的up情况，参考如下：
NAV-BBBBBBBB# show ipsec sa
Total: 3
S - Status, I - Inactive, A - Active;
=============================================================
Id ××× Peer IP Port Algorithms SPI Life(s) S
--------------------------------------------------------------------------------
17 test >172.16.106.50 500 esp:3des/sha/- 799a7a51 15069 A
17 test <172.16.106.50 500 esp:3des/sha/- 79c940d1 15069 A
18 test >172.16.106.66 500 esp:3des/sha/- 589df89d 15076 A
18 test <172.16.106.66 500 esp:3des/sha/- 79c940d3 15076 A
=============================================================
结论：到分支已经全部up，看来pnp***已成功的配置完成。“给自己一点掌声”
不过这个时候，我们测试发现分支可以Ping通总部内网主机，但无法Ping通另外一个分支点，反向从总部Ping分支，无法Ping通。笔者这个时候纳闷了。难道遇到传说总的单向通信？？？？心中一万个why出来。。。。。
不慌，待我一步一步详细查看，毕竟我是专业的网工。思路如下：
1.检查配置-------×××配置、×××client配置均检查没毛病
2.检查路由-------查看路由获取正常，FIB表也正常
3.使用最终兵器，Debug，在总部debug出来的信息最终输出结果如下：
--------VR:trust-vr start--------
172.16.119.200:1->192.168.40.200:2973
NAT: ICMP protocol type/code 0800
No DNAT matches, skip DNAT
Get nexthop if_id: 19, flags: 0, nexthop: 0.0.0.0
Interface route
NAT: ICMP protocol type/code 0800
No SNAT matches, or out of pool, skip SNAT
--------VR:trust-vr end--------
Start policy lookup.
Pak src zone dmz, dst zone pnp, prot 1, dst-port 2973.
Policy 9 matches, ===PERMIT===
crt_sess->flow0_io_cpuid 0
flow0 src 172.16.119.200 --> dst 192.168.40.200 with nexthop 0.0.0.0 ifindex
19
flow1 src 192.168.40.200 --> dst 172.16.119.200 nexthop not lookup or invalid
dp_sess_sm_transtion: Do session state machine transtion, state: 1, event: 4!
flow0's tunnel id (0) invalid.
Dropped: Failed to create session
-----------------------First path over (session not created)
Droppped: failed to create session, drop the packet (action=0)
——————————————————————————————————————————
大家注意我标注的红色的地方，懂防火墙处理流程的网工，我详细基本已经能看到问题在哪里了。
我画个图给大家理解下，参考如下：
描述下：--【此篇文章的精华】
分支A测试PC-3发起ICMP的流量ping到总部测试PC-1，流量没有任何问题，大家都知道ALG、或者思科service-policy等一些不固定端口协议的流量触发后，防火墙的自动适应处理的概念。
但当总部PC-1发起ICMP的流量到分支A时，这个时候，我们PNP的tunnel接口因为绑定了两个×××实例，此时接口根据以上配置无法识别测试PC-1到底是去分支A还是分支B，所以防火墙“毫不犹豫”的给予的严肃处理，即：Drop。（所以不是防火墙不给力，而是防火墙不知道怎么帮你转发流量所以直接扔掉，以保护设备性能。）
最后怎么解决呢，大家往下看
回过头来，我们总部Server端指定去往分支的tunnel路由，并补充了下一跳的地址
ip route 192.168.20.0/24 tunnel5 172.16.106.50（分支设备的公网ip）
ip route 172.16.119.0/24 tunnel5 172.16.106.66（分支设备的公网ip）
ps：前面就是因为没指定下一跳，内网虽然发起ping导致设备无法区分同一个接口两个分支的pnp流量。直接导致设备把流量drop掉，补充下一跳之后，分支和分支之间、总部和分支之间立马正常
最后补充一个小提示：
PNP-client配置完成后大约在一分钟后，pnp客户端协商成功，配置下发成功。需要耐心等待！！
综上，
山石网科的PNP-×××还是很不错的，不过确实需要一个有强大售后血液的工程师去沟通这样的前期需求，否则容易出现笔者介绍的一些不通现象，倘若客户在旁边，那就尴尬了。
好，到这里今天的分享就结束了，忙了一周，其实希望能不要以周五是休息的目的去度过。因为网工的姿态是天天向上，在我们网工眼里，任何时间都是学习和提升自己的时候。
——————来自一家二级运营商的网工分享
大家晚安.51CTO晚安。。。。
转载于:https://blog.51cto.com/allen686/1885681
5115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
