Как подтвердить наличие сетевого соединения

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

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

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

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

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

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

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

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

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

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

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

Шаг 2. Трассировка сети

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

Шаг 3. Проверка подлинности локального IP-адреса компьютера

Попробуйте проверить связь с локальным IP-адресом компьютера.

Если узел не может проверить связь со своим локальным IP-адресом, локальный стек не работает. Обратите внимание на все отображаемые сообщения об ошибках.

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

Проверьте, отображается ли красный символ «X» или желтый восклицательный знак на значке сетевого подключения в области задач. Красный значок X указывает, что Windows не обнаруживает сетевое подключение. Желтый восклицательный знак указывает, что индикатор состояния сетевого подключения (NSCI) не проверка пробы.

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

Также может возникнуть проблема между сетевым драйвером и Windows. Эта проблема обычно связана с повреждением стека. Выполните следующие действия по устранению неполадок:

Убедитесь, что на узле заданы последние биты (TCP/IP, NDIS, AFD, Winsock и т. д.).
Сбросьте IP-адрес и Winsock, выполнив следующие команды. Создайте резервную копию всей конфигурации сети.

netsh -c interface dump > C:\netConfig.txt netsh int ip reset netsh winsock reset

netsh -f C:\netConfig.txt

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

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

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

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

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

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

Ошибка недоступности конечного узла означает, что запросы ARP, отправляемые узлом, не получают ответа.
Соберите двусторонную трассировку из узлов, между которыми выполняется тестирование. Убедитесь, что запрос ARP, отправленный исходным узлом, достигает конечного узла и что конечный узел ответит соответствующим образом. Этот ответ должен быть виден в исходной трассировке. Если этот процесс завершается сбоем, проблема, скорее всего, связана с неправильной конфигурацией или другими проблемами, влияющими на инфраструктуру. Возможные причины:
1. Неправильные или несовпадение виртуальных локальных сетей.
2. Неправильная конфигурация порта переключения (порт магистрали и порта доступа).
3. Другие проблемы с оборудованием.
1. Telnet и PsPing лучше подходят для тестирования. Запустите Telnet или PsPing из исходного узла в конечный узел через порт прослушивания (например, 445).
2. Если шаг 1 выполнен успешно, внешнее подключение работает. Продолжайте тестировать базовое подключение.
3. Если шаг 1 не выполнен (и если профили брандмауэра отключены), соберите двусторонную netsh netconnection трассировку сценария для дальнейшего устранения неполадок.
Шаг 5. Связь или Telnet с шлюзом по умолчанию

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

Шаг 6. Проверка проблем, влияющих на конкретный конечный узел

Если исходный узел может выполнять связь, Telnet или PsPing с другими узлами в целевой подсети, то базовые подключения и маршрутизация в инфраструктуре работают. Этот результат указывает на проблему, которая влияет на конкретный конечный узел.
Примечание. Например, поставщиком приложений может быть корпорация Майкрософт, если проблема связана с неуспешным подключением к общей папке. В таких ситуациях было бы полезно выполнить двусторонную трассировку сценария netsh netconnection, чтобы собрать дополнительные сведения и убедиться, что в сетевом стеке нет проблем.
1. Убедитесь, что порт находится в состоянии прослушивания:
  CMD: netstat -nato | findstr :
  Powershell: Get-NetTcpConnection -LocalPort
2. Временно отключите все профили брандмауэра. (Примечание. Отключите только профили. Не отключайте службу.)
  В случае успешного выполнения брандмауэра необходимо перенастроить, чтобы разрешить трафик приложения по конкретному порту.
3. Удалите все сторонние приложения по одному и тестируйте между каждым удалением.
  В случае успеха обратитесь к поставщику проблемного программного обеспечения.
4. Попробуйте безопасный режим с сетевым подключением.
  Если это удалось, изолируйте причину, запустив «чистую загрузку» узла с помощью MSConfig, а затем включите сторонние приложения и службы по одному, пока проблема не повторится.
5. При воспроизведении попытки подключения следует выполнить трассировку сценария netsh netconnection из источника в затронутый конечный узел. Сетевой SDP также будет полезен.
Распространенные проблемы и решения

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..», так как часть IP-интерфейса идентификатора сети — 192.168.0.0.

Сбор данных

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

Предварительные требования
1. TSS должны запускаться учетными записями с правами администратора в локальной системе, а лицензионное соглашение должно быть принято (после принятия лицензионного соглашения TSS больше не будет запрашивать запрос).
2. Мы рекомендуем использовать политику выполнения PowerShell на локальном компьютере RemoteSigned .
Если текущая политика выполнения PowerShell не разрешает выполнение TSS, выполните следующие действия:
- RemoteSigned Задайте политику выполнения для уровня процесса, выполнив командлет PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned .
- Чтобы проверить, вступает ли в силу изменение, выполните командлет PS C:\> Get-ExecutionPolicy -List .
- Так как разрешения уровня процесса применяются только к текущему сеансу PowerShell, после закрытия заданного окна PowerShell, в котором выполняется служба TSS, назначенное разрешение для уровня процесса также вернется в ранее настроенное состояние.
Сбор ключевой информации перед обращением в службу поддержки Майкрософт
1. Скачайте TSS на всех узлах и распакуйте его в папку C:\tss .
2. Откройте папку C:\tss из командной строки PowerShell с повышенными привилегиями.
3. Запустите трассировку на исходном и целевом серверах с помощью следующего командлета:
```
TSS.ps1 -Scenario NET_General 
```
Примечание. Если вы собираете журналы как на клиенте, так и на сервере, дождитесь этого сообщения на обоих узлах, прежде чем воспроизвести проблему.

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

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

Были ли сведения на этой странице полезными?

Практическая работа № 13 «Решение проблем с tcp/ip»

Практическая работа № 14 «Работа с модемом на коммутируемых аналоговых линиях»

Цель: обобщение и систематизация знаний по теме «Межсетевое взаимодействие» Вид работы: фронтальный Время выполнения: 2 часа

Задания к работе
1. Составить таблицу стандартов на модемы. В таблицу должны быть внесены следующие стандарты: V.22, V.22 bis, V.32, V.32 bis, V.34, V.42, V.42 bis, V.90, V.92. Таблица должна содержать следующие сведения:
Название стандарта Стандарт определяет Основные технические характеристики

… … …
- разрешить эхо-вывод команд, передаваемых модему;
- разрешить ответ модема на АТ-команды в символьном виде;
- выводить сообщения модема об установлении связи в полном виде;
- номер набирается модемом после паузы при наличии гудка на линии;
- состояние «занято» определяется;
- сигнал DCD устанавливается только тогда, когда модем обнаруживает несущую частоту от удаленного модема;
- режим автоответа выключен;
- при тональном наборе длительность передачи одной цифры номера должна быть 55 миллисекунд.
1. Составить схему и описать локальный аналоговый тест с самотестированием
1. Назначение модемов.
2. Взаимодействие модемов с оконечным оборудованием и каналом связи.
3. Описать световые индикаторы на лицевой панели внешнего модема и их назначение.
Протокол TCP: что нужно знать специалисту по анализу сетевого трафика!

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

В каких случаях нам нужен анализ TCP пакетов?

Как показывает практика, современные системы анализа сетевого трафика имеют большую базу протоколов и готовых шаблонов для программного обеспечения. Это позволяет без труда разбивать транзакции на логические части. К сожалению, далеко не для всех задач бизнеса удаётся найти готовые продукты и в каждой компании обязательно найдётся парочка «самописных» или кастомизированных приложений. Как же анализировать трафик от таких приложений?

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

По своей сути TCP является протоколом транспортного уровня. Он позволяет осуществить соединение одного сокета (IP-адрес + порт) хоста источника с сокетом хоста назначения. Заголовок IP будет содержать информацию, связанную с IP-адресами, а заголовок TCP — информацию о порте.

Заголовок TCP

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

Рисунок 1. Заголовок TCP

В заголовке TCP содержаться следующие поля:
- Source port (16 бит): порт источника. Порт хоста, от которого исходит запрос.
- Destination port (16 бит): порт назначения. Порт хоста, куда направляется запрос.
- Sequence number, SYN (32 бита): порядковый номер. Позволяет контролировать порядок сообщений. Каждая конечная точка (как порт источника, так и порт назначения) будут поддерживать свой уникальный порядковый номер для отправляемых сообщений. При установлении соединения TCP (используется сообщение с установленным флагом SYN) в качестве изначального порядкового номера будет сгенерировано случайное число. Вернее, не совсем случайно сгенерировано, а будет содержать конкретное 32-битное число, то есть в пределах от 0 до 4294967295 (или 2 в 32-ой степени возможных вариантов), которое будет соответствовать времени, прошедшему после перегрузки системы отправителя (из расчета +1 за каждые прошедшие 4 микросекунды), а также увеличенное на 64000 каждый раз при установлении нового соединения. Так как сгенерированное число будет уникальным для периода времени почти в пять часов (если при этом никакие соединения не устанавливались), то такой подход к выбору порядкового номера позволяет избежать случайных коллизий при передаче данных, когда для нескольких пакетов из разных соединений будет совпадать порядковый номер. В дальнейшем, при отправке следующих пакетов, значение порядкового номера будет увеличиваться на +1 для всех пакетов с флагом SYN, пакетов с флагом FIN и для каждого байта отправленных данных. Это позволяет принимающей системе обрабатывать пакеты в правильной последовательности, как они были сформированы при отправлении, а не в том порядке, как они были получены.
- Acknowledgement number, ACK (32 бита): номер подтверждения. Когда сообщение содержит флаг ACK, то значение в номере подтверждения должно соответствовать следующему порядковому номеру (SYN), которое отправитель сообщения с флагом ACK ожидает получить от передающей системы. Таким образом, отправка одного номера подтверждения способна подтвердить получение всех байтов с информацией, полученных до этого. Более наглядно об использовании порядкового номера и номера подтверждения вы можете посмотреть на этом видео:
- Data offset (4 бита): длина заголовка, известная также как смещение данных. Содержит размер заголовка TCP, измеряемый в 32-битных сегментах. Минимальный размер заголовка TCP составляет пять 32-битных сегментов (всего 20 байт), а максимальный — пятнадцать 32-битных сегмента (или 60 байт).
- Reserved (3 бита): зарезервировано. Зарезервировано для будущего использования, пока просто забивается нулями. На данный момент осталось три незадействованных бита, в то время как еще три ранее зарезервированных бита уже используются как флаги.
- Flags, 9 бит (флаги или управляющие биты):
  - NS (1 бит): одноразовая сумма (Nonce Sum). Используется для улучшения работы механизма явного уведомления о перегрузке (Explicit Congestion Notification, ECN).
  - CWR (1 бит): окно перегрузки уменьшено (Congestion Window Reduced). Данный флаг устанавливается отправителем, чтобы показать, что TCP-фрагмент был получен с установленным полем ECE. Таким образом, это является подтверждением получения пакета данных с флажком ECE от хоста получателя и включением отправителем механизма уменьшения перегрузки (Congestion Control), позволяющим оптимизировать отправку пакетов с данными в перегруженных сетях, избежав серьезных задержек из-за отбрасывания пакетов.
  - ECE (1 бит): ECN-Эхо (ECN-Echo). Выполняет двойственную роль, в зависимости от значения флага SYN. При установленном флаге SYN это указывает на то, что отправитель пакета поддерживает ECN. Если флаг SYN сброшен (SYN=0), а ECE установлен, то это означает, что пакет с установленным флагом CE (Congestion Experienced, Подтвержденная перегрузка) был получен в заголовке IP во время обычной передачи. Таким образом, это служит индикатором перегрузки сети (или предстоящей перегрузки) для TCP-отправителя.
  - URG (1 бит). Устанавливается, если необходимо передать ссылку на поле указателя срочности (Urgent pointer).
  - ACK (1 бит). Устанавливается, когда пакет содержит значение номера подтверждения в поле подтверждения. Все пакеты после стартового пакета SYN будут иметь установленный флаг ACK.
  - PSH (1 бит). Делает этот пакет пакетом PUSH (проталкивания). При нормальном потоке передачи данных система получателя не будет подтверждать получение каждого пакета сразу же после его получения. Вместо этого система получателя в течении некоторого времени будет собирать и хранить полученные данные в буфере, пока не передаст их приложению пользователя. Пакет PUSH инструктирует систему получателя немедленно передать все полученные ранее данные из буфера в приложение пользователя и сразу же отправить сообщение с подтверждением.
  - RST (1 бит): сброс данного соединения. Отправкой пакета RST одна из сторон сообщает о немедленном разрыве соединения. При этом соединение обрывается, а буфер очищается. Самые распространенные причины отправки пакета с установленным флагом RST — ответ на пакет, полученный для закрытого сокета; пользователь сам прервал соединение (например, закрыв браузер, не дожидаясь ответа); соединение не было нормально закрыто, но находится в неактивном состоянии некоторое время.
  - SYN (1 бит). Начинает соединение и синхронизирует порядковые номера. Первый пакет, отправленный с каждой стороны, должен в обязательном порядке иметь установленным этот флаг.
  - FIN (1 бит). Одна из конечных точек отправляет пакет с установленным флагом FIN для другой конечной точки, чтобы сообщить, что все пакеты были отправлены, и соединение пора завершить.
  Механизм передачи сообщений TCP
  
  Перед тем, как данные могут быть переданы между двумя узлами, в TCP, в отличие от UDP, предусмотрена стадия установки соединения. Также, после того, как все данные были переданы, наступает стадия завершения соединения. Таким образом, осуществление каждого TCP-соединения можно условно разделить на три фазы:
  1. Инициализация соединения.
  Установка соединения осуществляется с помощью, так называемого трехстороннего рукопожатия TCP. Инициатором соединения может выступать любая сторона. Однако чтобы упростить рассмотрения данного вопроса в рамках данной статьи, мы рассмотрим пример, когда клиент инициализирует соединение с сервером.
  
  Рисунок 2. Трехстороннее рукопожатие TCP
  
  (Пакет №1). Клиент отправляет пакет с установленным флагом SYN и случайным числом («R1»), включенным в поле порядкового номера (sequence number).
  
  (Пакет №2). При получении пакета №1 сервер в ответ отправляет пакет с установленным флагом SYN, а также с установленным флагом ACK. Поле порядкового номера будет содержать новое случайное число («R2»), а поле номера подтверждения будет содержать значение порядкового номера клиента, увеличенного на единицу (то есть «R1 + 1»). Таким образом, он будет соответствовать следующему порядковому номеру, который сервер ожидает получить от клиента.
  
  (Пакет №3). В ответ на пакет SYN от сервера (пакет №2) клиент отправляет пакет с установленным флагом ACK и полем номера подтверждения с числом «R2 + 1». По аналогии, это число будет соответствовать следующему порядковому номеру, который клиент ожидает получить от сервера.
  1. Загрузка данных.
  После инициализации соединения полезная нагрузка будет перемещаться в обоих направлениях TCP-соединения. Все пакеты в обязательном порядке будут содержать установленный флаг ACK. Другие флаги, такие как, например, PSH или URG, могут быть, а могут и не быть установленными.
  1. Завершение соединения.
  При нормальном завершении TCP-соединения в большинстве случаев инициализируется процедура, называемая двухсторонним рукопожатием, в ходе которой каждая сторона закрывает свой конец виртуального канала и освобождает все задействованные ресурсы. Обычно эта фаза начинается с того, что один из задействованных процессов приложения сигнализирует своему уровню TCP, что сеанс связи больше не нужен. Со стороны этого устройства отправляется сообщение с установленным флагом FIN (отметим, что этот пакет не обязательно должен быть пустым, он также может содержать полезную нагрузку), чтобы сообщить другому устройству о своем желании завершить открытое соединение. Затем получение этого сообщения подтверждается (сообщение от отвечающего устройства с установленным флагом ACK, говорящем о получении сообщения FIN). Когда отвечающее устройство готово, оно также отправляет сообщение с установленным флагом FIN, и, после получения в ответ подтверждающего получение сообщения с установленным флагом ACK или ожидания определенного периода времени, предусмотренного для получения ACK, сеанс полностью закрывается. Состояния, через которые проходят два соединенных устройства во время обычного завершения соединения, отличаются, потому что устройство, инициирующее завершение сеанса, ведет себя несколько иначе, чем устройство, которое получает запрос на завершение. В частности, TCP на устройстве, получающем начальный запрос на завершение, должен сразу информировать об этом процесс своего приложения и дождаться от него сигнала о том, что приложение готово к этой процедуре. Инициирующему устройству не нужно это делать, поскольку именно приложение и выступило инициатором. Более подробно завершении TCP-соединения смотрите здесь (http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm).
  
  Рисунок 3. Завершение TCP-соединения
  - Keep-alive или повторное использование соединений
  На уровне TCP нет сообщений типа «keep-alive», и поэтому, даже если сеанс соединения в какой-то момент времени становится неактивным, он все равно будет продолжаться до тех пор, пока не будет отправлен следующий пакет.
  
  Когда мы отправляем HTTP-запрос по сети, нам сразу нужно создать TCP-соединение. Однако в HTTP 1.0 возможность повторного использования соединения по умолчанию закрыта (если заголовок «keep-alive = close» дополнительно не включен в заголовок HTTP), то есть TCP-соединение автоматически закрывается после получения запроса и отправки ответа. Так как процесс создания TCP-соединения относительно затратный (он требует дополнительных затрат процессорных ресурсов и памяти, а также увеличивает сетевой обмен между сервером и клиентом, что особенно становится актуальным при создании защищенных соединений), то все это увеличивает количество лагов и повышает вероятность перегрузки сети. Поэтому для HTTP 1.1 было решено оставлять TCP-соединение открытым до тех пор, пока одна из сторон не решит прекратить его.
  
  С другой стороны, если соединения не будут закрываться после того, как клиенты получат все необходимые им данные, задействованные ресурсы сервера для поддержания этих соединений не будут доступны другим клиентам. Поэтому HTTP-серверы, чтобы обеспечить больший контроль над потоком данных, используют временные интервалы (таймауты) для поддержки функциональности «keep-alive» для неактивных соединений (длящихся по умолчанию, в зависимости от архитектуры и конфигурации сервера, не более нескольких десятков секунд, а то и просто нескольких секунд), а также максимальное число отправляемых запросов «keep-alive», прежде чем сеанс без активного соединения будет остановлен. Более подробно о функциональности «keep-alive» вы можете узнать здесь (https://blog.stackpath.com/glossary/keep-alive/).
  
  Вступайте в Telegram канал проекта NetworkGuru, чтобы не пропустить интересные статьи и вебинары.
  
  Подписывайтесь на рассылку, делитесь статьями в соцсетях и задавайте вопросы в комментариях!
  
  Вечный параноик, Антон Кочуков.
  
  Диагностика сетевого подключения (ping, arp, traceroute, dig, nslookup)
  
  Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
  
  Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
  
  Диагностика сетевой связности (ping, arp, traceroute)
  
  В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
  
  В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
  
  В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
  
  Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
  
  В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
  
  Если в настройках интерфейса есть ошибки, их необходимо исправить — помогут в этом другие статьи, для ОС Ubuntu 18.04 или CentOS. Если же все верно — приступаем к диагностике с помощью утилиты ping. Данная команда отправляет специальные сетевые пакеты на удаленный IP-адрес (ICMP Request) и ожидает ответные пакеты (ICMP Reply). Таким образом можно проверить сетевую связность — маршрутизируются ли сетевые пакеты между IP-адресами отправителя и получателя.
  
  Синтаксис команды ping IP/имя опции:
  
  В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
  
  Часто используемые параметры:
  - ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
  - ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
  - ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).
  В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
  
  Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволлом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрволла рассказано здесь и здесь.
  
  Часто используемые параметры:
  - arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
  - arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
  Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
  
  В случае проблем на этом шаге, нам может помочь утилита traceroute, которая используя ту же логику запросов и ответов помогает увидеть маршрут, по которому движутся сетевые пакеты. Запускаем traceroute 8.8.8.8 –n и изучаем вывод программы:
  
  Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
  
  Часто используемые опции:
  - traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
  - traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
  - traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
  - traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
  Диагностика разрешения имен (nslookup, dig)
  
  Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
  
  Самый простой способ проверить работает ли разрешение имен — запустить утилиту ping с указанием доменного имени вместо IP-адреса (например, ping ya.ru). Если ответные пакеты от удаленного сервера приходят, значит все работает как надо. В противном случае нужно проверить прописан ли DNS-сервер в сетевых настройках и удается ли получить от него ответ.
  
  Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
  
  В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve –status:
  
  Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.
  
  Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:
  
  yum install bind-utils
  sudo apt install dnsutils
  
  После успешной установки сделаем тестовые запросы:
  
  В разделе Answer Section видим ответ от DNS сервера — IP-адрес для A-записи с доменным именем ya.ru. Разрешение имени работает корректно:
  
  nslookup ya.ru
  
  Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
  
  Что же делать, если в ответе отсутствует IP-адрес? Возможно, DNS-сервер недоступен. Для проверки можно отправить тестовый запрос на другой DNS-сервер. Обе утилиты позволяют эти сделать. Направим тестовый запрос на DNS-сервер Google:
  
  dig @8.8.8.8 ya.ru
  
  nslookup ya.ru 8.8.8.8
  
  Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрволла отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
  
  Часто используемые параметры:
  - nslookup имя сервер — разрешить доменное имя, используя альтернативный сервер;
  - nslookup –type=тип имя — получить запись указанного типа для доменного имени (например, nslookup -type=mx ya.ru – получить MX-записи для домена ya.ru);
  - dig @сервер имя — разрешить доменное имя, используя альтернативный сервер;
  - dig имя тип — получить запись указанного типа для доменного имени (например, dig ya.ru mx — получить MX-записи для домена ya.ru).
  Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
  Похожие публикации: