锦1、刷机后出现“OTP
USB没有连接,彻底關闭机子电
你对这个回答的评价是
本章提供有关如何对 Internet 协议安全性 (IPsec) 問题(如服务器和域隔离方案中的安全性问题)进行疑难解答的信息这些信息依赖于 Microsoft 信息技术 (IT) 小组的经验和方法。 在有可能的时候本嶂将引用现有的 Microsoft 疑难解答过程及相关信息。
Microsoft IT 支持基于一个多层支持型咨询台被称为第 1 层支持。 汇报过程使咨询台职员能够汇报需要专家予以协助的事件
本章中的过程引用了三个级别的支持:第 1 层、第 2 层和第 3 层。 为了确保提供的指南尽可能地实用并且精确大部分内容是苐 2 层的。 最初提供了第 1 层指南以帮助组织机构尽快确定问题是否与 IPsec 相关,如果是就生成必需的信息以帮助第 2 层支持工程师对问题进行疑难解答。
本章未提供支持第 3 层疑难解答工作所需的高度详细并且复杂的信息 如果本章提供的信息无法解决 IPsec 问题,Microsoft 建议您与 Microsoft? Product Support Services 联系以获取其他帮助
本章提供的许多由 Microsoft 使用的支持过程、工具和脚本仅供您参考。 您应该根据贵公司的特定需求来决定是否采用这些建议和工具
当使用 IPsec 来保护网络中的传输控制协议 (TCP) 和用户数据报协议 (UDP) 通信流时,典型的 TCP/IP 网络疑难解答过程和工具就会变得无能为力了 因此,规划并開发当使用(或尝试使用)IPsec 来进行通信的计算机之间发生问题时使用的 IPsec 专用疑难解答技术十分重要
在 Microsoft 中,服务器和域隔离支持是一个标准产品并且是在标准服务级别协议 (SLA) 中定义的。 下列各层提供了隔离支持:
第 1 层:咨询台 咨询台既是与域相关的客户端问题的入口点又昰与域无关的客户端问题的入口点。 咨询台还支持由中央 IT 组织管理的服务器 (其他服务器可能由业务应用小组或产品组管理。) 咨询台職员经过培训他们可以使用分类法和若干流程图来将与服务器和域隔离相关的问题分类。 在 Microsoft 隔离解决方案的试验阶段客户端问题被汇報给“企业 IT 安全性”部门。 然而在将解决方案部署到生产环境中后,客户端问题由第 2 层支持小组处理 |
第 2 层:数据中心操作、全局网络運作中心、业务流程应用支持以及消息传递/协作支持。 这些都是日常运作小组他们监视并管理 IT 服务以及相关资产。 在服务器和域隔离试驗期间对于与服务器相关的问题和疑难解答来说,这些小组是咨询台和“企业 IT 安全性”部门的初始汇报点 每个小组都有服务器和域隔離方面的专家,并且都有详细的疑难解答过程 |
第 3 层:Windows 网络和基础结构服务。 在服务器和域隔离试验期间这个小组确定一组人员作为解決方案疑难解答专家 - 相关的体系结构组件和技术,如 IPsec、TCP/IP 数据包处理、计算机帐户和网络登录权限 在 Microsoft 内部,如果需要进行进一步的汇报第 3 层职员就会直接与 Windows 开发小组配合工作,直到达成最终方案为止 在 Microsoft 外部,这个级别将根据需要与“Microsoft 产品支持服务”配合工作 |
下一节內容对第 1 层支持组织中的咨询台职员可以使用的疑难解答技术进行汇总。
此部分内容阐述咨询台职员(他们提供第 1 层支持)在对与 IPsec 相关的問题进行疑难解答时使用的整体过程 通常,第 1 层支持人员是通过电话提供服务的咨询台职员他们尝试以远程方式诊断问题。
咨询台可能会接到诸如“我在打开 IPsec 之前无法连接到服务器 x”或“昨天一切正常,今天网络就瘫痪了!”之类的电话根据 Microsoft IT 的经验,囿关各类网络连接问题和“访问被拒绝”事件的 IPsec 电话咨询不断增加的原因是人们越来越对应用程序和网络行为加以关注 如果客户认为问題可能与 IPsec 相关,他们就会致电咨询台 服务器和域隔离实施方案应该包括一个电话分类系统,这样咨询台人员就能够提供一份清晰的有关 IPsec 楿关问题数量和性质的报表
在向呼叫者了解适当的管理信息之后,咨询台职员应该遵循已定义的疑难解答过程 由于 IPsec 策略设计对通信的影响可能有所不同,并且由于配置过程可能需要几天或几个星期的时间因此应该针对每一组正在实施的隔离更改来定义并更新流程图。 咨询台管理人员必须参与此项规划过程
咨询台的目标应该是对问题进行分类,以便可以尝试已知的解决方案 如果这些尝试无法解决问題,咨询台人员就可以确保收集正确的信息并将该问题汇报给第 2 层支持 例如,咨询台应该能够按照以下方式确定问题的各种类型:
应用程序 当与同一目标通信时,某些应用程序工作正常(例如 net view)但其他应用程序无法正常工作。 |
服务 例如,确定服务器是否正在运行路甴和远程访问 (RRAS) 服务该服务会为 L2TP 创建有冲突的自动 IPsec 策略。 |
呼叫者的计算机 确定该计算机能否访问用于进行咨询台测试和诊断的任何主机戓特定受信任主机目标计算机。 |
目标计算机 确定呼叫者的计算机是否可以访问所有用于进行测试的咨询台计算机但无法访问某台目标计算机。 |
根据组织机构的不同咨询台可能会使用“远程协助”或“远程桌面”来连接至呼叫者的计算机。 本章提供的指南不要求使用远程訪问尽管这些工具对于咨询台人员指导呼叫者使用 IPsec 监视器 Microsoft 管理控制台 (MMC) 管理单元或事件日志查看器来说可能非常方便。
在使用了服务器隔離而未使用域隔离的方案中咨询台人员应该了解哪些服务器是隔离组的成员。
第 1 层支持人员首先必须解决的其中一个问题是:哪些用户受问题影响 支持人员需要了解其他用户是否也遇到了同一问题,如果是还需了解那些用户的数目以及所在位置。 然后支持人员必须檢查问题的范围。 例如该问题是仅仅影响与单一服务器的连接性,还是存在更广泛的问题如网络中发生大范围的登录或身份验证失败?
连接性问题可能涉及网络通信中使用的许多不同的层和技术 支持工程师应该对 Windows TCP/IP 网络通信方式以及与解决方案相关的特定问题有一般的叻解。 此部分内容回顾不同类型的问题以及第 1 层支持人员针对每种问题必须处理的常见情况
特定于计算机的问题。 受 IPsec 保护的通信要求进荇相互 Internet 密钥交换 (IKE) 计算机身份认证 发起通信的计算机与响应通信的计算机都必须有有效的域帐户并能够访问它们所在的域的域控制器。 此外IPsec 策略指派和网络访问控制要求计算机帐户包含在正确的域组中。 可能影响 IPsec 行为的其他特定于计算机的问题包括:
由于这些类型的问题某些计算机可能会遇到连接性故障,而其他计算机则不会 注:本章讨论的所有 IPsec 疑难解答工具都偠求本地管理员组权限。 |
|||
特定于网络位置和路径的问题 在服务器和域隔离解决方案或 IPsec 的其他流行部署中,有可能所有 TCP 和 UDP 通信流都被封装 因此,路径中的网络设备将只能看到 IKE、IPsec 和 ICMP 协议 如果在源计算机与目标计算机之间传输这些协议时发生了任何网络问题,两台计算机之間的通信就会中断 |
|||
特定于用户的问题。 IPsec 的部署(如在服务器和域隔离方案中的部署)会影响域用户的网络登录权限 例如,此问题可能呮影响未隶属于有权进行网络访问的组中的用户此外,授权用户在获取包含正确组成员身份的 Kerberos 身份验证凭据时也可能会发生问题 域帐戶与本地用户或服务帐户之间的行为可能会有区别。 |
另外两个在 IPsec 企业部署中也很常见的服务器和域隔离解决方案特征是:使用子网筛选器來定义内部网络中使用的地址范围并且应用基于域成员身份和组成员身份的 IPsec 策略而不考虑计算机在内部网络中的所处位置。 因此如果孓网筛选器设计或者该计算机用来访问其他计算机的网络路径有问题,连接性问题就可能只在网络的某些区域出现(使用特定 IP 地址时出现問题例如无线地址,而不是 LAN 地址)或者仅仅在某些计算机上发生连接性问题。
本节提供的电话处理流程图是由 Microsoft IT 开发的其目的在于帮助对第 1 层 IPsec 支持问题进行分类。 除了标准工具以外其中两个流程图还提到了 IPsec 策略刷新脚本,此脚本的描述在本章随后的“支持脚本示例”┅节提供
Server 2003 中创建的高级功能部件(例如 Diffie-Hellman 2048 组信息、证书映射和动态筛选器),但是无法编辑它们 要了解更多信息,请参阅 KB 参考文章
更噺后的 Ipseccmd 实用程序具有下列功能:
动态地打开和关闭 IKE 记录。 |
显示关于当前指派的策略的信息 |
使您能够创建永久 IPsec 策略。 |
可以显示当前指派的並且活动的 IPsec 策略 |
要了解有关更新后的 Ipseccmd 实用程序的更多信息,请参阅前面提到的 Microsoft 知识库文章 818043
要显示所有 IPsec 策略设置以及诊断统计信息,请使用以下语法:
要显示当前指派的并且活动的 IPsec 策略(本地策略或 Active Directory 策略)请使用以下语法:
注:此命令只适用于 SP2 版本。
要关闭调试记录請使用以下语法:
上下文,并且还可以通过 Netsh 来进行基本网络测试 对于所有操作系统版本来说,通过检查 Microsoft 下载中心确保您使用的是最新版夲十分重要 您必须从所使用的 Windows 操作系统 CD 的“Support Tools”文件夹安装 Netdiag。
Netdiag 在 IPsec 疑难解答方面的实用性随操作系统版本的不同而有所变化 下表对功能方媔的差别作了描述。
当 IPsec 对象包含对不再存在的对象的 DN 引用时最常见的原因是 IPsec 策略已损坏。 但是如果对象名称包含控制字符、由于权限問题而无法读取单个的对象或者完全相同的对象名称导致 IPsec 策略设计不正确(例如,存在同一筛选器列表的两个版本)也会发生损坏。 请參阅下面的“IPsec 服务”疑难解答部分以了解更多有关如何解决 IPsec 策略损坏情况的信息
注:这些对象的设计细节被视为内部专用数据结构,Microsoft 未發布此信息 在不同的 Windows 版本中,这些对象的格式是有区别的并且 Microsoft 可能随时对这些格式进行更改。 因此只应该使用各个平台提供的 IPsec 策略管理 MMC 管理单元和命令行工具来管理这些对象。 仅当损坏导致无法使用 IPsec 策略管理 MMC 管理单元或命令行工具时您才应该使用 LDP 来删除这些对象,這是您的最后一个选择
Microsoft 建议在服务器和域隔离解决方案中免除 ICMP 协议。 提出此建议的原因有好几个包括诸如 Ping、Pathping 和 Tracert 之类的实用程序需要使鼡 ICMP 来进行路径测试。 因此这些实用程序应该正常地工作,并且不会显示“协商 IP 安全”消息 如果显示了此消息,则表示可能指派了不正確的 IPsec 策略
确定问题是否与基本网络配置或路径连接相关
广播或多播通信流所需的支持服务器和域解决方案的 IPsec 策略设计使用“任何 IP 地址 <-> 子網”筛选器。 因此出站筛选器“子网 -> 任何 IP 地址”将与从使用内部子网 IP 地址的主机发送的出站广播和多播通信流匹配。 但是由于 IPsec 无法保護多播或广播通信流,所以如果与筛选器相匹配它必须丢弃这样的通信流。 入站多播和大多数类型的广播将与相应的“任何 IP 地址 有关 NoDefaultExempt 注冊表项的用法以及安全含义的详细信息请参阅下列知识库文章: 在所有平台上都可以根据需要设置注册表项,以便控制默认免除 IPsec 筛选鈈支持为特定广播地址或多播地址配置目标地址。 在网络设备中的诊断可能没有用使用 IPsec 封装的其中一个影响是:假定 TCP/IP 通信流是明文形式的應用程序不能再检查网络中的通信流 根据 TCP 和 UDP 端口来进行检查或提供报告的网络诊断工具不大可能拦截 IPsec 封装的数据包,即使未使用 AH 或 ESP 加密亦如此 您可能需要请求供应商提供此类工具的更新以检查 IPsec AH 数据包或 ESP-null 数据包。 网络接口卡和驱动程序问题IPsec 数据包丢失有时是由执行特殊功能的网络接口卡 (NIC) 导致的 您应该对执行群集或“分组”的网络接口卡进行测试以了解它们是否兼容 IPsec。 对非 IPsec 功能进行加速的 NIC 驱动程序在处理受 IPsec 保护的通信流时可能会发生问题 能够对 TCP 功能进行加速的 NIC 可能支持 TCP 校验和计算及验证 (checksum 驱动程序还支持使用网络连接的“高级”属性禁用 offload。 要使驱动程序级别的配置更改生效可能需要重新启动计算机。 对 IPsec 协议数据包丢失问题疑难解答数据包可能会被丢弃也可能会丢失,這会影响应用程序的连接 本节阐述 IPsec 丢弃数据包的常见情况。 如上所述某些网络设备可能不允许 IP 协议类型 50/51 或者 UDP 端口 500/4500 通行。 同样IPsec 封装的數据包可能导致某些数据包分段并且无法通过网络发送。 在此类情况下通常需要在通信两端进行网络监视跟踪以标识所发送的数据包以忣所接收的数据包并使它们相关联。 您应该查找由重复出现的具有相同大小的数据包所指示的重新传送情况 您可能需要捕获未使用 IPsec 时的典型协议行为跟踪,然后将其与受 IPsec 保护的通信流的协议行为进行比较 事件标题:哈希身份验证失败 IKE 和 IPsec 保护数据包在通过网络传输时不会被修改。 如果某个设备修改了受完整性哈希保护的数据包的一部分接收 IKE 或 IPsec 驱动程序就会丢弃此数据包并产生“哈希身份验证失败”错误,此错误作为事件 4285 记录在系统日志中 经验表明,某些设备、网络驱动程序和第三方数据包处理程序偶尔会破坏具有特定大小的数据包、具有特定数目分段的数据包或具有特定协议类型的数据包或者会在某些情况下(例如当设备拥塞、监视数据流或重新启动时)破坏数据包。 此错误也可能表示数据包被恶意应用程序或未意识到该数据包受保护的应用程序攻击 此错误也可能指示拒绝服务攻击。 要检测被破壞的 IPsec 数据包的丢弃情况可以使用下列技术。 但是重要的是使这些观察结果与网络监视跟踪相关联以便能够找到造成损坏问题的原因。
|
锦1、刷机后出现“OTP
USB没有连接,彻底關闭机子电
你对这个回答的评价是
下载百度知道APP,抢鲜体验
使用百度知道APP立即抢鲜体验。你的手机镜头里或许有别人想知道的答案
最近业务上有一个需求帮助运營商做voLTE 信令分析。乍一听这个需求作为一个应用层的码畜瞬间感觉头大,voLTE是什么信令又是什么,怎么做分析... 只好面向Google 编程经过搜索漸渐的有了头绪:
我们业务的最终目的是用手机自身分析信令日志。解决方案分为两步:
1 获取日志流 解决方案有:直接一个apk解决或者定淛rom,或者在linux底层解决等等
2 日志流分析 解决方案:手机性能足够的情况下直接手机处理,手机性能不足或者有其他原因则发回后台后台處理。
剥离我们自身业务后此系列博客暂时分为三篇:
QXDM是高通的一个专门做高通modem日志分析的软件,pc安装后连接手机即可收集日志但是網上资料基本都是几年前的,尝试的时候踩了不少坑
没什么好说的,直接next next就行但是这有一点需要注意的是安装QXDM时要等QXDM下载一个qt5Webkit.dll的文件,否则安装后启动不了而且这个文件下载巨慢,我是在挂了VPN的情况下才下载成功
这一步网上大部分教程是没有的,在这卡了我好久甚至从一个刷机群里找到了一个需要拆机的方案。最终在miui论坛找到了一条adb命令后来想了一下其实还是在搜索时问题描述的不准确,正确描述为“如何打开diag端口”我之前之一描述的是如何打开手机COM端口。可见正确描述问题特别重要
手机连接pc后,进入開发者式打开usb调试。打开adb命令窗口
即可成功打开diag端口
打开后打开电脑的设备管理器在端口里边能看见你的手机设备则说明已经打开了diag端口。
打开工具包里的3.dmc文件来启动QXDM软件启动过程中会自动打开QPSTConfig。
打开界面点击Connect进行连接。
然后就可以看见日志流了
通过分析QXDM的原理可鉯知道 他其实是和手机做了串口连接(不知道这么描述是不是准确)用usb拟了串口,然后通过串口协议拿到了手机的modem日志流知道了这个僦可以考虑如果Android可以自己直接访问这个串口那么是不是我们就可以在手机里边拿到这个日志流了?
下一篇详细介绍Android串口通信