Устранение неполадок с подключением TCP/IP

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

Применимо к: Windows 10

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

  • Подключение приложений к серверу базы данных
  • Ошибки времени ожидания SQL
  • Ошибки времени ожидания приложения BizTalk
  • Сбои протокола удаленного рабочего стола (RDP)
  • Сбои доступа к общей папке
  • Общая возможность подключения

Если вы подозреваете, что проблема связана с сетью, вы собираете трассировку сети. Затем трассировка сети будет фильтроваться. Во время устранения ошибок подключения вы можете столкнуться со сбросом TCP в сетевом захвате, который может указывать на проблему с сетью.

  • Протокол TCP определяется как надежный протокол, ориентированный на подключение. Одним из способов обеспечения надежности TCP является процесс подтверждения. Создание сеанса TCP начинается с трехстороннего подтверждения, затем передачи данных, а затем четырехстороннего закрытия. Четырехсторонняя закрытие, при которой и отправитель, и получатель соглашаются о закрытии сеанса, называется корректной закрытием. После четырехсторонного закрытия сервер предоставит 4 минуты времени (по умолчанию), в течение которого будут обрабатываться все ожидающие пакеты в сети. Этот период является TIME_WAIT состоянием. После завершения TIME_WAIT состояния все ресурсы, выделенные для этого подключения, освобождаются.
  • Сброс TCP — это внезапное закрытие сеанса; это приводит к немедленному освобождению ресурсов, выделенных для подключения, и все остальные сведения о подключении удаляются.
  • Сброс TCP определяется флагом RESET в заголовке TCP, который имеет значение 1.

Трассировка сети в источнике и назначении помогает определить поток трафика и увидеть, в какой момент наблюдается сбой.

В следующих разделах описаны некоторые сценарии, когда вы увидите RESET.

Удаление пакетов

Когда один одноранговый узел TCP отправляет TCP-пакеты, для которых не получен ответ с другого конца, одноранговый узел TCP в конечном итоге перенаправляет данные и, когда не получено ответа, он завершит сеанс, отправив ACK RESET (этот ACK RESET означает, что приложение подтверждает, какие данные обмениваются до сих пор. но из-за удаления пакетов подключение закрывается).

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

Если начальное подтверждение TCP завершается сбоем из-за удаления пакетов, то вы увидите, что пакет TCP SYN повторно передается только три раза.

Подключение на стороне источника через порт 445:

Снимок экрана: сводка кадров в сетевом мониторе.

Конечная сторона: при применении того же фильтра пакеты не отображаются.

Снимок экрана: сводка кадров с фильтром в сетевом мониторе.

Для остальных данных TCP передаст пакеты пять раз.

Исходная трассировка 192.168.1.62:

Снимок экрана: трассировка на стороне пакета.

Целевая трассировка 192.168.1.2:

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

Если вы видите, что пакеты SYN достигают назначения, но назначение по-прежнему не отвечает, убедитесь, что порт, к которому вы пытаетесь подключиться, находится в состоянии прослушивания. (Выходные данные Netstat помогут). Если порт прослушивает и по-прежнему нет ответа, то может быть падение мппы.

Неправильный параметр в заголовке TCP

Такое поведение возникает, когда пакеты изменяются в сети устройствами среднего уровня, а TCP на принимающем конце не может принять пакет, например изменяемый порядковый номер или пакеты, воспроизводимые средним устройством путем изменения порядкового номера. Опять же, одновременная трассировка сети в источнике и назначении сможет определить, будут ли изменены какие-либо заголовки TCP. Начните с сравнения трассировки источника и целевой трассировки. Вы сможете заметить, что в самих пакетах есть изменения или какие-либо новые пакеты достигают назначения от имени источника.

В этом случае вам снова потребуется помощь от команды сети, чтобы определить любое устройство, которое изменяет пакеты или отправляет пакеты в место назначения. Наиболее распространенными из них являются устройства RiverBed или акселераторы глобальной сети.

Сброс на стороне приложения

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

Сбросы приложения — это те, где вы видите флаг подтверждения, равный 1, а также флаг сброса. Этот параметр означает, что сервер подтверждает получение пакета, но по какой-либо причине не принимает подключение. На этом этапе приложению, получившей пакет, не понравилось то, что оно получило.

На снимках экрана ниже вы увидите, что пакеты, отображаемые в источнике и назначении, одинаковы без каких-либо изменений или удалений, но вы увидите явный сброс, отправленный назначением в источник.

На стороне источника

Снимок экрана: пакеты на стороне источника в сетевом мониторе.

Трассировка на стороне назначения

Снимок экрана: пакеты на стороне назначения в сетевом мониторе.

Вы также увидите пакет флага ACK+RST в случае отправки пакета создания TCP SYN. Пакет TCP SYN отправляется, когда клиент хочет подключиться к определенному порту, но если назначение или сервер по какой-либо причине не хочет принимать пакет, он отправляет пакет ACK+RST.

Снимок экрана: пакет с флагом RSK ACK.

Приложение, которое вызывает сброс (определяется номерами портов), должно быть изучено, чтобы понять, что вызывает сброс подключения.

Примечание.

Приведенные выше сведения о сбросах с точки зрения TCP, а не UDP. UDP — это протокол без подключения, и пакеты отправляются ненадежно. Вы не увидите повторную передачу или сброс при использовании UDP в качестве транспортного протокола. Однако UDP использует ICMP в качестве протокола отчетности об ошибках. Если UDP-пакет отправлен на порт, а порт назначения не указан, сразу после пакета UDP вы увидите сообщение о том, что узел назначения ICMP недоступен: Порт недоступен .

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

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

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

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

Снимок экрана: свойства события с идентификатором фильтра.

Теперь выполните команду netsh wfp show state, при этом при выполнении будет создан wfpstate.xml файл. После того как вы откроете этот файл и отфильтруете идентификатор, который вы найдете в приведенном выше событии (2944008), вы увидите имя правила брандмауэра, связанное с этим идентификатором, которое блокирует подключение.

Снимок экрана: XML-файл wfpstate, содержащий имя правила брандмауэра, связанное с идентификатором фильтра, блокирующим подключение.