Прочитать на английском

Поделиться через

Руководство по устранению неполадок с обменом данными по протоколу TCP/IP

  • Статья

Попробуйте наш виртуальный агент . Это поможет быстро определить и устранить распространенные проблемы репликации Active Directory.

Эта статья предназначена для устранения неполадок с подключением TCP/IP.

Средства диагностики

Команда проверки связи полезна для тестирования базового подключения. Однако не стоит полагаться на нее для доказательства общего подключения. Telnet и PsPing более полезны по следующим причинам:

  • Эти средства могут проверить возможность подключения к уровню приложения, используя TCP или UDP (только PsPing) в качестве протокола транспортировки.
  • Можно указать, какой порт будет использоваться. Таким образом вы можете перемещаться по открытым портам брандмауэра.
  • Вы можете подключиться к любому порту прослушивания на целевом узле, чтобы проверить доступ к порту определенного приложения.

Контрольный список по устранению неполадок

Шаг 1. Захват сетевой схемы

Создайте схему сети, которая содержит сведения об устройствах, находящихся на пути к затронутой области. В частности, обратите внимание на следующие устройства:

  • Брандмауэры
  • протоколы IP (системы защиты от вторжений и предотвращения);
  • DPI (глубокая проверка пакетов);
  • ускорители WAN.

Схема может помочь визуализировать и определить, где искать причину проблемы.

Шаг 2. Трассировка сети

Трассировки сети полезны, чтобы увидеть, что происходит на уровне сети при возникновении проблемы.

Шаг 3. Проверка подлинности локального IP-адреса компьютера

Попробуйте проверить связь с локальным IP-адресом компьютера.

Если узел не может выполнить связь с локальным IP-адресом, локальный стек не работает. Запишите все отображаемые сообщения об ошибках.

Если возникает ошибка общего сбоя , эта ошибка означает, что для обработки запроса нет допустимых интерфейсов. Эта проблема может быть вызвана проблемой оборудования или стеком.

Проверьте, видите ли вы красный символ "X" или желтый восклицательный знак на значке Сетевое подключение на панели задач. Красный X указывает, что Windows не обнаруживает сетевое подключение. Желтый восклицательный знак означает, что индикатор состояния подключения к сети (NSCI) не прошел проверку работоспособности.

Чтобы устранить эту проблему, убедитесь, что сетевой адаптер сообщает о подключении. Убедитесь, что сетевой адаптер подключен и что порт коммутатора, на котором подключен узел, не находится в состоянии ошибки. Можно изменить кабели, порты коммутатора и сетевые адаптеры, чтобы сузить место возникновения этой проблемы. Однако в конечном итоге эта проблема возникает за пределами операционной системы. Для дальнейшего исследования обратитесь к поставщикам оборудования.

Кроме того, может произойти ошибка между сетевым драйвером и 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. Попробуйте запустить компьютер в безопасном режиме для Сети Azure. Если работает безопасный режим с сетью, выполните процесс "чистой загрузки", отключив все сторонние приложения и службы в MSConfig, а затем повторно включите их по одному до тех пор, пока проблема не вернется. Затем вы можете обратиться к поставщику за поддержкой.

    1. Если ни один из этих пунктов не помог, проблема, скорее всего, заключается в повреждении реестра.
    2. Если у вас есть резервная копия реестра (например, физическая резервная копия или точка восстановления системы), можно попытаться восстановить узел в ранее работающей конфигурации. Перехват первопричины повреждения может оказаться трудным и чрезвычайно трудоемким. Даже если коррупция найдена, зная, что вызвало это еще более сложно. Изменение поврежденного раздела реестра вручную переводит узел в неподдерживаемое состояние. Поэтому рекомендуется восстановить или перезагрузить узел клиента, чтобы исправить повреждение.

Если NSCI завершает проверку пробы (желтый восклицательный знак), это не обязательно указывает на проблему подключения. Убедитесь, что обычное взаимодействие происходит как должно.

  • В этом случае исследование должно сосредоточиться на том, почему NCSI не проходит проверку на работоспособность. Сведения для этого описаны в отдельном разделе.
  • Если это не так, сначала изучите проблемы с подключением, поскольку, скорее всего, они будут устранены после восстановления подключения.

Шаг 4. Устранение неполадок сообщений об ошибках, возникающих во время теста ping или telnet

Если узел может выполнить проверку связи или telnet для узлов в той же подсети или в том же сегменте сети, это подтвердит, что внешнее подключение работает. Дальнейшее тестирование по-прежнему необходимо для того, чтобы понять, существует ли базовая проблема с подключением.

Если узел не может ping/telnet к узлам в одном сегменте подсети или сети. Запишите все отображаемые сообщения об ошибках.

  1. Ошибка узла назначения означает, что запросы ARP, отправленные узлом, не получают ответ.

  2. Соберите двухсторонняя трассировка из узлов, между которыми выполняется тестирование. Убедитесь, что запрос ARP, отправленный исходным узлом, достигает конечного узла, и что конечный узел отвечает соответствующим образом. Этот ответ должен быть виден в исходной трассировке. Если этот процесс не удается, проблема, скорее всего, заключается в неправильной конфигурации или других проблемах, влияющих на инфраструктуру.

    Возможные причины:

    1. Неправильные или несоответствующие виртуальные локальные сети.
    2. Неправильная конфигурация порта коммутатора (магистраль против порта доступа).
    3. Другие проблемы с оборудованием.

  3. Ошибка времени ожидания запроса означает, что запрос ARP получил ответ, но запрос на эхо ICMP, отправленный узлом, не получает ответ на эхо ICMP. Это, в одиночку, не указывает на проблему. Трафик ICMP может быть заблокирован сетевым программным обеспечением или брандмауэром на узлах. Может быть полезно выключить профили брандмауэра (Windows) или отключить их через поддерживаемый производителем брандмауэра метод тестирования ICMP.

    1. Для тестирования лучше подходят Telnet и PsPing. Запустите Telnet или PsPing с исходного узла на узел назначения через порт прослушивания (например, 445).
    2. Если шаг 1 успешно выполнен, внешнее подключение работает. Продолжите тестирование базового подключения.
    3. Если шаг 1 не выполнен (и если профили брандмауэра отключены), соберите двухсторонняя netsh netconnection трассировка сценария для дальнейшего устранения неполадок.

Шаг 5. Связь или Telnet с шлюзом по умолчанию

Если узел может проверить связь со своим шлюзом по умолчанию, то внешнее подключение (например, подключение вне узла) возможно с исходного узла. Дальнейшее тестирование по-прежнему необходимо для того, чтобы понять, существует ли базовая проблема с подключением. Если узел не может выполнять связь или Telnet со своим шлюзом по умолчанию, это означает, что ответы ICMP отключены на маршрутизаторе.

Шаг 6. Проверка проблем, влияющих на конкретный конечный узел

Если исходный узел может выполнять связь, Telnet или PsPing с другими узлами в конечной подсети, то выполняется базовое подключение и маршрутизация в инфраструктуре. Этот результат указывает на проблему, которая затрагивает конкретный узел назначения.

  1. Попробуйте использовать Telnet или PsPing для конкретного порта, который прослушивает приложение (например, TCP-порт 445 для SMB). Если подключение установлено успешно, можно подтвердить базовое подключение на уровне приложения. В этом случае необходимо обратиться к поставщику приложения, чтобы выяснить, почему приложение не подключается.

    Примечание

    Поставщик приложений может быть корпорацией Майкрософт, если проблема является ошибкой подключения к общей папке, например. В таких ситуациях рекомендуется использовать двустороннюю трассировку сценария Netsh NetConnection для сбора дополнительных сведений и проверки отсутствия проблем в сетевом стеке.

  2. Если подключение к конкретному порту не выполнено:

    1. Убедитесь, что порт находится в состоянии прослушивания:
      CMD: netstat -nato | findstr :<port>
      PowerShell: Get-NetTcpConnection -LocalPort <port>
    2. Временно отключите все профили брандмауэра. (Примечание. Отключите только профили. Не отключать службу.)
      Если это удается, брандмауэр должен быть перенастроен, чтобы разрешить трафик приложения на определенном порту.
    3. Удаляйте все сторонние приложения по одному за раз и проводите проверку между каждым удалением.
      Если это удалось, обратитесь к поставщику проблемного программного обеспечения.
    4. Попробуйте безопасный режим для Сети Azure
      Если это выполнено успешно, изолируйте причину, выполнив "чистую загрузку" узла с помощью MSConfig, а затем включите сторонние приложения и службы по одному, пока проблема не повторится.
    5. Когда вы воспроизведете попытку подключения, вам следует запустить трассировку сценария Netsh NetConnection от источника к затронутому узлу назначения. Сетевой SDP также будет полезен.

  3. Если узел не может выполнять связь, Telnet или PsPing с другими узлами в конечной подсети, проблема может быть связана с инфраструктурой. Опять же, ICMP может быть заблокирован в среде. Поэтому проверьте возможность подключения, используя Telnet или PsPing для подключения к известным прослушиваемым портам. На этом этапе необходимо провести двустороннюю трассировку сети, чтобы показать, где в сети происходит потеря пакетов. Убедитесь, что обе трассировки запущены до того, как вы попробуете проверить подключения, чтобы проблема была зафиксирована.

Распространенные проблемы и решения

Подключение TCP/IP к узлу, как представляется, остановлено

Эта проблема возникает, так как данные блокируются в очередях TCP и UDP или возникают проблемы с задержкой программного обеспечения на уровне сети или пользователя.

Чтобы устранить эту проблему, используйте netstat -a команду, чтобы отобразить состояние всех действий на tcp-портах и портах UDP на локальном компьютере.
Состояние хорошего TCP-подключения устанавливается при наличии нуля (0) байтов в очередях отправки и получения. Если данные блокируются в любой из очередей или если состояние нестабильно, то, вероятно, подключение неисправно. Если нет, скорее всего, возникает задержка программного обеспечения на уровне сети или пользователя.

Длительное время подключения при использовании Lmhosts для разрешения имен

Эта проблема возникает, так как файл Lmhosts анализируется последовательно, чтобы найти записи без параметра #PRE.

Чтобы устранить эту проблему, поместите часто используемые записи в верхней части файла и #PRE записи в нижней части. Если запись добавляется в конец большого файла Lmhosts, пометьте запись в Lmhosts как предварительно загруженную запись с помощью параметра #PRE. Затем выполните команду nbtstat -R, чтобы немедленно обновить локальный кэш имен.

Произошла системная ошибка 53

Системная ошибка 53 возвращается, если разрешение имен завершается ошибкой для определенного имени компьютера при net use использовании команды.

Если компьютер находится в локальной подсети, убедитесь, что имя орфографировано правильно, а целевой компьютер также работает с TCP/IP. Если компьютер отсутствует в локальной подсети, убедитесь, что его имя и сопоставление IP-адресов доступны в файле Lmhosts или базе данных WINS. Если все элементы TCP/IP, как представляется, установлены должным образом, используйте ping команду вместе с удаленным компьютером, чтобы убедиться, что его программное обеспечение TCP/IP работает.

Не удается подключиться к определенному серверу

Эта проблема возникает, так как разрешение имен NetBIOS не разрешает имя или неправильный IP-адрес.

Чтобы устранить эту проблему, используйте nbtstat -n команду на сервере для определения имен сервера, зарегистрированного в сети. Имя компьютера, к которому вы пытаетесь подключиться, должно находиться в отображаемом списке. Если имя не указано, попробуйте одно из других уникальных имен компьютеров, отображаемых nbtstat. Если имя, используемое удаленным компьютером, совпадает с именем, отображаемым nbtstat -n командой, убедитесь, что удаленный компьютер имеет запись для имени сервера, который находится на сервере WINS или в файле Lmhosts.

Невозможно добавить шлюз по умолчанию.

Эта проблема возникает, так как IP-адрес шлюза по умолчанию не имеет того же IP-идентификатора сети, что и IP-адрес.

Чтобы устранить эту проблему, определите, находится ли шлюз по умолчанию в той же логической сети, что и сетевой адаптер компьютера, сравнивая IP-адрес шлюза по умолчанию с идентификаторами сети любого из сетевых адаптеров компьютера.

Например, компьютер имеет один сетевой адаптер, для которого настроен IP-адрес 192.168.0.33 и маска подсети 255.255.0.0. Для этого требуется, чтобы шлюз по умолчанию был в форме 192.168.<y>.<z>", так как часть сетевого идентификатора интерфейса IP-адреса — 192.168.0.0.

Сбор данных

Перед обращением в службу поддержки Майкрософт вы можете собирать сведения о проблеме.

Предварительные требования

  1. TSS должен выполняться учетными записями с правами администратора в локальной системе, и EULA необходимо принять (после принятия лицензионного соглашения TSS не будет запрашивать снова).
  2. Рекомендуется использовать политику выполнения PowerShell локального компьютера RemoteSigned .

Примечание

Если текущая политика выполнения PowerShell не разрешает выполнение TSS, выполните следующие действия:

  • RemoteSigned Задайте политику выполнения для уровня процесса, выполнив командлетPS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
  • Чтобы проверить, вступает ли в силу изменение, выполните командлет PS C:\> Get-ExecutionPolicy -List.
  • Так как разрешения уровня процесса применяются только к текущему сеансу PowerShell, после закрытия заданного окна PowerShell, в котором выполняется TSS, назначенное разрешение для уровня процесса также будет возвращено в ранее настроенное состояние.

Сбор ключевых сведений перед обращением в службу поддержки Майкрософт

  1. Скачайте TSS на всех узлах и распакуйте его в папке C:\tss.

  2. Откройте папку C:\tss из командной строки PowerShell с повышенными привилегиями.

  3. Запустите трассировку на исходном и целевом сервере с помощью следующего командлета:

    TSS.ps1 -Scenario NET_General

  4. Примите EULA, если трассировки выполняются в первый раз на исходном или целевом сервере.

  5. Разрешить запись (PSR или видео).

  6. Воспроизвести проблему перед вводом Y.

    Примечание

    Если вы собираете журналы как на клиенте, так и на сервере, дождитесь появления этого сообщения на обоих узлах перед воспроизведением проблемы.

  7. Введите Y , чтобы завершить коллекцию журналов после воспроизведения проблемы.

Трассировки будут храниться в ZIP-файле в папке C:\MS_DATA , которую можно отправить в рабочую область для анализа.

Справочные материалы