通过

TCP/IP 通信故障排除指南

  • 项目

试试我们的虚拟代理 - 它可以帮助快速识别和修复常见的 Active Directory 复制问题。

本文旨在帮助解决 TCP/IP 通信问题。

故障排除工具

ping 命令适用于测试基本连接。 但是，不应依赖它来验证总体连接。 Telnet 和 PsPing 的作用更大，原因如下：

  • 这些工具可以使用 TCP 或 UDP（仅限 PsPing）作为传输协议来测试与应用程序层的连接。
  • 可以指定将使用的端口。 因此，你可以在防火墙上导航开放端口。
  • 可以连接到目标节点上的任何“侦听”端口来验证对特定应用程序端口的访问权限。

故障排除清单

步骤 1：捕获网络图

捕获详细描述受影响区域路径中的设备的网络图。 具体而言，请注意以下设备：

  • 防火墙
  • IPS（入侵防护系统）
  • DPI（深度数据包检查）
  • WAN 加速器

此图可帮助你直观了解和确定在何处查找问题的原因。

步骤 2：网络跟踪

网络跟踪有助于查看问题发生时网络级别发生的情况。

步骤 3：Ping 计算机的本地 IP 地址

尝试 ping 到计算机的本地 IP 地址。

如果节点无法 ping 其本地 IP，则本地堆栈不起作用。 请注意显示的任何错误消息。

如果收到“ 常规失败” 错误，则此错误意味着没有有效的接口来处理请求。 此问题可能是由硬件问题或堆栈问题引起的。

检查系统任务栏中的“网络连接”图标上是否显示了红色的“X”字符或黄色感叹号。 红色 X 表示 Windows 未检测网络连接。 黄色感叹号表示网络连接状态指示器 (NSCI) 未通过探测检查。

若要解决此问题，请验证网络适配器是否报告连接。 确保网络适配器已插入，并且连接节点的交换机端口未处于错误状态。 可以更改电缆、交换机端口和网络适配器，以缩小此问题发生的位置。 但最终，问题出在 OS 之外。 若要进一步调查，请与硬件供应商联系。

网络驱动程序和 Windows 之间也可能发生问题。 此问题通常是由于堆栈中的损坏。 使用以下故障排除步骤：

  1. 确保节点上的最新位（TCP/IP、NDIS、AFD、Winsock 等）。

  2. 运行以下命令重置 IP 和 Winsock。 备份所有网络配置。

    netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset

  3. 重启节点。

  4. 重启后，还原网络设置。 仅当接口名称尚未更改或脚本更新为使用新名称时，此操作才有效。

    netsh -f C:\netConfig.txt

  5. 根据需要卸载或重新安装网络适配器驱动程序。

  6. 检查并删除第三方筛选器驱动程序（例如，防病毒软件）。

  7. 尝试在网络安全模式下启动计算机。 如果网络安全模式有效，请通过禁用 MSConfig 中的所有第三方应用和服务来运行“干净启动”进程，然后逐个重新启用它们，直到问题返回。 然后，可以联系供应商获取支持。

    1. 如果这些项均不成功，则问题可能是注册表损坏。
    2. 如果有注册表的备份副本（例如物理备份或系统还原点），可以尝试将节点还原到以前工作的配置。 捕获腐败的根本原因可能非常困难，而且非常耗时。 即使发现腐败，也知道是什么导致了它更具挑战性。 手动修改损坏的注册表项会使节点处于不受支持的状态。 在这种情况下，我们建议客户还原或重新加载节点以便更正损坏。

如果 NSCI 未通过探测检查（黄色感叹号），这不一定表示连接问题。 确保典型的通信发生，因为它应该发生。

  • 如果是这样，则调查应着重于 NCSI 未通过其探测检查的原因。 这方面的详细信息在单独的主题中进行了介绍。
  • 如果不是这样，请首先调查连接问题，因为在连接还原后，这可能会得到纠正。

步骤 4：排查 ping 或 telnet 测试期间发生的错误消息

如果该节点可以 ping 或 telnet 到同一子网或网段上的节点，这会确认外部连接正常。 还需要进一步测试，以了解是否存在基本连接问题。

如果节点无法 ping/telnet 到同一子网/网段上的节点。 请注意显示的任何错误消息。

  1. 目标主机无法访问 错误意味着节点发送的 ARP 请求未收到响应。

  2. 从要测试的节点收集双面跟踪。 确保源节点发送的 ARP 请求到达目标节点，并且目标节点会相应地答复。 应在源跟踪中看到此回复。 如果此过程失败，则问题可能是配置错误或其他影响基础结构的问题。

    可能的原因包括：

    1. VLAN 错误或不匹配。
    2. 交换机端口配置不正确（中继与访问端口）。
    3. 其他硬件问题。

  3. 请求 超时 错误表示 ARP 请求收到响应，但节点发送的 ICMP 回显请求未收到 ICMP 回显响应。 仅此一项并不表示问题。 节点上的网络或防火墙软件可能会阻止 ICMP 流量。 关闭防火墙配置文件 (Windows) 或通过防火墙供应商支持的 ICMP 测试方法禁用防火墙配置文件可能会很有用。

    1. Telnet 和 PsPing 更适合用于测试。 在侦听端口（例如 445）上，从源节点向目标节点运行 Telnet 或 PsPing。
    2. 如果步骤 1 成功，则外部连接正常。 继续测试基本连接。
    3. 如果步骤 1 未成功（以及防火墙配置文件已禁用），请收集一个双向 netsh netconnection 方案跟踪以进一步进行故障排除。

步骤 5：Ping 或 Telnet 到默认网关

当节点可以 ping 到其默认网关时，则可以从源节点进行外部连接（例如机外连接）。 还需要进一步测试，以了解是否存在基本连接问题。 如果节点无法 ping 或 Telnet 到其默认网关，这意味着 ICMP 答复在路由器上处于禁用状态。

步骤 6：检查影响特定目标节点的问题

如果源节点可以 ping、Telnet 或 PsPing 到目标子网上的其他节点，则基础结构内的基本连接和路由正常工作。 此结果指向影响特定目标节点的问题。

  1. 尝试 Telnet 或 PsPing 到应用程序侦听的特定端口（例如，SMB 的 TCP 端口 445）。 如果连接成功，则可以确认基本的应用程序级连接。 在这种情况下，必须与应用程序供应商联系，以帮助调查应用程序无法连接的原因。

    注意

    例如，如果问题未能连接到共享，则应用程序供应商可能会Microsoft。 在这些情况下，采取双向 netsh 网络连接方案跟踪来收集其他信息并帮助验证网络堆栈中是否不存在任何问题会很有用。

  2. 如果与特定端口的连接未成功：

    1. 确保端口处于“侦听”状态：
      CMD： netstat -nato | findstr :<port>
      PowerShell：Get-NetTcpConnection -LocalPort <port>
    2. 临时禁用所有防火墙配置文件。 （注意：仅禁用配置文件。请勿禁用服务。
      如果成功，则必须重新配置防火墙以允许其特定端口上的应用程序流量。
    3. 一次删除一个第三方应用程序，并在每两次删除之间进行测试。
      如果成功，请与有问题的软件的供应商联系。
    4. 尝试网络安全模式。
      如果成功，请通过使用 MSConfig 运行节点的“干净启动”来隔离原因，然后逐个启用第三方应用程序和服务，直到问题再次出现。
    5. 重现连接尝试时，应运行从源到受影响目标节点的 netsh 网络连接方案跟踪。 网络 SDP 也十分有利。

  3. 如果节点无法 ping、Telnet 或 PsPing 到目标子网上的其他节点，则问题可能与基础结构相关。 同样，ICMP 可能会在环境中被阻止。 因此，请通过使用 Telnet 或 PsPing 连接到已知侦听端口来验证连接。 此时，需要一个双向网络跟踪来显示网络上发生数据包丢失的位置。 在尝试连接测试之前，请确保两条跟踪都在运行，以便捕获问题。

常见问题和解决方案

与主机的 TCP/IP 连接似乎已停止

出现此问题的原因是 TCP 和 UDP 队列中阻止了数据，或者存在网络或用户级软件延迟问题。

若要解决此问题，请使用 netstat -a 命令显示本地计算机上的 TCP 和 UDP 端口上所有活动的状态。
在发送和接收队列中具有零字节（0）字节时，建立良好的 TCP 连接的状态。 如果任一队列中的数据被阻止，或者状态不规律，则连接可能出错。 如果没有，则可能遇到网络或用户级软件延迟。

使用 Lmhosts 进行名称解析时的长时间连接时间

出现此问题的原因是，将按顺序分析 Lmhosts 文件以查找没有 #PRE 选项的条目。

若要解决此问题，请将常用条目放在文件顶部附近，将 #PRE 条目放在底部附近。 如果将条目添加到大型 Lmhosts 文件的末尾，请使用 #PRE 选项将 Lmhosts 中的条目标记为预加载条目。 然后，运行 nbtstat -R 命令以立即更新本地名称缓存。

出现系统错误 53

如果使用命令时 net use ，如果特定计算机名称的名称解析失败，则返回系统错误 53。

如果计算机位于本地子网上，请验证名称是否拼写正确，并且目标计算机是否也正在运行 TCP/IP。 如果计算机不在本地子网上，请确保其名称和 IP 地址映射在 Lmhosts 文件或 WINS 数据库中可用。 如果所有 TCP/IP 元素似乎都正确安装，请使用 ping 命令与远程计算机一起验证其 TCP/IP 软件是否正常工作。

无法连接到特定服务器

出现此问题的原因是 NetBIOS 名称解析未解析名称或正在解析错误的 IP 地址。

若要解决此问题，请使用 nbtstat -n 服务器上的命令来确定网络上注册的服务器的名称。 您尝试连接到的计算机的计算机名应位于显示的列表中。 如果未列出该名称，请尝试显示 nbtstat的其他唯一计算机名称之一。 如果远程计算机使用的名称与命令显示 nbtstat -n 的名称相同，请确保远程计算机具有 WINS 服务器或其 Lmhosts 文件中的服务器名称的条目。

无法添加默认网关

出现此问题的原因是默认网关的 IP 地址与 IP 地址不在同一 IP 网络 ID 上。

若要解决此问题，请通过将默认网关的 IP 地址与计算机任何网络适配器的网络 ID 进行比较，确定默认网关是否与计算机的网络适配器位于同一逻辑网络上。

例如，计算机有一个网络适配器，其 IP 地址配置为 192.168.0.33，子网掩码为 255.255.0.0。 这要求默认网关的格式为“192.168”。<y>.<z>“，因为 IP 接口的网络 ID 部分为 192.168.0.0。

数据收集

在联系Microsoft支持人员之前，可以收集有关问题的信息。

先决条件

  1. TSS 必须由本地系统上具有管理员权限的帐户运行，并且必须接受 EULA（接受 EULA 后，TSS 不会再次提示）。
  2. 建议使用本地计算机 RemoteSigned PowerShell 执行策略。

注意

如果当前 PowerShell 执行策略不允许运行 TSS，请执行以下操作：

  • 通过运行 cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned设置RemoteSigned进程级别的执行策略。
  • 若要验证更改是否生效，请运行 cmdlet PS C:\> Get-ExecutionPolicy -List。
  • 由于进程级别权限仅适用于当前的 PowerShell 会话，因此一旦关闭了运行 TSS 的给定 PowerShell 窗口，进程级别的分配权限也将返回到以前配置的状态。

在联系Microsoft支持人员之前收集关键信息

  1. 在所有节点上下载 TSS ，并将其解压缩到 C：\tss 文件夹中。

  2. 从提升的 PowerShell 命令提示符打开 C：\tss 文件夹。

  3. 使用以下 cmdlet 在源和目标服务器上启动跟踪：

    TSS.ps1 -Scenario NET_General

  4. 如果跟踪首次在源或目标服务器上运行，请接受 EULA。

  5. 允许录制（PSR 或视频）。

  6. 在输入 Y 之前重现问题。

    注意

    如果在客户端和服务器上收集日志，请在两个节点上等待此消息，然后再重现问题。

  7. 在重现问题后输入 Y 以完成日志收集。

跟踪将存储在 C：\MS_DATA 文件夹中的 zip 文件中，该文件可以上传到工作区进行分析。

参考