Главная → Академия → Монтаж и пусконаладка контроллера → Проверка DNS и доступа в интернет

Проверка DNS и доступа в интернет

Урок 4 · Монтаж и пусконаладка контроллера · 10 мин · theory

Введение: Роль DNS в работе контроллера HI

Для полноценного функционирования в современной экосистеме автоматизации контроллер HI должен иметь стабильный и надежный доступ к сети Интернет. Однако само по себе наличие IP-адреса и возможность "достучаться" до шлюза, как мы рассматривали в предыдущих уроках, не гарантирует полноценной работы. Ключевым, но часто упускаемым из виду компонентом, является система DNS (Domain Name System).

Простыми словами, DNS — это глобальная "телефонная книга" интернета. Когда контроллер должен подключиться к облачному сервису по имени, например, `cloud.hi.auto`, он не знает IP-адрес этого сервера. Контроллер обращается к специальному DNS-серверу (адрес которого он обычно получает от роутера по DHCP) и спрашивает: "Какой IP-адрес у домена `cloud.hi.auto`?". DNS-сервер отвечает: "Его адрес `185.125.88.10`". Только после этого контроллер может установить соединение.

Критическая важность исправной работы DNS для контроллера HI обусловлена следующими функциями:

* Синхронизацию с платформой удаленного доступа `cloud.hi.auto`.

* Получение данных о погоде для сценариев климат-контроля.

* Взаимодействие с голосовыми ассистентами (Яндекс Алиса, Google Assistant, Apple HomeKit).

* Отправка Push-уведомлений на смартфоны пользователей.

Последствия сбоев DNS могут быть катастрофическими для стабильности объекта. Если DNS-сервер, предоставленный провайдером или настроенный на роутере объекта, перестает отвечать или работает нестабильно, инсталлятор столкнется с трудно диагностируемыми проблемами: сценарии, завязанные на облачные сервисы, перестают работать без видимых ошибок в логах Node-RED, контроллер "живет" с неправильным временем, а попытки обновления заканчиваются неудачей.

> 💡 Подсказка: Для максимальной надежности системы рекомендуется использовать проверенные публичные DNS-серверы (например, Google `8.8.8.8` или Cloudflare `1.1.1.1`) в качестве вторичных или даже первичных. Это обеспечивает резервный канал разрешения имен на случай, если основной DNS-сервер, предоставленный провайдером, выйдет из строя или будет блокировать доступ к определенным ресурсам.

---

Диагностика DNS с помощью утилиты nslookup

Когда вы сталкиваетесь с проблемой, где контроллер имеет IP-адрес, пингует шлюз, но не может получить доступ к облачным сервисам, первым подозреваемым должен быть DNS. Стандартная утилита в операционной системе Debian, на которой базируется контроллер HI, для этой задачи — `nslookup`.

`nslookup` (name server lookup) — это консольная программа, которая позволяет отправлять запросы к DNS-серверам и анализировать их ответы. Это основной инструмент инженера для проверки здоровья системы разрешения имен.

Базовое использование

Основной синтаксис команды предельно прост: `nslookup [имя_домена]`. Подключитесь к командной строке контроллера через SSH и выполните проверку ключевых для системы доменов.

Пример 1: Проверка разрешения имени сервера времени 
# Запрашиваем IP-адрес для пула серверов времени

nslookup pool.ntp.org

Успешный ответ будет выглядеть примерно так:

Server:		192.168.1.1

Address:	192.168.1.1#53



Non-authoritative answer:


Name:	pool.ntp.org


Address: 195.80.50.8


Name:	pool.ntp.org


Address: 78.155.216.134


Name:	pool.ntp.org


Address: 85.143.64.91


...
Анализ ответа:

Если же DNS не работает, вы получите сообщение об ошибке, например:

;; connection timed out; no servers could be reached

Это означает, что контроллер не смог даже связаться с DNS-сервером `192.168.1.1`.

> ⚠️ Внимание: Частая ошибка инсталляторов — полагаться только на DNS-серверы, выдаваемые роутером объекта по DHCP. Они могут быть ненадежны, работать медленно или даже блокировать определенные ресурсы по требованию провайдера. Прямой запрос к публичному DNS с помощью `nslookup [domain] [dns_server]` позволяет быстро локализовать проблему: дело в неисправности DNS-сервера на объекте или проблема с самим интернет-каналом.

Расширенное использование: запрос к конкретному DNS-серверу

Чтобы проверить, не является ли источником проблемы DNS-сервер, выданный роутером, можно отправить запрос напрямую к надежному публичному DNS. Для этого в команде `nslookup` нужно указать IP-адрес этого сервера.

Пример 2: Проверка разрешения имени через DNS Google 
# Запрашиваем IP-адрес для облачной платформы HI, используя сервер 8.8.8.8

nslookup cloud.hi.auto 8.8.8.8

Успешный ответ:

Server:		8.8.8.8

Address:	8.8.8.8#53



Non-authoritative answer:


Name:	cloud.hi.auto


Address: 185.125.88.10

Если эта команда работает, а базовый `nslookup cloud.hi.auto` — нет, вы с уверенностью можете заключить, что проблема именно в DNS-сервере, который используется контроллером по умолчанию, а не в интернет-подключении в целом. Решение — сменить DNS-серверы в настройках контроллера.

---

Конфигурация DNS-серверов в контроллере HI

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

Файл `/etc/resolv.conf`: временное решение

Основной файл, который система использует для определения DNS-серверов, — это `/etc/resolv.conf`. Его содержимое крайне простое:

# cat /etc/resolv.conf

nameserver 192.168.1.1


nameserver 8.8.8.8

Каждая строка `nameserver [IP-адрес]` указывает системе на DNS-сервер. Система будет опрашивать их по порядку. Если первый не ответит, она перейдет ко второму.

Проблема: Во многих конфигурациях, особенно при получении сетевых настроек по DHCP, этот файл генерируется автоматически системными службами. Если вы отредактируете его вручную, ваши изменения будут перезаписаны при следующей перезагрузке контроллера или переподключении сетевого интерфейса. Поэтому редактирование `/etc/resolv.conf` напрямую подходит только для быстрой временной диагностики, но не для постоянной конфигурации.

Постоянная конфигурация DNS

Для надежной и постоянной настройки DNS-серверов на контроллере HI следует использовать один из двух методов.

🔗 Связанный материал: Принципы настройки статических IP-адресов и шлюзов, рассмотренные в уроке COURSE-03-M03-L02, напрямую применяются и для указания статических DNS-серверов.

1. Использование утилиты `hi_netconf` (рекомендуемый способ)

Платформа HI включает в себя специальную утилиту для упрощения сетевой конфигурации. Для задания статических DNS-серверов используется команда с соответствующими параметрами.

# Установить DNS-серверы: первичный от роутера, вторичный - Google

sudo hi_netconf --set-dns 192.168.1.1 8.8.8.8

Эта утилита корректно внесет изменения в системные конфигурационные файлы, гарантируя их сохранение после перезагрузки.

2. Ручное редактирование `/etc/network/interfaces`

Этот способ является более низкоуровневым, но дает полный контроль над конфигурацией. Он особенно полезен при настройке статического IP-адреса. Для этого необходимо отредактировать файл `/etc/network/interfaces`, добавив в секцию нужного интерфейса (например, `eth0`) параметр `dns-nameservers`.

Пример конфигурации Ethernet-интерфейса со статическим IP и DNS: 
# /etc/network/interfaces


# The primary network interface


auto eth0


iface eth0 inet static


    address 192.168.1.100         # Статический IP-адрес контроллера


    netmask 255.255.255.0         # Маска подсети


    gateway 192.168.1.1           # Шлюз (IP-адрес роутера)


    dns-nameservers 8.8.8.8 1.1.1.1 # Основной и резервный DNS-серверы

В данном примере мы жестко задаем два публичных DNS-сервера: Google (`8.8.8.8`) и Cloudflare (`1.1.1.1`). После сохранения файла и перезагрузки сети (`sudo systemctl restart networking`) или всего контроллера, эти настройки будут применены и сохранены. Файл `/etc/resolv.conf` будет автоматически сгенерирован с этими адресами.

---

Проверка полного доступа в интернет: curl и wget

Даже если `ping` доменного имени проходит успешно (что означает, что DNS работает и хост доступен на сетевом уровне), это еще не гарантирует полноценного доступа. `ping` использует протокол ICMP, в то время как большинство облачных сервисов работают по протоколам HTTP и HTTPS (порты 80 и 443). На роутере объекта может быть настроен файрвол, который разрешает ICMP-трафик, но блокирует HTTP/HTTPS.

Для окончательной проверки "сквозного" доступа до веб-сервиса на уровне приложения используются утилиты `curl` или `wget`.

Утилита `curl` — швейцарский нож для веб-запросов

`curl` — это мощная утилита командной строки для передачи данных с использованием различных протоколов, включая HTTP и HTTPS. Для инженера-установщика это лучший способ убедиться, что контроллер может "достучаться" до нужного API.

Наиболее полезный режим для быстрой диагностики — запрос только HTTP-заголовков с помощью флага `-I` или подробного лога соединения с флагом `-v`.

Практический пример: проверка доступа к `google.com` 
# Запрашиваем только заголовки ответа с сайта google.com

curl -I https://google.com

Успешный ответ будет содержать код `200 OK`, что означает полную доступность сервиса:

HTTP/2 200 

content-type: text/html; charset=ISO-8859-1


p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."


date: Wed, 25 Oct 2023 12:00:00 GMT


server: gws


...

Ключевая строка здесь — `HTTP/2 200`. Это однозначное подтверждение того, что:

  • DNS-имя `google.com` успешно разрешилось.
  • TCP-соединение на порт 443 (HTTPS) было установлено.
  • SSL/TLS-рукопожатие прошло успешно.
  • Веб-сервер получил наш запрос и ответил на него кодом "Успешно".
    • Анализ ошибок:

    Если `curl` завершается ошибкой, ее текст дает ценную информацию для диагностики:

    Утилита `wget` выполняет схожие функции, но `curl` считается более гибким инструментом именно для диагностических запросов.

    ---

    Резюме: Алгоритм поиска неисправностей

    Сталкиваясь с проблемой "облачные сервисы не работают", инженер должен действовать методично, проверяя сетевое взаимодействие слой за слоем, от физического до прикладного. Хаотичные действия приводят только к потере времени.

    > ℹ️ Информация: Системный подход к диагностике сети экономит часы на объекте. Всегда двигайтесь от нижних уровней модели OSI/TCP/IP (физика, IP) к верхним (DNS, HTTP).

    📋 Пошаговый чеклист для диагностики отсутствия доступа к облачным сервисам

  • Шаг 1: Проверка физического подключения и IP-адресации.

    • * Действие: Выполните в консоли команду `ip a` или `ifconfig`.

    * Ожидаемый результат: Убедитесь, что нужный интерфейс (`eth0` или `wlan0`) поднят (статус `UP`) и ему присвоен корректный IP-адрес из сети объекта.

    * Если нет: Проверьте физическое подключение кабеля Ethernet или настройки Wi-Fi, как было рассмотрено ранее.

  • Шаг 2: Проверка доступности шлюза.

    • * Действие: Выполните команду `ping [gateway_ip]`, где `[gateway_ip]` — это IP-адрес вашего роутера (например, `ping 192.168.1.1`). См. урок `COURSE-03-M03-L04`.

    * Ожидаемый результат: Стабильные ответы от шлюза с низким временем отклика.

    * Если нет: Проблема в локальной сети между контроллером и роутером, либо неверно указан адрес шлюза в настройках.

  • Шаг 3: Проверка разрешения доменных имен (DNS).

    • * Действие: Выполните `nslookup cloud.hi.auto`.

    * Ожидаемый результат: Получение IP-адреса для домена.

    * Если нет: Проблема с DNS. Выполните `nslookup cloud.hi.auto 8.8.8.8` для изоляции проблемы. Если вторая команда работает, исправьте конфигурацию DNS-серверов в контроллере.

  • Шаг 4: Проверка доступа к веб-ресурсам (прикладной уровень).

    • * Действие: Выполните `curl -I https://cloud.hi.auto` или `curl -v https://api.weather.com`.

    * Ожидаемый результат: Ответ от сервера с кодом `HTTP 200 OK`.

    * Если нет: Проблема, скорее всего, связана с файрволом, блокирующим порты 80 (HTTP) или 443 (HTTPS). Изучите текст ошибки, который выдаст `curl`.

    Краткий обзор частых причин:

    Что дальше

    В этом уроке мы завершили изучение базовых инструментов диагностики сети на уровне операционной системы контроллера. Вы научились системно подходить к поиску неисправностей, связанных с доступом в интернет, и освоили ключевые утилиты: `nslookup` и `curl`. В следующем разделе мы перейдем к практическим лабораторным работам, где вы сможете на реальном оборудовании применить все полученные знания для настройки и диагностики сетевых подключений контроллера HI.