Сетевик Джонни // Network Admin

📢 MPLS в маршрутизаторах ESR. Часть 1. L2VPN Пришло время разобраться, почему MPLS называют «слоем 2.5» и как заставить его работать на благо вашей сети. Начинаем серию вебинаров по технологии, которая не теряет актуальности! 📌 3 апреля 2026 (пятница) 🕐 14:00 (по МСК) 📚 Что разберем на первой встрече: ➖Вспомним теорию — зачем вообще нужен MPLS и почему его называют «L2.5» ➖L2VPN Martini mode ➖L2VPN Kompella mode 🎙 Спикер: Алексей Листаров — инженер с многолетним опытом работы в крупном операторе связи. Сертифицированный преподаватель нашего авторизованного центра Академии Eltex. 👉Регистрация Готовьте свои вопросы по конфигурации, будем разбираться вместе! 📱 @eltexcm #eltex #eltexcm #webinar #вебинар #esr #mpls #kompella #martini #mode О рекламодателе

Telegram в России ЗАБЛОКИРОВАН на ~80% — пишут СМИ. В отдельных федеральных округах цифра близится к 90%. в этом даже есть плюс, отсортируют действительно заинтересованных лиц в свободном, НЕ цензурированом интернете. 👮‍♀️ Личный VPN: юзер ликует, VLESS смеётся, а РКН плачет. v.2 (цветет и пахнет, пинг минимальный 200-300ms)

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf? Мы уже знаем, как dhclient и resolvconf пишут настройки DNS. Но что происходит, когда в игру вступают тяжеловесы вроде NetworkManager, systemd-resolved, отдельно стоящий unbound или корпоративный BIND? А если сверху это всё приправлено облачной инициализацией cloud-init и абстракцией netplan? Файл /etc/resolv.conf может вести себя непредсказуемо. 🔍 systemd-resolved — это локальный кэширующий dns-сервер (systemd-networkd), процесс systemd-resolved слушает 127.0.0.53:53, и nameserver в resolv.conf указывает на 127.0.0.53 соответственно. Файл /etc/resolv.conf обычно является symlink на /run/systemd/resolve/stub-resolv.conf В свою очередь /run/systemd/resolve/stub-resolv.conf — содержит 127.0.0.53, а прямой список upstream DNS можно найти в файле /run/systemd/resolve/resolv.conf. Диагностика: # Основная информация о состоянии resolvectl status # Статистика запросов resolvectl statistics # Информация по конкретному интерфейсу resolvectl status eth0 🖥 dnsmasq — это простой DHCP/DNS сервер, который работает зачастую как локальный кэш на 127.0.0.1:53. Обычно dnsmasq не пишет в resolv.conf самостоятельно, а читает upstream из resolv.conf, использует директиву --server= при запуске, или сервера прописаны в конфигурационном файле /etc/dnsmasq.conf. Диагностика: # Перезагрузка конфигурации sudo kill -USR1 $(pidof dnsmasq) # Проверка параметров запуска ps aux | grep dnsmasq 🕹 NetworkManager — это инструмент для автоматической настройки сети в большинстве современных десктопных и серверных дистрибутивах Linux. Был разработан компанией Red Hat в 2004 году для упрощения современных сетевых задач. Взаимодействие с ним настолько “упрощает” работу с сетью, что очень многие системные администраторы отключают его сразу.

— Обычно NetworkManager получает настройки от DHCP (через внутренний DHCP-плагин или внешний dhclient), принимая DNS-серверы из DHCP-ответа (опция option domain-name-servers), и передает их в системную службу управления DNS.

Поведение при обработке DHCP DNS можно контролировать через параметр ipv4.ignore-auto-dns: ipv4.ignore-auto-dns=no (по умолчанию) - NM использует DNS-серверы, полученные от DHCP ipv4.ignore-auto-dns=yes - игнорировать DNS от DHCP и использовать только статически заданные серверы Сам NetworkManager не обрабатывает DNS-запросы и не слушает порт 53, а в зависимости от настроек запускает dnsmasq (который слушает 127.0.0.1:53) или взаимодействует с systemd-resolved (обычно слушает 127.0.0.53:53). Что запускается - зависит от параметра dns в /etc/NetworkManager/NetworkManager.conf: dns=systemd-resolved — используется только systemd-resolved. dns=dnsmasq — запускается dnsmasq через NetworkManager. dns=none — NetworkManager не берет на себя функции управления резолвингом DNS dns=default — NetworkManager сам решает, что делать. При взаимодействии с systemd-resolved NetworkManager выступает в роли менеджера конфигурации, передавая параметры DNS через D-Bus API systemd-resolved, но не участвуя в обработке DNS-запросов напрямую. Тогда у нас будет наблюдаться следующая картина: resolvectl status # отображает текущие DNS-серверы, которые systemd-resolved получил от NetworkManager nmcli dev show | grep DNS # показывает DNS-серверы, которые NetworkManager передал в systemd-resolved

🔍 dhclient — стандартный DHCP-клиент в Linux-системах, входящий в пакет ISC DHCP. Его основная задача автоматически получать настройки сети (IP-адрес, сетевую маску, шлюз, DNS-сервера) у DHCP-сервера и применять их локально. По умолчанию DHCP-клиент (программа /sbin/dhclient) не изменяет /etc/resolv.conf напрямую. Вместо этого вызывается вспомогательный скрипт /sbin/dhclient-script, который получает параметры (в том числе DNS-серверы) от DHCP-сервера. — Внутри dhclient-script есть функция make_resolv_conf(), которая формирует содержимое файла /etc/resolv.conf и записывает новые настройки DNS. Кроме того используются так называемые хуки (скрипты), которые лежат в каталогах /etc/dhcp/dhclient-exit-hooks.d/ или /etc/dhcp/dhclient-enter-hooks.d/. Они позволяют изменить логику формирования или перезаписи /etc/resolv.conf, переопределяя функции или добавляя свои параметры. Диагностика: # Проверить конфигурацию DHCP-клиента cat /etc/dhcp/dhclient.conf # Запустить dhclient в debug-режиме dhclient -v -d <интерфейс> # выведет подробный лог, включая обработку DNS). # Проверить lease-файл DHCP** cat /var/lib/dhcp/dhclient.leases # там хранятся полученные параметры, включая DNS-серверы 🖥 resolvconf — это устаревший, но иногда встречающийся служебный инструмент для централизованного управления содержимым файла /etc/resolv.conf в UNIX-подобных системах. Он сохраняет и обновляет /etc/resolv.conf, собирая настройки DNS с различных источников: DHCP-клиентов, VPN-клиентов, сетевых интерфейсов, NetworkManager, позволяет нескольким программам и сервисам вносить свои DNS-серверы, динамически формируя итоговый конфиг для системы. — Работает как демон или в виде набора скриптов-хуков, которые вызываются при изменении сетевой конфигурации, принимает входящие DNS-настройки через программу или скриптовые вызовы, обновляет кэш и генерирует конечный /etc/resolv.conf. В resolvconf используются шаблоны для формирования итогового файла DNS: - /etc/resolvconf/resolv.conf.d/head — вставляется в начало результата. - /etc/resolvconf/resolv.conf.d/base — база доменов и серверов. - /etc/resolvconf/resolv.conf.d/tail — добавляется в конец. resolvconf может использоваться другими службами (например, NetworkManager, dhclient, openvpn) для централизованного обновления DNS-конфига.

В современных дистрибутивах часто заменяется или отключается в пользу systemd-resolved или других решений, но поддерживается для обратной совместимости.

Диагностика: # Вывод актуальной информации resolvconf -l # Обновить /etc/resolv.conf resolvconf -u В следующем посте продолжим навигацию по этому лабиринту: разберёмся, как systemd-resolved, dnsmasq, NetworkManager, unbound, BIND, cloud-init и netplan управляют /etc/resolv.conf, в каких случаях они конфликтуют, а когда — работают сообща, и какие рычаги у нас остаются над DNS. Ставьте 👍 #DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 3: кто на самом деле управляет resolv.conf? Когда-то давным-давно в далекой Галактике DNS настраивался простым редактированием /etc/resolv.conf: nameserver 8.8.8.8 nameserver 1.1.1.1 search example.com Сейчас же файл с содержанием nameserver 127.0.0.53 и предупреждением “DO NOT EDIT” может шокировать. Причина такого изменения в эволюции DNS-инфраструктуры: Раньше: приложения → resolv.conf → DNS-сервер Сейчас: приложения → локальный DNS-прокси → upstream серверы В современных дистрибутивах /etc/resolv.conf – это чаще всего не ручная настройка, а автоматически генерируемый конфиг, создаваемый и поддерживаемый системными компонентами: systemd-resolved, NetworkManager, resolvconf или их аналогами вроде openresolv. Эта автоматизация приносит гибкость (разные DNS для разных сетей, DNSSEC, LLMNR/mDNS), но с другой стороны и некоторые потенциальные проблемы: • Настройки могут слетать после перезагрузки сети или обновления пакетов. • Конфликты при подключении VPN, которые пытаются переписать DNS. • Сложности с использованием локальных доменов или специфичных DNS-серверов. • Затрудненная отладка: куда на самом деле идут запросы? Так кто же главный? systemd-resolved? NetworkManager? Как вернуть себе контроль? В следующем посте разберёмся в этом лабиринте: какие инструменты претендуют на управление /etc/resolv.conf, как они взаимодействуют и какие рычаги управления у нас есть, чтобы заставить DNS работать так, как нам нужно. Ставьте 👍 #DNS #Linux | 🙁 @iscode

🥷 Как работает DNS в Linux. Часть 3: разбираемся с resolv.conf, systemd-resolved, NetworkManager и другими Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике. Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS: • почему одинаковые запросы дают разные IP • как реально контролируется разрешение имен: что вызывает кого и зачем • как проводить диагностику: strace, resolvectl, tcpdump 🖥 Утилиты и их пути к DNS В Linux-системах преобразование доменных имён в IP-адреса — фундаментальный процесс, но не все утилиты делают это одинаково. Под капотом скрываются конкурирующие механизмы: классический стек glibc/NSS (с его правилами из /etc/nsswitch.conf, локальным файлом /etc/hosts и кеширующими сервисами, такими как systemd-resolved), прямые DNS-запросы (игнорирующие системные настройки) и альтернативные библиотеки (например, c-ares). Эти различия часто становятся источником неочевидных расхождений в работе инструментов, особенно при диагностике сетевых проблем. ‼️ Типичный пример — разница в выводе getent hosts и dig для одного домена: $ getent hosts google.com 142.250.179.206 google.com $ dig +short google.com 142.250.179.238 Здесь getent опирается на кеш systemd-resolved (через NSS), а dig обходит системные механизмы, запрашивая DNS-сервер напрямую. Практические советы: • Если ping и curl выдают разные IP, причина обычно в кеше NSS или настройках /etc/hosts. При работе с curl/wget учитывайте их зависимость от libc: расхождения могут указывать на проблемы в NSS (например, некорректный nsswitch.conf). • Для проверки системного разрешения (включая /etc/hosts) используйте getent, host или ping. • Для валидации работы DNS-сервера применяйте dig/nslookup — они не смотрят в локальные файлы. Итог: понимание внутренних механизмов разрешения имён критично при отладке сетевых проблем. Всегда сверяйтесь с таблицей выше, чтобы выбрать правильный инструмент: проверка локальных настроек требует NSS-зависимых утилит, а диагностика DNS — "прямых" запросов в обход системы. #DNS #Linux | 🙁 @iscode