Диагностика при недоступности ВМ по сети

Статья содержит описание принципов и методов диагностики сетевых проблем.

Для выполнения инструкций этой статьи подключитесь к диагностируемому серверу по SSH.

Типы настройки сети и принципы их работы

Порядок диагностики зависит от типа настройки сети.

Коммутация

Физический интерфейс на сервере узла и виртуальные интерфейсы ВМ подключены к одному и тому же бриджу. Маршрутизация в пределах сервера узла отсутствует. Для пакетов к ВМ, поступающих на физический интерфейс, ОС сервера узла определяет целевой виртуальный интерфейс при помощи ARP-запроса.

Маршрутизация

Виртуальные интерфейсы ВМ подключены к бриджу. Пересылка пакетов между физическим интерфейсом и бриджем осуществляется за счёт наличия маршрутов в ОС сервера узла:

• маршрута до подсети, из которой IP-адреса выдаются ВМ;
• хост-маршрутов до конкретных IP-адресов.

Далее пакет в бридже передаётся на виртуальный интерфейс.

IP fabric

На сервере узла отсутствует бридж. Пересылка пакетов между физическим и виртуальными интерфейсами осуществляется за счёт наличия хост-маршрутов до конкретных IP-адресов в ОС сервера узла. Актуальность маршрутов обеспечивается службой FRR.

Инструментарий

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

Linux

Утилиты для диагностики:

• arping — для обнаружения хостов в компьютерной сети;
• bridge — для управления bridge-интерфейсами;
• curl — для создания сетевых запросов по разным протоколам данных: FTP, FTPS, HTTP, HTTPS, TFTP и другим;
• dig — для проверки DNS-записей домена;
• ip — для проверки и настройки сетевых интерфейсов;
• iperf3 — для измерения пропускной способности сети;
• mtr — для проверки сетевого соединения;
• nc — для передачи и получения данных через протоколы TCP и UDP;
• nmap — для исследования сети и проверки безопасности;
• ping — для проверки доступности удалённого хоста;
• ss — для анализа сетевых соединений системы;
• tcpdump — для анализа сетевого трафика;
• tracepath и traceroute — для отображения возможных маршрутов пакетов.

Чтобы получить подробную информацию о возможностях, синтаксисе и ключах утилиты Linux, выполните команду:

man <утилита>

Если на диагностируемом сервере отсутствует нужная утилита, установите соответствующий пакет при помощи команд:

yum install <название_пакета>

 dnf install <название_пакета> 

apt install <название_пакета> 

Windows

Утилиты для диагностики:

• ipconfig — для управления сетевыми интерфейсами;
• netsh —  для отображения или изменения конфигурации сети;
• netstat — для отображения информации о соединениях системы по протоколам UDP и TCP;
• nslookup —  для выполнения DNS-запросов;
• ping — для проверки доступности удалённого хоста;
• route — для просмотра, удаления и добавления статических маршрутов в таблицу маршрутизации системы;
• tracert — для диагностики сети.

Предварительная диагностика

Чтобы исключить базовые проблемы, проведите предварительную диагностику:

1. Определите тип настройки сети в кластере. Для этого в веб-интерфейсе платформы перейдите в раздел Кластеры → Тип сети.
   
   

2. Проверьте доступность сервера узла:

   docker exec -it vm_box bash
   vmssh -p <порт_SSH> <IP_адрес_узла>

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

3. Убедитесь, что конфигурация сервера соответствует выбранному типу настройки сети.
   • коммутация:

     1. Проверьте наличие бриджа:

        ip address show
        

     2. Проверьте сетевые интерфейсы, подключённые к бриджу:

        bridge link show

   • маршрутизация:

     1. Проверьте наличие бриджа:

        ip address show

     2. Проверьте сетевые интерфейсы, подключённые к бриджу:

        bridge link show

     3. Проверьте наличие маршрутов:

        Для вывода списка IPv4-маршрутов

        ip route show

        Для вывода списка IPv6-маршрутов

        ip -6 route show

   • IP fabric:

     1. Проверьте наличие хост-маршрутов:

        Для вывода списка IPv4-маршрутов

        ip route show

        Для вывода списка IPv6-маршрутов

        ip -6 route show

Приведите конфигурацию в соответствие выбранному типу настройки сети. В сложных случаях (например, если отсутствует необходимый бридж) наиболее надёжный способ — удалить узел из кластера, переустановить ОС на сервере и подключить узел заново. Если это невозможно (узел уже в работе), исправьте настройки конфигурационных файлов:

• /etc/sysconfig/networks-scripts для CentOS 7, AlmaLinux 8;
• /etc/network/interfaces для Ubuntu 20.04, Astra Linux.

Диагностика сетевых проблем на сервере узла

1. Определите тип сетевой проблемы: гостевая ОС не отвечает на команду ping, недоступен какой-либо из TCP/UDP-портов и т.д. От настроек сетевого оборудования и ограничений провайдера зависит выбор утилит для поиска проблем. Например, если полностью заблокирован протокол ICMP, утилита ping будет бесполезна для диагностики.

2. Запустите на сервере узла утилиту tcpdump на физическом интерфейсе:

   tcpdump -i <название_интерфейса> -enn -vvv host <IP_адрес_ВМ>

3. Отправьте пакеты на проблемную ВМ в зависимости от выявленного типа проблемы:

   • если проверяете по ICMP:

     ping <IP_адрес_ВМ>

   • если проверяете доступность TCP-порта IPv4:

     nmap -Pn -sS <IPv4_адрес_ВМ> -p <порт_TCP>

   • если проверяете доступность UDP-порта IPv4:

     nmap -Pn -sU <IPv4_адрес_ВМ> -p <порт_TCP> 

   • если проверяете доступность TCP-порта IPv6:

     nmap -6 -Pn -sS <IPv6_адрес_ВМ> -p <порт_TCP>

   • если проверяете доступность UDP-порта IPv6:

     nmap -6 -Pn -sU <IPv6_адрес_ВМ> -p <порт_TCP>

Если в tcpdump на физическом интерфейсе не отображаются отправленные пакеты, проверьте наличие ARP-запросов (IPv4-трафик) или NDP-запросов (IPv6-трафик) к ВМ:

tcpdump -i <название_интерфейса> -enn -vvv arp | grep '<IPv4_адрес_ВМ>'

tcpdump -i <название_интерфейса> -enn -vvv icmp6 | grep '<IPv6_адрес_ВМ>' | grep -P 'advertisement|solicitaton'

# tcpdump -i enp2s0 -enn -vvv arp | grep '172.31.223.182'
...
19:09:23.205505 0c:c4:7a:15:db:94 > 52:54:00:f3:c3:ec, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 172.31.223.182 tell 172.31.223.254, length 46
19:09:23.205640 52:54:00:f3:c3:ec > 0c:c4:7a:15:db:94, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 172.31.223.182 is-at 52:54:00:f3:c3:ec, length 46

# tcpdump -i enp2s0 -enn -vvv arp | grep '172.31.223.182'
...
01:26:41.097832 a8:a1:59:3e:ba:2b > 4c:6d:58:45:29:4e, ethertype IPv6 (0x86dd), length 86: (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::aaa1:59ff:fe3e:ba2b > fe80::1: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::1
          source link-address option (1), length 8 (1): a8:a1:59:3e:ba:2b
            0x0000:  a8a1 593e ba2b
01:26:41.098597 4c:6d:58:45:29:4e > a8:a1:59:3e:ba:2b, ethertype IPv6 (0x86dd), length 78: (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::1 > fe80::aaa1:59ff:fe3e:ba2b: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::1, Flags [router, solicited]

В результате возможно два варианта:

• на физическом интерфейсе отсутствуют ARP/NDP-запросы. Это означает, что проблема не связана с работой узла. Для решения проблемы проконсультируйтесь с вашим сетевым инженером;
• на физическом интерфейсе есть ARP/NDP-запросы без ответов. В этом случае проверьте, что запросы пересылаются на виртуальный интерфейс ВМ:

1. Получите название виртуального интерфейса:

   virsh domiflist <ID_или_название_libvrit-домена_ВМ>

2. Проверьте запросы командами:

   ARP

   tcpdump -i <название_интерфейса> -enn -vvv arp | grep '<IPv4_адрес_ВМ>'

   NDP

   tcpdump -i <название_интерфейса> -enn -vvv icmp6 | grep '<IPv6_адрес_ВМ>' | grep -P 'advertisement|solicitaton'

Если ARP/NDP-запросы отображаются на виртуальном интерфейсе также без ответов, дальнейшая диагностика проводится в гостевой ОС.

Диагностика сетевых проблем в гостевой ОС ВМ

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

1. Сверьте настройки IPv4 или IPv6 в гостевой ОС с указанными для проблемной ВМ в платформе. Выполните команды:
   
   • Linux:

     • для вывода сетевых интерфейсов:

       ip address show

     • для вывода списка IPv4-маршрутов:

        ip route show  

     • для вывода списка IPv6-маршрутов:

       ip -6 route show

   • Windows:

     • для вывода списка сетевых интерфейсов:

       ipconfig /all

     • для вывода списка маршрутов:

       route print

2. На сервере узла запустите утилиту tcpdump на виртуальном интерфейсе проблемной ВМ:

   1. Получите название виртуального интерфейса:

      virsh domiflist <ID_или_название_libvrit-домена_ВМ>

   2. Выполните команду:

      tcpdump -i <название_интерфейса> -enn -vvv

3. Отправьте ICMP (утилита ping) или TCP/UDP (утилита nmap) пакеты на какой-либо внешний адрес. Возможны такие варианты ответа:
   • на виртуальном интерфейсе проблемной ВМ отправляемые пакеты не видны. В этом случае, вероятнее всего, проблема в настройках файрвола в гостевой ОС;
   • на виртуальном интерфейсе проблемной ВМ отправляемые пакеты видны. В этом случае запустите tcpdump на физическом интерфейсе сервера узла. Если пакеты видны и там, проблема возникает где-то за пределами узла. Для решения проблемы проконсультируйтесь с сетевым инженером;
   • пакеты теряются между виртуальным и физическим интерфейсом на сервере узла. В этом случае ещё раз проверьте корректность настроек сети и файрвола на узле.