AF升级8095后巡检报警[config] init：error(sagfor support) [config] init：error(sagfor support) 1.cat /proc/sys/net/netfilter/nf_conntrack_count 查看当前设备连接数 cat /proc/sys/net/nf_conntrack_max 查看设备支持的最大连接数 2.查看进程状态 check_service.sh 这里在排查到过程中发现dataplan和cfg-center进程异常，实际上是因为没有使用su - sangfor命令进行提权导致的显示报错  提权后显示正常 3.查看core目录下是否有大量文件产生  下图显示的结果为正常现象 无 经过排查判断为误报 无 否 注意流程性的操作登录提权不要遗漏 设备连接数，服务进程，core目录  

客户反馈AFsyslog外发的日志在AF查询不到 1、检查防火墙对应时间前后日志正常，根据syslog外发日志进行查询，查不到相关日志 2、对syslog的日志里的目的作为日志查询的源进行查询，可以查到相关日志 保护客户端的日志源目地址会反过来记录，AF8017-8085都存在相关问题 如果查询不到相关日志，建议可以对源目地址反向查询日志          

打开迅雷或者使用迅雷下载后会有一段时间的断网过一会之后就好了   无 1.先对测试PC数据流进行定向直通分析，分析得出结果显示数据流被ddos防护拦截 2.客户配置的内网到外网的ddos防护策略以及详细的安全日志信息 使用迅雷下载时的安全日志告警 打开迅雷时的安全日志告警显示为端口扫描工具 迅雷打开和下载时的流量请求超过了ddos防护中设置的阈值 这里IP扫描和端口扫描的阈值最高是4000不能修改超上限，其他的攻击类型可以修改超过4000 关闭端口扫描和UDP洪水攻击防护后测试PC可以正常打开迅雷和使用迅雷下载 无 否 无 ddos防护策略  

AF新架构双机主备主机通过心跳口跳转到备机报错，报错internal server error如下:   1、排查心跳口是否开启WEBUI，以及PING，并尝试关闭后重新开启，依旧无法访问。 2、尝试PING对端心跳口，不通。 3、通过直连带外管理进入备机，主机点击【管理对端设备】，同时备机抓包发现源IP是vpntun口的IP，且无回包。 4、后台确认，vpn路由也发布了2.2.2.0相关的路由。导致内核的路由中有vpn和直连冲突 下图为VPN路由，在表37中 下图为直连路由，在表251中 在未打业务标记或带外管理标记的情况下 ，37表优先级比251表高，所以会先查到37表 。导致源地址是vpntun口地址。   内核往外发包的时候需要先走内核协议栈（包括查内核路由表来填源ip），包送到网口决定发包之后，会被dp接管，dp再走正常的转发报文的流程（包括查路由决定出接口） 在此问题中，直连路由静态路由都在251表内，vpn的路由在37表，在未打业务标记或带外管理标记的情况下 ，37表优先级比251表高，所以会先查到37表。Ps:如果打了带外管理标记的网口则只匹配内核路由。 由于在内核匹配到了37表中的路由，所以内核决定用1.61.xx.xx(vpntun口的IP)向2.2.2.1发送请求。数据转发到dp，dp根据正常的报文转发流程进行转发，dp决定的走直连路由去往对端。导致访问心跳口的时候，出接口没有错，但源IP是1.61.xx.xx 分支VPN发布的本地子网和总部的心跳口的网段，不能冲突。任意修改一个即可          

8.0.48上传SP_AF_OS_Spree_01.bin实际显示的是SP_JG_20的补丁包，再次重新上传报错上传失败 无 1.重复上传SP_AF_OS_Spree_01.bin无显示错误但是提示上传失败 2.更换浏览器上传安装成功 浏览器环境导致 更换浏览器进行补丁包上传 无 否 无 无  

触发了临时封锁，行为日志-联动拒绝里面没有记录   ①防火墙外网口抓包确认数据包达到了防火墙，并且源ip在临时封锁名单 ②查询行为日志—应用控制日志—联动拒绝日志 查不到日志记录 手动添加到临时封锁的ip，再次匹配到临时封锁的ip的时候，记录到的日志为行为日志—应用控制日志动作为拒绝的日志。   因为触发安全策略而被联动封锁添加到临时封锁ip中的ip，再次匹配到，会记录到行为日志—应用控制日志—联动拒绝中。 手动添加到临时封锁的ip，再次匹配到临时封锁的ip的时候，记录到的日志为行为日志——应用控制日志动作为拒绝的日志。查找动作为拒绝的日志。          

配置策略限制单用户软件更新流量不生效下列是具体配置和问题现象   无 1.调整流控策略优先级为最高测试还是有异常凸起的流量 2.查看配置文件类型配置虽然把选项全部构选上了但是由于有的文件类型没有选项所以需要保持默认而不是全选 文件类型勾选了全部选项没有保持默认 将文件类型改为默认即为空 无 否 无 无  

打开ips上面有日志，跳转到其内置数据中心上面无安全日志   ①检查IPS界面业务安全，发现里面记录了相关日志，也能看到具体的日志信息   ②查看内置数据中心，查不到相关日志记录 访问IPS的时候使用的是51443端口进行访问。51443端口用于管理对端设备的访问，因此使用xx.xx.xx.244:51443登录的时候，实际上访问的是双机中的对端设备xx.xx.xx.245，显示的日志也是设备xx.xx.xx.245的日志。但是这个时候跳转到内置数据中心的时候还是备控xx.xx.xx.244的内置数据中心，所以两个界面的日志不一致。 不要带51443端口去访问IPS，这是IPS的日志和其内置数据中心的日志是一样的。          

客户反馈需要在防火墙中加白云WAF对应IP，但加白后，访问业务会跳转到防火墙的WEB页面，导致业务无法正常使用。对应接口已关闭WEBUI选项。   1、检查配置，发现接口有多个IP，部分IP有做DNAT映射业务，部分IP没有。且接口已关闭WEBUI   2、云WAF是代理访问，加白云WAF的IP后，客户的访问都被云WAF代理了，此时再访问接口上的IP，即使没有开启WEBUI，也会显示防火墙的WEB页面。 WEBUI是防火墙根据本机控制策略去限制能否访问的，加白某个IP之后，即使没有开启WEBUI，这个IP也可以访问。因为加白之后也会跳过本机控制策略。而此时再想让云WAF的IP无法访问到防火墙的WEB页面，也不能通过ACL去拦截。 添加一条没意义的DNAT，随便将内网不存在的服务，映射到防火墙接口IP对应的443端口，将443端口占用。 此时白名单IP访问接口IP的443端口就不会跳转到防火墙的web页面，从而间接的拦截白名单IP访问WEBUI。          

AF和SIP对接，AF测试连通性正常，但是SIP上没有AF的信息 1. AF能正常测试，找寻网络拓扑图发现中间有什么设备 2. 中间发现有个AD，做了源地址转换，而且是内网全部地址的转换   3.针对源地址转换加一条DNAT映射回去，或者在源地址转换中去除AF的地址 中间设备做了SNAT 做一条对应的DNAT转换回去          

客户反馈服务器那边流量突增和降低很高，但是AF上接口吞吐率流量显示很平滑。 1. AF日志记录是非wan口到wan口到流量，分析流量是不是在非wan口到wan口的流量 2. 根据服务器这边的流量去分析黑盒日志这段时间接口的流量 3. 查看接口的流量值 需要考虑别的设备记录流量日志的平均刻度值，我们AF是五分钟一次计算流量的平均值，这个客户这边交换机是一分钟记录一次流量值，且我们的AF是五分钟记录的平均值，所以波动并不大 无需处理，正常流量上报          

客户反馈原地址转化配置正常，可以上外网，但某个EXE应用程序无法使用。切换手机热点后应用可以正常使用。   1、经确认无法使用的应用切换热点后正常使用。怀疑内网上网环境拦截。 内网拓扑图为 PC-核心交换机-AC-AF-运营商 2、建议AC，AF添加全局直通以及白名单。添加后依旧无法使用。并尝试物理跳过AC，问题依旧。 3、怀疑IP地址在AF之前有做源地址转化，经抓包确认，未做源地址转化。 4、怀疑运营商问题，尝试切换运营商线路，问题依旧。 5、尝试将PC直连AF，配置snat，路由，随后正常访问。（此时怀疑核心或防火墙内网口异常，内网口是聚合口） 6、尝试获取应用程序需要访问的IP，使用network monitor抓到应用程序对应请求如下 获取到PC需要与某个域名进行通信。 尝试加白域名，且加白对应IP地址。仍然无法正常使用。 查看会话，地址转化正常，路由匹配正常。 6、经过wireshark抓包，发现在与A域名解析的A IP通信过程中，PC会主动外发rst请求包。 怀疑是内网口聚合口分片传输数据导致。客户聚合口为负载hash，经沟通，客户不允许试拆聚合口进行测试，也不允许使用主备模式。 7、经研发排查，分片正常，在wireshark的数据包中，发现PC除了会与A域名解析的115.4的443通信，还会和115.3的9443端口通信。   经排查PC访问115.3的9443端口匹配上了客户配置的目的地址为ALL的双向地址转换，随后数据包发给了内网口。导致的无法正常使用某个应用程序。   network monitor获取到的EXE与某个域名通信不准确，抓包的时候只关注了对应域名解析出来的IP，所以漏看了数据包。 建议当面对应用程序需要抓包分析的场景时候，可以使用多个工具结合。将每个工具的优缺点结合起来抓，会更准确。 1、wireshark；在网络层抓的全面，但是网口流量太多了，没有办法根据进程定位流量，只能根据程序外发请求的时间来缩小流量范围。可以尝试在环境纯净的虚拟机里面抓。但是如果域名解析的有多个IP，客户环境与自己本地虚拟机可能存在解析差异。 2、TCPView ；TCPView可以查看某个进程的TCP\UDP连接情况。 3、Process monitor 添加过滤器，过滤operation为tcp/udp send/receive 4、proxifier+fiddler，适用于HTTP/HTTPS场景，使用proxifier强制将应用程序的流量发至fiddler，需要添加fiddler的https证书才能抓到https流量。          

AF配置开启多线路定制策略以后sangforVPN对接不成功 1、查看分支的日志提示“隧道在22秒内断开，VPN可能无法正常建立数据通道” 2、测试总部的4009端口地址稳定无丢包，更换对接协议也不能对接成功 3、客户反馈是总部开启多线路定制策略以后对接不成功 4、沟通关闭多线路定制策略以后，vpn对接恢复正常 总部开启多线路定制策略，选择了对接线路，对端线路是线路1，实际上对端是使用的wan2，是对应的线路2，导致总部拒绝连接 1、关闭总部多线路定制策略解决 2、或者总部多线路定制策略，对端线路选择线路2解决 该配置为全局配置，如果是总部设备，谨慎操作！！！   内部确认多线路定制策略，是可以控制分支只允许哪个线路接入总部，如果配置错线路，会导致分支对接不上      

客户访问业务不通   ①在内网口抓包发现业务流量确实到达了eth7口内网口，但是在外网口eth1抓包没有抓到数据包 ②show session发现会话匹配也是从eth7口进，eth1口出。且匹配到允许的ACL策略。 ③开定向直通发现可以正常访问业务，但是没有产生任何日志记录。 ④查看客户有开通云威胁情报网关的服务，将此业务进行排流处理，发现可以访问业务。 ⑤查看云威胁引流线路，客户一条引流线路走eth1口，后台查看会话发现引流流量有时走了eth8口。 ⑥根据路由测试，发现客户的静态路由，有一个默认路由走eth8。相关业务流量引流通过eth8口发出了，导致没有回包。 AF自身上网，没有设置local域相关的路由时，匹配到目的路由，走eth8口将相关业务流量发送到云端，但是设置的线路是eth1口，导致没有回包。 做一条local域的策略路由，源区域选择local域，源ip选择引流线路出接口eth1口的ip，目的ip选择pop节点。使引流线路正常走eth1口出去。 不影响业务        

在安装8095前置包报错exit status 1 1.进入后台df -h查看磁盘的使用情况 发现是/sfdata/log占满具体清楚方法参考https://support.sangfor.com.cn/cases/list?product_id=13&type=1&category_id=2019&isOpen=true 2.清除对应目录空间后可能第一次重新安装补丁包还是会显示报错，需要重新安装补丁包刷新浏览器再试试 /sfdata/log占满 清除对应目录的磁盘空间 无 否 无 磁盘空间使用情况  

ARP绑定提示加载配置文件失败   1、查看F12返回信息，cgi返回为200OK； 2、cgi调试提示依旧 3、查看原始配置文件无异常 4、关闭sangfor_waf测试依旧 5、经过研发协助代码确认，判断由于对应IP与聚合口同段，而聚合口不支持静态ARP绑定，因此存在报错；   聚合口不支持静态ARP绑定，因此存在报错；          

AF对接SASE-XDR部分域名连通性探测失败 前端页面检测几秒种没有检测到就会认为连通性失败   1.备份/sfos/system/etc/af/xdr/xdr_domain.ini 文件 2.修改 vi /sfos/system/etc/af/xdr/xdr_domain.ini  count修改为1，domain_0后面修改为localhost 3.接入成功后将后台 /sfos/system/etc/af/xdr/xdr_domain.ini 文件恢复回来 无 是      

云鉴误报，情报同事删除对应情报后，依旧存在同样的误报   登录到后台查询云鉴缓存记录并删除对应的云鉴缓存 ①使用sls_tool -H查看使用方法 ②查看具体对应标签 查询目标：[lib]——>(1):domain<local domain> (2):domain<hot threat> 安全标签：       [val]—> 查询内容      [action]—> (1):query  (2):insert  (3):delete  (4):clear动作 查询：[src]——>(2)云查 ③根据误拦截的ip查找对应云查的内容，如果有云查有缓存记录，会出现相关的信息。 sls_tool -L -s 2 -v ip -a 1  #查询确认ip是否在库中 ④找到误报ip的云查缓存记录后，根据对应动作进行删除 sls_tool -L -s 2 -v ip -a 3  #删除该缓存 ⑤sls_tool -L -s 2 -v ip -a 1  #再次查询，确认是否删除成功 云鉴缓存的作用： 如果用户第一次没有被云鉴拦截可能是因为本地库里面没有这个ip，当获取到用户访问的ip后，云鉴会联合云端进行搜索，锁定为恶意ip，并返回对应的安全日志，同时本地云鉴里面也会保留此信息，用户第二次访问就会被就会被拦截。删除对应情报，后台依旧有缓存的记录，同样的ip访问后，依旧会被拦截。 到后台查到云鉴缓存的记录，然后进行删除          

老架构，开启策略路由链路探测，链路探测显示故障，导致客户从外网访问不了内网业务。 抓包查看，未源进源出，导致业务访问异常。 禁用开启链路探测的策略路由，业务恢复。     业务访问不通，抓包查看未源进源出   新增第2条策略，业务访问异常，抓包查看，未匹配源进源出。           进是5口进的，出是从13口出去的 2、 查看新增的第2条路由，和业务访问没有影响（新增的策略路由目的IP为固定的）。并且这条策略路由链路探测显示故障（代表这条策略路由没生效） 3、查看后续的策略路由，是符合入接口的源进源出条件的。 4、问题就出来了，为什么新增了一条失效的路由会导致入接口匹配不上源进源出？？？ 5、 进行路由测试，对应流量是通过默认路由出去的。 6、关闭第2条路由链路探测，依旧访问异常 7、 新增一条策略路由（目的地址选择不存在的策略路由），目的是生成源进源出路由。业务恢复 8、此时想让问题复现，彻查根因，于是禁用新增的第1条策略。测试发现问题未复现 9、此时开启第2条链路探测，问题复现，此时反馈研发。 10、根据研发排查，第一次关闭链路探测时，配置未下发导致第2条策略路由依旧是失效状态。   关闭策略路由链路探测时，设备配置未下发，导致策略路由依旧是失效状态。 然而为什么这条策略路由失效会导致不符合源进源出条件（其他策略路由配置是符合入接口的源进源出的）： 老架构源进源出条件：   入接口有WAN口属性   入接口必须有对应的策略路由；   如果入接口是多个策略路由的下一跳，则需要保证所有策略路由中展示的下一跳IP一致 源进源出匹配原理： 请求包   数据到达AF外网口，记录入接口信息，判断如接口是否符合源进源出条件   符合就记录匹配的tid（同一个接口，同一个下一跳只生成一个tid）不管有多少条策略路由，只要是同一个接口，同一个下一跳就只生成一个tid   不符合条件就按来回数据包正常查询路由机制，再通过静态路由往下发   回包   应答包到达AF内网口，根据会话信息中记录的tid查询tid信息，判断tid是否失效   如果这个tid只要有一条策略路由是失效状态，那么这个tid也就失效了   如果tid生效就从记录的接口发出去   不生效就按照正常路由匹配出去 本问题中，链路探测故障导致第2条策略路由失效。因为和第2条策略路由满足同一个接口，同一个下一跳的其他所有策略路由只会生成一个tid。第2条因链路探测导致失效了所以就导致这个出接口的tid也就失效了。从而导致应答包没有匹配到源进源出，匹配其他路由出去了。 关闭策略路由链路探测或者配置一个正确的链路探测（保障路由不会失效）          

客户侧有一个业务过AF（虚拟网线部署）会出现无法下载的情况，下载一会就会提示下载失败。       1、客户侧测试，针对服务器IP加白，可以正常下载，尝试关闭服务器对应的SSL解密，发现业务就正常了，说明问题跟AF的SSL解密有关系。 2、开启解密的情况下，针对AF内网口和外网口抓取下载异常过程的数据包，分析AF的内网口数据包，能发现客户端这边发了很多TCP 0窗口的数据包，随即服务器主动发了RST包，导致下载提示下载失败。 1、客户端发送TCP0窗口，这个意味着客户端这个方向数据流量接收不过来了，TCP的接收窗口不够用了，所以客户端会发送TCP ZeroWindow给服务器，通知服务器先缓一缓发送数据。 2、AF做解密之后，实际上AF内网口跟服务器之间交互的数据包，就是AF代理之后的数据包，不是单纯的TCP转发数据包了。 3、AF做解密之后，AF跟服务器之间的数据包的TCP三次握手来看，AF发出的数据包中没有TCP窗口扩大因子的选项，所以客户端接收窗口就是65535大小。数据包如下图： 4、AF解密之后代理的SYN包中不带窗口扩大因子的选项，是因为： （1）AF解密后的数据需要送到7层处理，AF的7层处理能力对比4层比较有限（2）如果默认数值设置的很大，AF的7层没处理过来，那就会导致4层数据不断累积，直到会话结束，或超限丢包。 可以AF后台执行测试 echo 2 > /var/idl_dbgfs/flowd.fw.service/tcpstack.win_scale（窗口扩大因子设置为2，TCP接收窗口为65535*2的2次方），如果提示失败，说明版本不支持，如85R SP2打包KB_AF_OS_tcpwin_8085.bin。如果解决问题，在limit ini文件中固化数值（其中x需要改为验证后的值）修改，文件路径：/sfos/config/sys_limit/default/sup_system_limit.ini， [tcpstack limit]下添加:  WIN_SCALE=2 修改TCP窗口扩大因子的选项之后，AF解密后接收窗口会扩大，需要观察和保障业务运行一段时间，看是否会有问题。（一般不会有问题的）   1、wireshark中TCP ZeroWindow是指的本端的接收窗口用完，需要对端发送数据的时候慢一些发送。 2、此类问题，常见于AF做解密之后，一些视频流量或者一些从服务器下载类型的业务，服务器会发送大量数据包给客户端的场景。