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

Вы можете столкнуться с ошибками подключения к ошибкам завершения или таймаута приложения. Наиболее распространенные сценарии включают подключение приложения к серверу базы данных, ошибки времени ожидания SQL, ошибки таймаутов приложений BizTalk, сбои при доступе к общим ресурсам, а также общее подключение.

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

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

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

  • Сброс TCP передается с помощью флага сброса в заголовке 1TCP.

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

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

Пакетные падения

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

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

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

Сторона источника с подключением к порту 445:

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

Конечная сторона: примените тот же фильтр, и вы не увидите никаких пакетов.

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

Для оставшейся части данных протокол TCP пересылает пакеты 5 повременными вызовами.

Трассировка 192.168.1.62 на стороне источника:

Снимок экрана, на котором показана трассировка на стороне пакета

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

Вы не увидите ни одного из перечисленных выше пакетов. Изучите свою рабочую группу, чтобы узнать, есть ли в сети некоторые из них, которые могут повлиять на переходы.

Если вы видите, что пакеты SYN находятся в точке назначения, но конечный объект по-прежнему не отвечает на запросы, убедитесь, что порт, к которому вы пытаетесь подключиться, находится в состоянии прослушивания. (Справка по результатам netstat поможет вам). Если порт прослушивается и по-прежнему не отвечает, это может привести к удалению WFP.

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

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

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

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

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

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

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

Сторона источника

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

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

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

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

Снимок экрана: флаг пакетов

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

Примечание

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

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

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

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

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

Снимок экрана: свойства событий

Затем выполните команду netsh wfp show state, чтобы создать файл вфпстате. XML. После того как вы откроете этот файл и отфильтровать идентификатор, который вы нашли в приведенном выше событии (2944008), вы увидите имя правила брандмауэра, связанного с этим ИДЕНТИФИКАТОРом, которое блокирует соединение.

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