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

Эта статья поможет вам устранить проблемы с обменом данными TCP/IP.

Инструменты устранения неполадок

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

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

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

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

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

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

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

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

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

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

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

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

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

Если узел не может выполнить связь или 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. Попробуйте безопасный режим с сетевым подключением.
      Если это удалось, изолируйте причину, запустив "чистую загрузку" узла с помощью 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 должны запускаться учетными записями с правами администратора в локальной системе, а лицензионное соглашение должно быть принято (после принятия лицензионного соглашения TSS больше не будет запрашивать запрос).
2. Мы рекомендуем использовать политику выполнения PowerShell на локальном компьютере RemoteSigned .

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

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

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

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

   TSS.ps1 -Scenario NET_General
   

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

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

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

   Примечание.

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

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

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

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

• Устранение неполадок с подключением TCP/IP
• Устранение неполадок с нехваткой портов
• Устранение ошибок удаленного вызова процедур (RPC)
• Сбор данных с помощью монитора сети
• Не удается открыть свойства TCP/IP сетевого адаптера
• Прямой SMB узла через TCP/IP
• Настройка сети TCP/IP при отключении NetBIOS
• Остановка трафика TCP
• Изменен диапазон динамических портов по умолчанию для TCP/IP
• Свойства TCP/IP отменить изменения к параметрам по умолчанию