l2tp启动的时候，会自动修改ipsec的配置，修改端口 由 500 改成6000，l2tp的禁用的时候会改回来，但是当前出现过无法正常改回来的问题。导致ipsec服务异常。   1、抓包发现我们收到协商包以后，没有应答，调试日志也没有看到有调试日志 2、netstat -npl | grep lmdlan ，发现没有监听500端口，但是监听了6000端口 产品bug 7.6.8版本使用升级客户端加载20200605_CTI-Support__TD202005191223.ssu升级包升级即可 该包所有版本都可以使用；去预警 YJ20200714001下载 1、支持集群环境下升级，无需拆集群，并且只需要在分发器升级即可，真实服务器会自动升级； 分布式环境，无需拆分布式，但每台设备需要升级，先升级主节点，再升级从节点； 2、支持集群环境下回滚，无需拆集群，先回滚分发器，再回滚真实服务器； 分布式环境，无需拆分布式，先回滚主节点，再回滚从节点； 3、打包不重启服务，不重启设备        

客户反馈配置了syslog服务对接后，在syslog服务器未收到日志   1、在AF控制台抓包分析，发现AF未发出syslog日志数据包 抓包命令：tcpdump -i any port 514 or host [syslog服务器IP]  -s0 -nn -c 10   2、检查syslog服务配置，发现未勾选syslong需发送的日志模块配置   在设备【监控】【设置】【日志设置】【日志主机列表】编辑对应syslog，勾选需要发送到syslog服务器功能模块日志即可            

本帖主要讨论SANGFOR VPN丢包，使用ping测试指定长度的方式抓取数据包和分析数据包的处理过程。 前言： 这里说的ping测试带指定的长度是说的这样一个操作过程：在总部VPN设备找到分支的VPN用户名，然后取消掉压缩，在设备的后台带源去ping测试对端设备的LAN口IP，ping测试的时候指定长度为400，然后再同时抓取内网接口和外网接口的数据包。 这样做的原理是：取消压缩之后，内网和外网的数据仅有一个数据加密的包头，利用这个包头数值差异，我们可以对应上内网和外网数据包，然后就可以分析丢包和延迟问题。 【高危操作预警】本帖适用于，VPN流量比较小，不会抓包一秒成千上万个数据包。如果VPN流量特别大，请参考SANGFOR VPN丢包如何抓取数据包并分析数据包（第二式）   （一）如何抓取数据包 1、在抓包之前一定要记得先在总部找到对应的分支用户名点开编辑，取消压缩，然后断开VPN重新连接，切记这一点。PS：总部是DLAN620及以上的版本无需进行此操作。 2、在总部或者分支ping测试VPN对端设备的LAN口IP，例如分支是192.168.10.1，总部是192.168.1.1，分支去ping测试总部，后台ping测试的指令为：ping -I 192.168.10.1 192.168.1.1 -s 400 3、抓包指令参考：tcpdump -i any -nnv  \( host 14.254.254.134 or host 192.168.1.1 \)  -s0  -w /tmp/test.cap，其中14.254.254.134是对方公网IP，192.168.1.1是对方设备的LAN口IP。抓包的这个操作，总部和分支都需要抓。 （二）如何分析数据包 首先说明下我们分析数据包的目的，是为了找出内网的数据包对应的公网数据包，是否存在丢包或者设备不回包的情况。基于这一点，我们有下面分析。 1、使用wireshark打开总部和分支的数据包，在过滤条件栏填写：ip.len>=428 or ip.len<=550，过滤指定区间范围长度的数据包。 2、找到ICMP来回正常的数据包，并且找到ICMP的request的发起方，例如分支主动ping测试的，找到分支数据包中request数据包下面的公网VPN封装的数据包，记录下数据包长度。如下图，可以看出下面的公网数据包532长度的就是内网ping测试的数据包加密后的公网数据包。 点开IP层，可以看到这个数据包IP层长度是516，则过滤数据包条件可以修改为ip.len==428 or  ip.len==516，可以进一步减少杂包干扰数据包分析。 3、记录下第一步分支发出来request对应的公网数据包的ip.id，查看总部设备的数据包，看总部公网数据包中是否有这个ip.id对应。有缺失，这说明公网有丢包；如果没缺失，说明从分支到总部这个分支没有丢包，继续往下看。 再看总部是否有request数据包并且ip.id能对应上分支丢包的ICMP的request的ip.id。总部缺失这个request数据包，则说明总部设备解密出现问题，找产品专家；如果没有缺失的继续往下看。 总部有收到request数据包但是没有回reply，这种情况下找产品专家。总部回了reply的情况下，在看公网封装加密的回的reply包是否两端都有，如果缺失，则为公网丢包。如果有收到，则说明分支的设备解密失败，联系专家处理即可   NA          

客户有时候会反馈他的某某应用经过VPN隧道特别卡慢，需要我们做排查，有时候这些应用并不是因为我们的VPN隧道导致的，而是客户的应用本身就是这样子，而非我们VPN设备问题。 下面将介绍一种使用wireshark的I/O图标功能，判断应用交互的延迟主要出在什么地方。首先介绍，如何在wireshark中去使用I/O图标功能，在统计---I/O图标 选择TCP的应用 能看到上图的时间轴，客户的应用从打开到结束，大概持续了90秒作用，有柱子的部分都是在有数据包交互的，空着的地方则是没有数据包交互的。可以直接从这个I/O图标中判断这个应用有大量的时间应用层本身的闲置时间，也就是说这个应用慢是由于这个应用层本身决定的，就是要等待一长段时间，才有数据包交互。 当然，如果你眼睛视力比较好，也可以把数据包的时间调整从  自捕获起经过的时间，然后可以找到如下红框处，应用交互的过程，时间是跳着过去的。 PS：抓包过程，只要抓一次打开业务慢就可以了，应尽可能的减少杂包干扰。       NA，经验分享          

客户使用我司VPN设备组网，分支去访问总部的部分应用卡慢，这个应用是金蝶用友U8之类的ERP应用。并且经过确认，客户VPN隧道里面其他的业务都正常，就只有这些应用访问慢。   1、VPN隧道不存在丢包延迟 2、两端设备性能正常 3、抓取vpntun隧道里面，业务的数据包进行分析，发现这个业务数据包本身存在大量的小包，并且属于高交互型的应用。数据包特征，如下图： 此类金蝶U8用友ERP之类的应用，由于其业务的特性，多为高交互型的小包，VPN隧道延迟远高于内网延迟，所以会导致此类业务访问特别慢。 推VDI的远程应用来解决此类问题     解释说明两个问题，第一个是为什么其他的业务不会卡慢，为什么在内网访问不慢？ 1、举个例子，客户有10000字节的数据包，需要经过VPN隧道传输，如果分成50个字节一个数据包传输，那么需要200次。如果都是1500字节，那么7次就足够了。假设VPN隧道延迟是30ms，那么50字节的小包需要6秒才能完成，1500字节的，0.21秒就完成了，这样时间差距是巨大的。这就是为什么小包过多的应用为什么会访问慢 2、再举个例子，上面有提到数据包是高交互型的数据包。什么是高交互型的数据包，就是数据包里面能看到数据包是一个接一个的进行发送。正常的业务数据包，应该是连续发好几个数据包的，这样数据包传输效率更高 3、再再举个例子，假设总部内网延迟是2ms，公网VPN延迟40ms，同样的这种数据包数量，假设内网打开是2秒，那么公网VPN打开这个应用就是40秒，这个差距是巨大的。这个就是为什么同一个应用，在总部VPN打开很慢，在总部内网打开却很快的原因 综上1/2/3点，此类高交互型的小包在公网VPN隧道跑，就是会很慢，VPN隧道本身是没有解决办法的，只能是推VDI的远程应用来解决    

标准IPsec建立成功，第二阶段协商在一直不断协商并且每次都可以协商成功，如此反复。 1、通过后台日志logfs/sfvpn/ipsec_vpn查看，发现vpn隧道建立成功之后，我司设备立马发出了delete SA的消息给对端，随后就删除了第二阶段，后续又开始协商； 2、继续分析delete消息，发现每次delete掉的SA是上一次已删除协商的第二阶段SAID 3、再结合解密出来的数据包来看 从数据包里面可以看到，我司发出delete消息之后，对端里面发了二阶段的协商包过来，导致我司又开始了二阶段协商并成功建立，因此就进入了循环，我司建立成功之后，又再次发出了delete消息。 1、对端设备收到我司发出的delete旧隧道的SA信息，导致第三方设备清理了当前隧道SA，引起重协商导致的问题。 1、协调第三方协助分析，为什么收到旧隧道的delete的SA信息，会删除当前隧道SA；     PS：建立新隧道，删除旧隧道，发delete消息是标准协议。    

       大家好，最近发现各位小伙伴在处理VPN问题的时候，一直不知道怎么去查路由表，或者不知道使用什么命令去查看路由表，因此这里会详细给大家介绍适用的方法来解决问题！        首先先介绍一下我们常用的查看路由的命令：        route -nn  ：查看的是Linux系统路由，并非是VPN路由；        ip rule list ：查看的设备所有路由表项，这里才包含了VPN路由表； 第一节：如何正确认识IP rule list；         在了解到VPN路由表是包含在rule list里面之后，大家后续就可以正确认识路由了。那么这里就不再介绍route -nn表了，这个可以百度查询，这里会详细介绍给大家ip rule list。         先来给大家看一下 ip rule list 张什么样子的，如下：                 第一列：表示各个表项的优先级，数字越低，优先级越高；         from X：all表示匹配源IP是所有，图例中from 10.2.10.106表示匹配的源IP是10.2.10.106才会匹配上表20         lookup X：表示命中的表号，这个标号就是我们接下来需要查看路由的关键；         PS：匹配路由规则：从上到下，按照路由表优先级关系，先必须匹配源IP，源IP匹配之后，再进入对应表号匹配目的IP；如果第一张表"local"未能命中目的IP，则继续匹配第二张表"24"，同样第二张表也会先匹配源IP，如果源IP匹配，则进入匹配目的IP，如果源IP不匹配，则继续匹配第三张表"25"，以此循环查询；         在sangfor产品中，数据包正常转发数据查路由都会是查总表ip rule list，那么这里，我么只要找到对应的VPN表即可； 第二节：如何查询VPN路由表；          上面已经介绍了ip rule list的作用，接来下就来看，VPN路由表如何查询；          在WOC、MIG、SSL、AC、AF产品线各个对应表项如下；                  PS：          1、26、36、240对应的是标准IPsecVPN路由表；27、37、241对应的sangforvpn路由表；          2、SSL目前还没有6.20的正式版本，都是定制版本，定制版本的是36和37；AC的老版本可以根据实际设备查询。          在介绍完路由表号之后，那么接下里就可以使用命令“ip route show table X”来查找对应表里面的路由了。          如下是找了一个dlan620版本的WOC设备演示：                  192.168.4.0/24 :是对端sangfor vpn网段，即目的网段；          dev vpntun :经过vpntun转发出去 第三节：排查路由转发问题思路；          在排查客户问题过程，经常会遇到数据包转发不对，或者从别的网口出口，没有在vpntun口抓到包这种问题。          1、先ip r g X.X.X.X查看路由的下一跳是否正确；          2、当下一跳不正确的时候，此时需要ip rule list 看一下设备有哪些表项；          3、然后通过ip route show table X | grep 192.168.4.  ；               grep 192.168.4.：意思是过滤出来192.168.4.网段路由，有时可以扩大子网，过滤192.168.或者192.这种。               PS：这里需要特别强调一点，如果我们需要访问的路由是192.168.4.0网段（查看图一ip rule list），但是通过查路由表24过滤出来的网段是192.0.0.0，通过路由表37过滤出来的是192.168.4.0，这个时候是会匹配24表的，以为24表的优先级更高。将到这里，有小伙伴就有疑问了，我们平常学习的路由不是说最长掩码匹配嘛，这里有个前提路由匹配规则，先匹配优先级高的表项，同一表项存在多条路由，再按照最长掩码匹配的。       NA，经验分享          

我们常说某某设备存在性能问题，那如果是设备性能不足，会导致哪些问题呢？设备性能不足，会导致上网卡慢，网络延迟大，VPN业务相关卡慢甚至业务无法正常使用。常见的性能不足，表现出来的现象就是CPU高，经过设备转发延迟大，经过设备网络传输速度慢等。 如何判断设备出现性能不足问题 1、出现CPU高 CPU多核存在某一个单核CPU高也属于此类问题，可以看到设备的CPU使用率长期处理90%以上，甚至是100%。以WOC为例，查看CPU的的指令是mpstat -P ALL 2，可以看到CPU实时的使用情况。如下图，可以看到CPU使用率最高的时候达到了100% 如果是CPU高的问题，请进一步的查看top，看是不是lmdlan占用的CPU高，如下图。如果是，可以推断是lmdlan占用的CPU高。 2、抓取数据包分析设备转发是否瓶颈 经过设备转发之后，出现了延迟和访问慢的情况，有些时候连控制台都打不开的场景，可以往设备转发性能这块来排查。此类问题的排查，主要是抓取对应接口的数据包（上网的流量抓ETH0、ETH2，VPN的流量抓取ETH0、ETH2），分析数据包得出结论。以排查VPN转发存在性能瓶颈为例，可以在流量大的时候，记录最大流量的数值，以及抓取vpntun接口的30000个数据包保存下来（MIG产品线5000个数据包即可）。数据包保存下来之后，分析数据包是否存在大量的异常数据包，比如很多SYN包，分析数据包长度分布情况。提供给对应的产品专家，进行更详细的性能评估。如下图，在wireshark的统计-分组长度，就可以得到数据包长度分布情况： 某些情况下，会发现流量不大，但是客户经过我们设备就是卡慢。抓取数据包之后，可以在wireshark中【统计】-【对话】中查看是否存在明显的异常流量，如下图存在大量192.168.0.103去访问外网的22端口的异常会话，像这种流量明显就不是客户业务，属于异常流量导致设备性能不足       NA，经验分享，不涉及          

此文档一般应用于分析设备性能问题，转发流量是否达到设备的性能瓶颈，那么，接下来小伙伴们就跟着步骤一步一步操作吧！ 1、获取到设备的黑匣子日志，把\wanacc\blackbox\1-Mon\since-100602-161816\net文件和脚本net_analysis.sh上传到同一目录（脚本可见附件获取）；     PS：其中1-Mon目录是根据大家要分析日期来指定，这里仅做示例； 2、进入到上传脚本目录，给脚本加执行权限   chmod +x  net_analysis.sh     net_analysis.sh.zip ( 0.00M  ) 3、通过输入./net_analysis.sh net eth0执行出结果（接口可自己更换，具体要看哪些接口，可以使用ifconfig命令输出设备所有接口名字），当前目录会生成.csv文件 4、打开文件有这样三列数据     ps：如果发现该列值有负数，会出现图表峰值错乱，可以删除表内负数值即可； 5、选中这三列，点击插入,选择图表6、根据得出结果分析 纵轴单位是字节B/s 横轴单位是时间分 系列1 ： 发送流量 系列2 ： 接收流量 系列3 ： 网口转发总流量（发送+接收）       NA，不涉及          

新架构（dlan6.2.0及之后）第三方数据包解密 1、进入设备后台以及用Xshell进入后台，进后台的步骤类似pshell，差别不大。 2、利用Xshell的日志记录功能，记录下调试日志信息 3、若是crt软件，则右击会话，点击会话选项； 4、在日志文件中配置要保存的路径文件名，点击“确定”保存。然后关闭CRT，重新连接会话后就能记录日志了。 5、AC产品需先进入cd /ac/module/sfvpn/sbin/ 目录 6、然后执行 ./dp-debug listparent ，这条命令只打印一次调试日志； 7、如果是woc/mig/AF/SSL，无需步骤5，直接敲命令dp-debug listparent； 8、可以通过while :;do ./dp-debug listparent;sleep 10;done 循环打印日志，打印完按ctrl+c终止。 9、xshell或crt在打调试日志的前，同时抓包，抓对方的公网IP即可。 10、等vpn连接过程完成或断开后，停止抓包，停止调试日志。 11、可能抓到很多协商包，调试日志也很多，可以先随便选择第一个IPSEC的协商包，aggressive包 SPI全为0 的为第一个IPSEC的协商包。右击作为过滤器选中，就可以过滤出所有第一个IPSEC的协商包。 12、然后随便选择一个IPSEC的协商包，复制isakmp.ispi值 13、到调试日志文件中去搜索； 14、找到对应日志中的 skeyid_e : 183fe68415ebd2e4fd3a3b0c92019b1a95063a335994d91d 15、调试日志中Cookie_i对应 SPI 数值：ecae42bc06ede890 skeyid_e对应Enckey数值： 183fe68415ebd2e4fd3a3b0c92019b1a95063a335994d91d 16、过滤12步选择的协商包数据流； 17、解密，随意选中一个数据包，右键，选择“协议首选项”----“IKEv1 Decryption Table”，将第15步收集的数值填写进去。 18、看解密效果。 数据包以及1981调试日志，各位可以去尝试解密过程。       NA，经验分享，不涉及          

目前标准IPsec第二阶段解密配置从dlan6.2开始做出调整，在dlan6.2版本之前，解密方法如下   【高危预警】使用telnet或者是gettelnet1981.sh打1981调试日志，一定要注意VPN连接数以及VPN流量，理论上来说VPN流量超过20Mb，就很有可能导致设备CPU100%，导致VPN隧道延迟业务卡慢。请在业务空闲期使用，或者提前将风险告知客户，授权后再操作   gettelnet1981.rar ( 0.00M  ) PS：gettelnet1981.sh，这个脚本对比telnet，优化了运行时间，避免长时间跑telnet占用CPU的问题。在一定程度上，能降低客户业务影响。但是理论上，还是一样的有可能会导致设备CPU100%，所以使用前，还是需要和客户说明该操作风险以及征得客户操作授权。   1、使用shell类型的工具进入后台 2、上传gettelnet1981.sh到设备的/sbin/目录下，执行gettelnet1981.sh，十秒终止，输出的1981记录在/var/tmp/telnet/目录下。如果觉得十秒时间太短，可以执行gettelnet1981.sh  /tmp/  30  ，输出的1981记录在/tmp/telnet/目录下，执行时间是30秒，这个时间参数可以自己调整。gettelnet1981.sh脚本见附件，需要解压缩。 3、在打调试日志的前，同时抓包。抓对方的公网IP即可。 4、等VPN重新建立成功之后，停止抓包，停止1981的调试日志。   5、打开1981日志搜索关键字Enckey，再从数据包第一个IPSEC的协商包中获取SPI值   6、Enckey数值：4648c2886302c526ca2f50b8bb91f2a8f33b2a4dd35f22ec   SPI：fc328a288ee280b7   7、解密，随意选中一个数据包，右键，选择“协议首选项”----“IKEv1 Decryption Table”，将第8步收集的数值填写进去。   8、看解密的效果 数据包以及1981调试日志，各位可以去尝试解密过程       NA，经验分享，不涉及            

VPN监控包主要应用于VPN不定时丢包延迟、VPN中断这几类问题，打监控包的目的主要就是获取到出现问题的时候对应的数据包，以便于分析问题。下面将介绍VPN监控包打包之后，获取到的监控包有哪些东西可以查看，如何来分析问题当时的情况，并且将通过一个实例来讲解怎么去分析问题的 如下图，是一个VPN监控包产生的文件 对于我们分析问题，VPN监控包只是一个辅助工具，还有一些其他的信息需要收集的，如： 1、总部设备和分支设备与北京时间的差距 2、总部和分支网络拓扑 3、如果有VPN日志的，需要提供出现问题时间点的总部和分支的日志信息   如何来使用监控包分析问题： （1）先确定好出现问题的时间点，这个可以通过咨询客户确认大概时间以及VPN日志确认（VPN中断问题可以通过VPN日志确认）。可以通过VPN监控包中的vpnstate.log、vpnwatch.log、vpn_ping_detect_x.x.x.x.log判断VPN状态和VPN丢包延迟的时间点 （2）再根据时间点，去找总部和分支的数据包，总部和分支的数据包需要能在同一时间点对应得上，否则两份数据包没有对比的价值，对比数据包是否一致可以查看ip.id是否一致来做判断 （3）分析数据包判断问题原因   案例： 问题现象：客户总部所有的分支，不定时的出现所有VPN中断 处理过程： 1、根据总部vpnwatch.log找到出现不通中断的时间点，以及对应时间点的数据包 2、找到总部数据包之后，再去找分支的数据包，客户总部设备比分支快了48分钟左右，则分支对应总部的数据包，应该是这样的： 3、进一步对比数据包中的内容，能看到ip.id是对应得上的，说明两个数据包是没问题的。 4、进一步分析数据包，下面的红框内有SYN三次握手的数据包，这里能说明VPN是这个时间点重新连接过，往上看，能看到分支（右）发出去的数据包总部有收到，但是总部回包分支没有收到，也就是说中间存在网络问题，导致分支没有收到总部的数据包，造成VPN探测包超时中断以及断开之后VPN连接不上。         NA，经验分享，不涉及            

以前老的分析VPN丢包问题，判断数据包是否丢在了中间网络，或者判断数据包是否存在乱序问题，是通过一个个ip.id看数据包，相当的浪费时间和废眼睛，下面介绍如果利用文本对比工具快速的定位数据丢包乱序问题。   步骤1：首先你的PC上要有文本对比工具，在这里推荐使用Beyond Compare。 步骤2：先把你要分析的数据包抓下来，比如我要判断两个设备直接的VPN丢包是否丢在公网，那我就把两端的交互的数据包同时先抓下来。然后通过wireshark导出数据包，如下：先把ip.id项放到最前面： 然后再导出数据：   步骤三：   用对比工具打开导出的csv文件，最开始两个数据包的ip.id是对不齐的，这时需要先把两边数据的ip.id对齐。如图，选择左边第一个ip.id=28257的数据包，右键点击对齐方式，如下图： 然后再去右边的数据包找到ip.id=28257，左键点一下就会自动对齐   步骤四：   对齐之后，找丢包，如下图很明显的就发现了左边   PS 乱序的问题也可以参照类似的思路导出看即可       NA，经验分享帖，不涉及          

客户使用我司设备和第三方VPN设备对接IPSEC VPN，第一阶段对接上了，第二阶段对接不上。 提示：检查出,入站策略中连接的双方配置是否一致 1、标准IPSEC第二阶段对接异常，并且日志明显打出需要检查第二阶段出入站配置是否一致。如下图：是第三方的配置，检查和我方一致 2、再仔细查看IPSEC的日志，发现日志端确实是存在异常，如下图，我司响应对方协商的情况下，正常来说这条对方的过来的32位掩码的网段，掩码应该是255.255.255.255才对，对方发过来的是0.0.0.0。   对方发过来的网段掩码是0.0.0.0，而不是255.255.255.255，导致我司设备感兴趣流的网段校验失败 改成30位掩码或者24位掩码的方式去对接 无 否  

客户标准IPSEC组网，对端是思科设备，VPN隧道起来之后最近一段时间出现VPN隧道丢包，丢包的时候实际上是持续性的丢包，每次出现此类持续性丢包的时候客户业务就断开了。 1、确认丢包的现象，不是偶发性的丢包，而是持续性丢包，并且是在持续性丢包的时候，客户业务会完全受到影响。这点很重要，因为持续性丢包，要么就是一段时间网络完全不通了，要么就是VPN隧道整个就断开了。而偶发性的丢包，就是网络零散性的丢几个数据包。2、在两端设备同时抓取IPSEC对端公网的数据包，等待现象出现。3、分析抓取的数据包，能发现在ICMP持续性不通的时候，公网封装加密的ESP数据包中SPI值发生了变化，怀疑VPN出现中断重连导致的SPI值变化，如下图： 4、进一步查看IPSEC日志，发现出现问题的时间点，IPSEC隧道存在DPD超时中断的情况，如下图： 5、再结合思科这边抓取的数据包，能发现我司发过去的DPD数据包，对方明显有收到但是没有回DPD数据包（PS：补充一个知识点，DPD数据包是封装在information中的），如下图：     DPD超时中断，导致IPSEC隧道内持续性丢包，根本原因是对方思科设备没回包，需要思科端详细排查原因 根本原因是对方思科设备没回包，需要思科端详细排查原因 无  

客户有台数据库服务器未启用pdlan客户端时业务使用一切正常，启用pdlan客户端后会导致门户网站到某公司公司上的一个业务网站单点登录失败，直接输入某公司公司登录也是失败。   1、先跟客户沟通这个业务认证流程。沟通结果是认证流程是门户网站点击后会自动到阿里上的应用服务器上，然后阿里应用服务器会到阿里数据库服务校验某公司公司名和密码，如果认证某公司公司名和密码一致则登录成功。现在不成功，说明问题出现在应用服务器和认证服务器之间。2、 未启用PDLAN客户端，测试数据库服务器到应用服务器通信情况： 8445460b8c9f7e1c75.png (177.92 KB) 3、数据库服务器启用pdlan客户端后，测试数据库服务器到应用服务器通信 3465960b8ca1ad6928.png (117.8 KB) 4、数据库服务器启用pdlan客户端后，查看路由表信息，结果如下： 5786260b8ca571f323.png (299.48 KB) 由此可以看到启用pdlan客户端后，***.***.*.*网段的数据进入VPN隧道了，所以导致某公司公司法与应用服务器通信。5、查看VPN本地子网，在本地子网中存在***.***.*.*网段，如下图： clipboard.png (90.33 KB) 6、某公司公司本地子网后，再启用pdlan客户端测试业务访问结果一切正常 添加的本地子网的中包含对端服务器网段地址，简单说就是地址冲突 因为阿里服务器上地址网段没法改变，所以只能某公司公司本地子网包含服务服务器地址网段。  

woc网关模式部署，和第三方标准ipsec隧道建立后不通。   1. 查看标准ipsec隧道是稳定的，没有中断重连的情况。2. 发包源目ip有匹配感兴趣流定义的网段，未配置内网权限和防火墙规则。3. 进一步检查配置发现配置了一条基于wan1口的全端口映射规则，这会导致esp协议流量也会匹配此映射规则，客户改成对指定端口做映射后恢复正常。 84706607bdf7e5af52.png (117.65 KB) 客户配置了一条基于wan1口的全端口映射规则。 客户将wan1口全端口映射规则改成只对指定端口做。  

使用SSL设备和第三方设备对接标准IPSEC第一阶段协商失败，日志提示“请检查网络是否连通，如果联通请检查【xx】中的高级设置里面的各项是否和对端一致”   1.对比两端配置一致； 2.尝试让对端主动发包，在本端未发现有任何连接的日志； 3.在SSL设备的控制台【系统维护】-【控制台命令】使用tcpdump抓包，由于设备是网关直连公网，抓包条件为tcpdump -i eth2 host  对端公网ip -s0 -w ； 4.查看数据包发现对端有回复IPSEC的第二个协商包； 5.检查设备的控制台设置【IPSEC VPN设置】-【基本设置】-【VPN监听端口】设置的为500端口 508015f2170a78bc9a.png (60.49 KB) 6.将该端口修改为为默认的4009端口后，标准ipsec对接成功。ps：修改端口为高危操作，会导致ipsec服务重启，所有分支重连   控制台设置【IPSEC VPN设置】-【基本设置】-【VPN监听端口】设置的500端口修改为4009端口  

单台win7电脑使用安全管理员登录控制台会提示“证书校验失败” 881445ebe1dbb7fa9c.png (30.09 KB)   1、更换浏览器登录还是一样的提示2、重置ie浏览器测试依然会提示证书校验失败3、将USB-KEY驱动和导入控件卸载，重新以管理员身份安装 99005ebe1d842787d.png (170.48 KB) 426465ebe1debadb91.png (119.99 KB) 4、测试可以正常登录进控制台   卸载电脑上的KEY驱动和导入控件，重新以管理员身份安装  

打开PDLAN控制台时提示：读取配置信息（LanService.vpn）发生错误！错误号：10，PDLAN程序无法正常运行   PDLAN安装目录中的LanService.vpn文件被误删除导致 卸载PDLAN客户端后重新安装即可，PDLAN客户端链接https://bbs.sangfor.com.cn/plugin.php?id=service:download&action=view&fid=100000000873964#/100000013492656/all