Устранение неполадок с подключением TCP/IP
Попробуйте наш виртуальный агент . Он поможет вам быстро определить и устранить распространенные проблемы с репликацией Active Directory.
Вы можете столкнуться с ошибками подключения в конце приложения или с ошибками времени ожидания. Ниже приведены наиболее распространенные сценарии.
- Подключение приложений к серверу базы данных
- Ошибки времени ожидания 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:
Вы не увидите ни одного из указанных выше пакетов. Обратитесь к сетевой команде, чтобы изучить различные прыжки и узнать, может ли какой-либо из них вызвать падение сети.
Если вы видите, что пакеты SYN достигают назначения, но назначение по-прежнему не отвечает, убедитесь, что порт, к которому вы пытаетесь подключиться, находится в состоянии прослушивания. (Выходные данные Netstat помогут). Если порт прослушивает и по-прежнему нет ответа, то может быть падение мппы.
Неправильный параметр в заголовке TCP
Такое поведение возникает, когда пакеты изменяются в сети устройствами среднего уровня, а TCP на принимающем конце не может принять пакет, например изменяемый порядковый номер или пакеты, воспроизводимые средним устройством путем изменения порядкового номера. Опять же, одновременная трассировка сети в источнике и назначении сможет определить, будут ли изменены какие-либо заголовки TCP. Начните с сравнения трассировки источника и целевой трассировки. Вы сможете заметить, есть ли изменения в самих пакетах или какие-либо новые пакеты достигают назначения от имени источника.
В этом случае вам снова потребуется помощь от команды сети, чтобы определить любое устройство, которое изменяет пакеты или отправляет пакеты в место назначения. Наиболее распространенными из них являются устройства RiverBed или акселераторы глобальной сети.
Сброс на стороне приложения
Если вы определили, что сбросы не связаны с повторной отправкой или неправильным параметром или пакетами, изменяемыми с помощью трассировки сети, вы сузили его до сброса на уровне приложения.
Сбросы приложения — это те, где вы видите флаг подтверждения, равный 1, а также флаг сброса. Этот параметр означает, что сервер подтверждает получение пакета, но по какой-то причине не принимает подключение. На этом этапе приложению, получившей пакет, не понравилось то, что оно получило.
На снимках экрана ниже вы увидите, что пакеты, отображаемые в источнике и назначении, одинаковы без каких-либо изменений или удалений, но вы увидите явный сброс, отправленный назначением в источник.
Трассировка на стороне назначения
Вы также увидите пакет флага ACK+RST в случае отправки пакета создания TCP SYN. Пакет TCP SYN отправляется, когда клиент хочет подключиться к определенному порту, но если назначение или сервер по какой-либо причине не хочет принимать пакет, он отправляет пакет ACK+RST.
Приложение, которое вызывает сброс (определяется номерами портов), должно быть изучено, чтобы понять, что заставляет его сбрасывать подключение.
Приведенные выше сведения о сбросах с точки зрения 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), вы увидите имя правила брандмауэра, связанное с этим идентификатором, которое блокирует подключение.
Обратная связь
Были ли сведения на этой странице полезными?