6.1 隧道资源访问失败
6.1.1 资源诊断报错“资源连通性检测异常”
问题现象
资源访问失败，使用资源诊断提示代理网关与资源无法建立连接
问题确认方式：
此类报错，tcping可能会显示是通的，无法直接用tcping探测的结果来确认资源最后是否真实可访问，但是如果tcping是通的，可以说明隧道已打通。
可以用curl等支持tls的工具发起请求来确认是否可以访问，另外可以检查服务端资源访问日志，明确请求是否已经到了服务端，以及访问是否报错
问题可能原因：
资源本身不可达
tls协议版本不对
中间设备拦截，包括终端上的安全软件，防火墙，沙箱等
问题解决方案：
在服务端检查资源是否真实可以访问，用curl检查是否可以连接
尝试调整本地internet选项中的tls选项，或者检查服务端的tls协议选项
如果是单台环境，可以先尝试在终端抓包确认连接被哪一端断开，或者防火墙，杀软，及沙箱退出后再重试
6.1.2 资源诊断报错“未找到该应用权限”
问题现象
问题确认方式：
检查服务端是否存在对应资源
在浏览器资源应用中心页面F12检查v1/user/clientResource请求中是否包含此资源
使用隧道日志分析工具分析具体原因
问题可能原因：
该资源未配置或被排除
该资源未下发到客户端，或者客户端未拿到配置
问题解决方案：
若未配置资源或者被排除，可以在资源诊断详情中看到
若以配置，可以使用F12或者收集客户端日志后，在LogColltionTool.log中查看xtunnle dump中信息，检查客户端是否成功拿到资源
clientResource请求是客户端请求拿到的数据，xtunnle dump中记录的是隧道实际获取到数据。
6.1.3 资源诊断报错“代理网关线路检测异常”
问题现象
问题确认方式：
使用tcping探测和curl探测代理网关线路是否能够访问, tcp能通不能说明网关能连上，tcp只是用来说明延迟以及是否有明显丢包的
必须要用curl发起tls请求看是否能通才能说明问题
问题可能原因：
网关不被atrust代理，网关的连接与网络环境有关，跟所有网关线路的tcp连接失败或者socks连接失败，通常是网络问题或者中间设备问题
问题解决方案：
如果多个用户无法访问，优先确认服务端网关是否正常
通过tcping检查网络连通性，网络延迟以及是否有明显丢包
检查tls协议版本设置
通过curl发起tls请求确认报错信息
6.1.4 资源诊断报错“无法解析域名资源”
问题现象
问题确认方式：
如果本地发起了dns请求，且请求被引流，则可以在 "域名解析"中的"域名类型"字段中确认域名的资源类型，以及预期结果
问题可能原因：
希望通过隧道域名资源解析成fakeip，但是没有勾选启用fakeip或者未设置域解析
希望通过内网dns解析，但是内网dns解析超时。
希望通过本地dns解析，但是本地dns无法解析
读取了缓存，未进行实际解析。
本地或者浏览器使用了tcpdns导致无法引流
问题解决方案：
检查是否需要配置fakeip或者是否配置域解析
检查服务端内网dns访问日志是否出现报错
nslookup检查本地dns是否异常
通过日志工具查看dns日志，查看对应域名的解析结果是否存在报错
清理本地dns缓存和浏览器缓存后重试
可以先临时配置防火墙规则来禁用tcp 53，443端口验证是否是tcpdns导致的异常，如是，则可沟通研发提供补丁包
6.1.5 资源诊断无报错，但是资源访问异常
问题现象
问题确认方式：
多次资源诊断均可达，说明隧道连接已打通，隧道状态应该是正常的。资源不可访问，可能是客户端业务系统还存在其他资源的依赖
问题可能原因：
特殊软件存在特殊依赖，如mac地址，特殊协议等
单个业务资源的子链接可能会访问到其他资源或者其他端口，资源地址或者端口未配全
问题解决方案：
尝试本地切换成tap网卡，管理员执行use_tap.bat
``` use_tap.bat
@echo off
set installPath=%programfiles(x86)%\Sangfor\aTrust\aTrustAgent
set confDir="%installPath%\xtunnel-64\conf"
if %PROCESSOR_ARCHITECTURE%=="x86" (
set confDir="%installPath%\xtunnel-32\conf"
)
echo %confDir%
if not exist %confDir% (
echo %confDir%
mkdir %confDir%
)
set confDir=%confDir:"=%
copy /Y "%installPath%\conf_bak\conf_tap.toml" "%confDir%\conf.toml"
taskkill /f /im aTrustXtunnel.exe
pause
```
TIPS: 参考上述脚本也可以编写启用网卡常驻的脚本
tap网卡常驻脚本
自适应模式网卡常驻脚本
尝试发布全协议全端口验证，切换至长隧道，同时内网dns下发中不勾选"仅允许以下域名通过内网DNS解析", 确保全网域名,全网IP，全协议都走atrust
通过F12或者抓包软件确认对应业务往那些ip或者端口发送请求，配置对应的资源
6.1.6 麒麟Kylin系统上资源访问失败，诊断提示write:permission denied
问题现象
Kylin系统上访问资源失败，使用资源诊断时会提示sdpc接入地址连接失败，或者资源域名解析失败。对应的错误提示：write:permission denied
问题确认方式：
确认aTrust是否被Kylin系统联网控制阻止了访问网络，其中aTrust应用名为cn.com.sangfor.atrust
问题可能原因：
麒麟系统拦截了aTrust相关进程的网络请求，导致客户端无法正常连接sdpc或访问资源
问题解决方案：
关闭系统(安全中心->网关保护->应用联网控制)功能
在系统(安全中心->网络保护->应用联网控制->高级设置)中，将aTrust应用加白，对应的应用名为cn.com.sangfor.atrust
SP_aTrust_2410CL_05补丁包已经优化此问题，安装客户端时默认会将aTrust进程添加到白名单中，可安装对应版本客户端解决
6.1.7 AD域内远程文件夹或mstsc远程访问失败
问题现象：
AD域环境内打开共享文件夹认证失败
使用mstsc无法正常访问对应资源，提示内部错误
问题确认方式：
和管理员确认当前是否为AD域场景，可能某些资源未发布完成，如域控场景下很多业务依赖内网DNS下发
mstsc连接依赖系统相关配置，提示内部错误可能是相关系统配置需要调整
问题可能原因：
AD域内的相关资源访问可能存在特殊的配置，如需要增加相关资源地址的发布或调整系统配置
问题解决方案：
AD域业务可能有UDP依赖，需将资源和AD域控地址同时配置为长隧道，域名使用内网dns下发
mstsc 连接可能出现内部错误，通常是mstsc的协议限制等，可参考此博客调整设置https://blog.csdn.net/qq_44329573/article/details/127019416
通过F12或者抓包软件确认对应业务往哪些IP或者端口发送请求，配置对应的资源
6.1.8 Mac电脑上开启的互联网共享，登录aTrust之后无法正常共享网络
问题现象：
Mac电脑上开启的互联网共享，登录aTrust之后无法正常共享网络
问题确认方式：
手动关闭开启一次互联网共享开关是否恢复正常？如果恢复正常则说明是aTrust影响
问题可能原因：
开启系统互联网共享会系统会动态修改pf规则，aTrust登录成功后会覆盖修改系统pf规则文件，导致系统动态添加的pf规则被覆盖，导致网络共享无法使用
问题解决方案：
登录aTrust之后再手动关闭开启一次互联网共享开关
深信服科技 all right reserved，powered by Gitbook本文档更新于：
2024-11-05 01:19