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

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

Область применения: поддерживаемые версии клиента Windows и Windows Server

В этой статье содержится комплексное руководство по устранению ошибок подключения TCP/IP.

Симптомы и анализ

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

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

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

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

Введение в TCP

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

• Четырехсторонняя закрытие, когда отправитель и получатель согласны закрыть сеанс, называется изящным закрытием. Это определяется флагом FIN в заголовке TCP, равным 1.

• После четырехсторонного закрытия компьютер ожидает 4 минуты (по умолчанию) перед освобождением порта. Это называется состоянием TIME_WAIT. Во время этого TIME_WAIT состояния все ожидающие пакеты для TCP-подключения можно обрабатывать. После завершения состояния TIME_WAIT все ресурсы, выделенные для подключения, освобождаются.

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

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

Потеря пакетов по сети

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

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

Сценарий 1. Потеря пакетов во время первоначального подтверждения TCP

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

Примечание.

Количество повторов передачи пакета TCP SYN может отличаться в зависимости от ОС. Это определяется значением Max SYN Retransmissions в параметрах TCP Global , которые можно просмотреть с помощью команды netsh int tcp show global.

Предположим, что исходный компьютер с IP-адресом 10.10.10.1 подключается к назначению с IP-адресом 10.10.10.2 через TCP-порт 445. Ниже приведен снимок экрана трассировки сети, собранной на исходном компьютере, в котором показана начальная подтверждение TCP, в которой отправляется пакет TCP SYN, а затем повторно передается источником, так как ответ не был получен из назначения.

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

Если пакеты TCP SYN достигают назначения, но назначение не отвечает, убедитесь, что TCP-порт, подключенный к нему, находится в состоянии ПРОСЛУШИВАНИЯ на целевом компьютере. Это можно проверить в выходных данных команды netstat -anob.

Если порт прослушивает, и по-прежнему нет ответа, может произойти падение на платформе фильтрации Windows (МПП).

Сценарий 2. Потеря пакетов во время установки tcp-подключения после передачи данных

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

Предположим, что исходный компьютер с IP-адресом 192.168.1.62 установил подключение к конечному компьютеру с IP-адресом 192.168.1.2 через TCP-порт 445. Исходный компьютер отправляет данные (пакет SMB Negotiate), который повторно передается пять раз, как показано ниже. После отсутствия ответа от назначения исходный компьютер отправляет ACK-RST, чтобы закрыть это TCP-подключение.

Источник 192.168.1.62 боковой трассировки:

Вы не увидите ни одного из указанных выше пакетов, достигающих назначения.

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

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

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

Одновременная трассировка сети в источнике и назначении может помочь определить любые изменения заголовков TCP.

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

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

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

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

Сбросы на уровне приложения характеризуются флагом подтверждения (ACK), равным 1 вместе с флагом сброса (R). Это означает, что сервер подтверждает получение пакета, но не принимает подключение по какой-то причине. Эта проблема обычно возникает, когда приложение, получающее пакет, находит что-то неприемлемое в данных.

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

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

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

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

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

Примечание.

Приведенные выше сведения относятся к сбросам с точки зрения TCP, а не UDP. UDP — это протокол без подключения, и пакеты отправляются ненадежно. Следовательно, при использовании UDP в качестве транспортного протокола не наблюдается повторная передача или сброс. Однако UDP использует ICMP в качестве протокола отчетов об ошибках. Когда пакет 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

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

Чтобы определить, удаляется ли локальный брандмауэр Windows, включите аудит платформы фильтрации Windows на компьютере с помощью следующей команды.

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

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

Затем выполните команду netsh wfp show state , которая создает файл wfpstate.xml .

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