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

Статья содержит методы диагностики сетевых проблем. Для выполнения инструкций этой статьи подключитесь к диагностируемому серверу по SSH. Подробнее о подключении по 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, выполните команду:

sudo man <утилита>

Если на сервере отсутствует нужная утилита, установите её:

sudo dnf install <название_утилиты> 

sudo apt install <название_утилиты> 

Windows

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

• ipconfig — для управления сетевыми интерфейсами;
• netsh —  для отображения или изменения конфигурации сети;
• netstat — для отображения информации о соединениях системы по протоколам TCP и UDP;
• 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 для AlmaLinux;
• /etc/network/interfaces для Ubuntu, 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. 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 на физическом интерфейсе узла кластера. Если пакеты видны и там, проблема возникает за пределами узла. Для решения проблемы проконсультируйтесь с сетевым инженером;
   • пакеты теряются между виртуальным и физическим интерфейсом на узле кластера. В этом случае повторно проверьте корректность настроек сети и файрвола на узле.