Локальные сервисы и офлайн-знания

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

В обычной сетевой среде пользователь даже не задумывается о том, сколько скрытых внешних зависимостей задействует простейшее действие: ввод адреса в браузере инициирует запросы к публичным рекурсивным DNS-резолверам; открытие рабочей документации обращается к облачным хранилищам; поиск технической информации направляется в глобальные поисковые системы; запуск программного кода требует проверки временных меток в сертификатах TLS и связи с серверами точного времени NTP; а координация группы опирается на централизованные мессенджеры. При исчезновении внешнего интернет-канала вся эта многослойная пирамида мгновенно рушится. Браузер выводит ошибку поиска DNS, системные утилиты зависают на десятки секунд в тщетных попытках связаться с недоступными внешними IP-адресами, локальные сессии блокируются из-за расхождения системных часов, а инженеры лишаются доступа к схемам, даташитам и руководствам по ремонту оборудования.

Тема посвящена созданию автономного сервисного узла — «Островка» (англ. Island node), развёрнутого на базе единственной физической машины и способного полностью заменить внешнюю сетевую инфраструктуру в пределах локального сегмента. Рассматривается полный спектр базовых служб: автономное разрешение имён и адресация, организация легковесного совместного доступа к файлам, хранение и мгновенный поиск по терабайтному корпусу офлайн-знаний (энциклопедии Kiwix, инженерная документация, векторные геодезические карты), инструменты децентрализованной координации и версионирования исходного кода (локальный Git, чат IRC), а также независимая синхронизация времени как фундаментальное условие информационной безопасности.

Изложение построено от базовых сетевых служб к прикладным знаниям и координации. Первый раздел формулирует концепцию и компонентный состав сервисного стека «Островок». Второй раздел разбирает работу DNS/DHCP-сервера dnsmasq без апстрима и при его исчезновении, unbound с копией корневой зоны и выбор зоны polygon.internal. Третий раздел анализирует технологии совместного хранения файлов (SMB, NFS, HTTP-каталог) и разграничение доступа. Четвёртый раздел описывает структуру и организацию офлайн-знаний: архивы ZIM, векторные тайлы OpenStreetMap и локальный полнотекстовый поиск. Пятый раздел охватывает средства версионирования (git bundle) и локальные текстовые коммуникации. Шестой раздел детально исследует физику ухода системных часов (RTC drift), последствия рассинхронизации для протоколов безопасности и настройку локального NTP-сервера chrony.

Архитектура автономного сервисного узла («Островок»)

Принципы проектирования изолированного стека

Попытка перенести стандартный корпоративный сервисный стек (тяжеловесные СУБД вроде PostgreSQL или Oracle, платформы совместной работы уровня GitLab, Nextcloud, почтовые серверы Microsoft Exchange или связки Matrix Synapse) на автономную машину в сценарии дефицита энергии не работает. Такие платформы рассчитаны на серверы с гигабайтами оперативной памяти и постоянным питанием: они держат в памяти СУБД и фоновые задачи, постоянно пишут на диск, расходуя ресурс флеш-памяти (TBW по теме 6), и не дают процессору уходить в простой ². Точные цифры зависят от версии и нагрузки и здесь не приводятся; для своего узла их измеряют так же, как в ЛР 8.

Автономный узел «Островок» проектируется по принципиально иным критериям:

1. Минимализм и низкое потребление ресурсов. Суммарный объем оперативной памяти, занимаемый всем комплексом базовых служб в состоянии покоя, должен измеряться десятками, а не сотнями мегабайт, а процессор в простое должен действительно простаивать — это требование проверяется измерением в ЛР 8 и позволяет платформе находиться в энергосберегающих состояниях C-states (тема 3) и сохранять ватт-часы аккумулятора.
2. Восстановление и запуск одной командой. Сервисы не должны требовать ручного ввода паролей или сложных многостадийных процедур запуска. Конфигурации полностью версионируются в локальном репозитории (инфраструктура как код), а запуск осуществляется супервизором systemd по единой цели polygon.target.
3. Отсутствие скрытых сетевых связей. Каждый сервис настраивается с жестким запретом на обращение к внешним сетевым интерфейсам, если они не объявлены явно. Попытка запросить внешний хост должна немедленно пресекаться локальным отказом без ожидания сетевого тайм-аута.
4. Хранение в виде статических неизменяемых файлов. Вся база знаний, документация, карты и дистрибутивы хранятся в виде архивов только для чтения (ZIM, MBTiles, SquashFS), что исключает их логическое повреждение при внезапном обесточивании узла.

Компонентный состав и бюджет ресурсов

Стек «Островок» собран из небольших программ, каждая из которых делает одно дело и настраивается одним текстовым файлом ³⁴. Таблица перечисляет их роли и причины выбора; потребление памяти не переписывается из чужих обзоров, а измеряется в ЛР 8 (./island.sh status читает VmRSS из /proc/<pid>/status).

В опыте автора (ЛР 8, dnsmasq 2.90 в пространстве имён, Ubuntu 22.04) резидентная память dnsmasq с кэшем на 1000 записей составила 4608 КиБ (C-08-12: 4,5 МБ). Этого числа достаточно для главного вывода: службы имён, времени и файлов вместе занимают десятки мегабайт, и ограничение по памяти для узла из темы 6 создают не они, а kiwix-serve с большими архивами, поиск и графическая оболочка, если она есть. Полный бюджет своего узла записывается в журнал ЛР 8 по результатам ./island.sh status, а не по этой таблице.

Имена и адресация без внешнего апстрима

Локальный DNS: специфика работы без корневых серверов

В обычном режиме рекурсивный резолвер при получении запроса обращается к корневым серверам (тринадцать имён от a.root-servers.net до m.root-servers.net), затем к серверам зоны верхнего уровня и, наконец, к авторитетным серверам домена; устройство глобального DNS — курс «Компьютерные сети», тема 14 ⁵.

В автономном узле корневые серверы недоступны. Если клиент настроен на резолвер, который пытается до них достучаться, то каждый запрос к имени, которого нет в кэше, ждёт тайм-аута: пакет уходит в никуда или отвергается с ICMP Network Unreachable, резолвер повторяет его к следующему серверу. Клиентская программа (curl, браузер, ssh) при этом блокируется на время, которое складывается из тайм-аутов резолвера и библиотеки клиента (options timeout и attempts в /etc/resolv.conf, по умолчанию 5 с и 2 попытки, см. resolv.conf(5)). Для пользователя это выглядит как «сеть тормозит», хотя локальные сервисы исправны.

Поэтому на узле работает dnsmasq — компактный DNS-сервер с кэшем и DHCP-сервер ³⁵, настроенный так, чтобы ни один запрос не уходил наружу. Фрагмент conf/dnsmasq.conf из ЛР 8:

# Не читать /etc/resolv.conf и не пересылать запросы наружу
no-resolv
no-poll
# Имена без точки и обратные запросы для частных сетей наружу не уходят
domain-needed
bogus-priv
# Локальная зона: неизвестное имя в ней — сразу NXDOMAIN
local=/polygon.internal/
domain=polygon.internal
no-hosts
addn-hosts=/etc/polygon/hosts.internal
listen-address=10.88.0.1,127.0.0.1
bind-interfaces
cache-size=1000

Поведение такого сервера проверено опытом в ЛР 8 (dnsmasq 2.90) и выглядит так (C-08-03: REFUSED, код 5):

dig @10.88.0.1 wiki.polygon.internal     → status: NOERROR, wiki.polygon.internal. A 10.88.0.1
dig @10.88.0.1 nosuch.polygon.internal   → status: NXDOMAIN
dig @10.88.0.1 example.org               → status: REFUSED

Имя из файла зоны получает ответ сразу. Неизвестное имя внутри polygon.internal получает NXDOMAIN — это и делает директива local=: зона объявлена своей, и dnsmasq не ищет её нигде больше. Внешнее имя при отсутствии апстрима получает не NXDOMAIN, а REFUSED: dnsmasq не утверждает, что имени нет, а сообщает, что спросить ему некого. Разница важна для диагностики: NXDOMAIN на внешнее имя означал бы, что кто-то выше по цепочке ответил, а REFUSED — что цепочка обрывается на узле. Клиент получает ответ сразу и не ждёт тайм-аута, что и требовалось.

Исчезновение апстрима и копия корневой зоны

В сценарии А связь есть, и узел пересылает внешние запросы провайдеру (строка server= вместо no-resolv). Что происходит, когда связь пропадает? Опыт ЛР 8 даёт два разных ответа. Имя, которое уже спрашивали, dnsmasq продолжает отдавать из кэша, пока не истёк срок жизни записи (TTL), — в опыте это 300 с, заданные «провайдером». Новое внешнее имя не получает никакого ответа: dnsmasq переслал запрос и ждёт, клиент получает тайм-аут. Это тот самый режим «сеть тормозит», от которого защищает конфигурация без апстрима, поэтому при переходе от сценария А к Б или В апстрим из конфигурации убирают явно, а не ждут, пока его отсутствие заметят пользователи.

Для узла, которому нужен настоящий рекурсивный резолвер (например, чтобы при восстановлении связи сразу работать без ручного переключения), используется unbound. Он умеет держать локальные зоны (local-zone: "polygon.internal." static) и хранить полную копию корневой зоны по RFC 8806 (auth-zone с name: ".") ¹³. Копия корня избавляет резолвер от обращений к корневым серверам: имена верхнего уровня (.org, .ru) он разрешает сам, а дальше всё равно нужен интернет. В автономии от этого две пользы: резолвер без задержек отвечает NXDOMAIN на несуществующие зоны верхнего уровня, а при появлении связи начинает работать без смены конфигурации. Файл root.zone скачивается заранее и устаревает: подписи DNSSEC в нём имеют срок действия порядка недель, и у устаревшей копии проверка подписей отказывает — это одна из причин, по которой точное время важно не только для Kerberos (раздел о времени).

Отдельный приём — split-horizon: одно и то же имя получает разные ответы в зависимости от того, откуда спросили. На узле с двумя сегментами (служебный и гостевой) files.polygon.internal для служебного сегмента указывает на файловый сервер, а для гостевого — на страницу с правилами; в unbound это делают access-control-view и view:, в dnsmasq — localise-queries для адресов, привязанных к интерфейсам.

Выбор локальной зоны: .internal, .home.arpa, .local

Выбор суффикса для локальных имён регламентирован ⁶⁷:

1. .local (RFC 6762, Multicast DNS). Зона зарезервирована для mDNS (Avahi, Bonjour). Системные резолверы Linux (через nss-mdns) и Apple отправляют запрос host.local групповой рассылкой на 224.0.0.251, порт 5353, минуя одноадресный DNS-сервер. Использовать .local в dnsmasq нельзя: часть клиентов его просто не спросит. По той же причине в ЛР 8 dnsmasq не ставят на порт 5353 — его занимает Avahi.
2. .home.arpa (RFC 8375). Зона для домашних сетей; не делегируется в глобальном DNS.
3. .internal. В 2024 году ICANN зарезервировала зону верхнего уровня .internal для частного использования: она никогда не будет делегирована в корне, и её можно использовать в любой изолированной сети ¹⁴. Курс использует одну зону для всего Полигона — polygon.internal (wiki.polygon.internal, files.polygon.internal, time.polygon.internal).
4. Произвольные суффиксы (.lan, .island, .corp) — плохой выбор: любой из них может быть делегирован в будущем, и тогда локальные имена начнут конфликтовать с глобальными.

Сетевая адресация: статика против DHCP

На автономном узле используется смешанная схема.

• Сам узел и инфраструктура получают адреса статически (в ЛР 8 — 10.88.0.1/24). Сервер не должен зависеть от собственного DHCP: если интерфейс узла ждёт адреса, а DHCP-сервер стартует только после поднятия интерфейса, загрузка зацикливается.
• Клиенты получают адрес, шлюз, DNS и сервер времени по DHCP от того же dnsmasq (рисунок):

dhcp-range=10.88.0.100,10.88.0.150,255.255.255.0,1h
dhcp-option=option:router,10.88.0.1
dhcp-option=option:dns-server,10.88.0.1
dhcp-option=option:ntp-server,10.88.0.1
dhcp-authoritative

Конфликт адресов возникает, когда кто-то назначил себе статический адрес из пула DHCP. dnsmasq перед предложением адреса проверяет, не занят ли он: отправляет ICMP-эхо (ping) и, если ответ пришёл, помечает адрес как занятый и предлагает следующий (dnsmasq(8), опция --no-ping, которая эту проверку отключает). Цена проверки видна в ЛР 8: клиент получил адрес через 3,2 с после первого запроса (C-08-11: 3,2 с), почти всё это время — ожидание ответа на ping. Со стороны клиента защита дублируется: современные клиенты DHCP перед использованием адреса делают ARP-проверку (RFC 5227) и при конфликте отказываются от адреса сообщением DHCPDECLINE. Диагностика конфликта на узле — ip neigh (два MAC-адреса для одного IP в разное время) и журнал dnsmasq (log-dhcp).

Хранилища файлов и совместный доступ

Сравнение файловых протоколов в изоляции

Для организации обмена схемами, архивами пакетов, технической литературой и резервными копиями внутри замкнутого узла применяются три основных протокола файлового доступа ⁸:

Простой HTTP-каталог: файлы без настроек

Наиболее устойчивым к сбоям форматом раздачи файлов в условиях автономии является статический HTTP-каталог с включённым автоиндексированием (англ. directory listing). Преимущество решения — абсолютная всеядность: файлы читаются любым встроенным веб-браузером, консольной утилитой curl или wget, не требуя установки специализированных сетевых клиентов.

Конфигурация виртуального хоста в nginx (/etc/nginx/sites-available/files.polygon.internal):

server {
    listen 80;
    server_name files.polygon.internal;
    root /srv/storage/public;

    # Включение красивого листинга каталогов
    autoindex on;
    autoindex_exact_size off;
    autoindex_localtime on;

    # Оптимизация отдачи больших статических файлов
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    # Ограничение скорости для предотвращения утилизации канала
    limit_rate_after 10m;
    limit_rate 2m;
}

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

Разграничение прав и защита от исчерпания диска

В изолированной среде критически важно не допустить переполнения корневого раздела файлами пользователей. Если гостевой пользователь загрузит терабайтный архив на системный раздел, операционная система заблокируется из-за невозможности создать временные файлы /tmp и дескрипторы сокетов в /run.

Для нейтрализации риска применяются два архитектурных правила:

1. Физическая или логическая изоляция хранилища. Каталог общего доступа /srv/storage монтируется на отдельный раздел или отдельный субтом Btrfs.
2. Дисковые квоты. На уровне файловой системы включаются жесткие лимиты на пользователя или группу (btrfs qgroup или edquota).
3. Разграничение прав POSIX. Доступ к модификации системных каталогов ограничен правами суперпользователя; общедоступная папка настраивается со специальным битом закрепления (англ. sticky bit), аналогично каталогу /tmp:

   chmod 1777 /srv/storage/shared
   

   Флаг 1 (sticky bit) гарантирует, что удалить или переименовать файл может только его непосредственный создатель, даже если права записи открыты для всех участников группы.

Корзина, версии файлов и квоты

Пользователь в изоляции удаляет файл так же легко, как и в офисе, а восстановить его из облака нельзя. Поэтому общий каталог узла настраивается с защитой от ошибки человека в два слоя. Первый — корзина на сервере: в Samba модуль vfs_recycle переносит удалённые файлы в скрытый каталог .recycle вместо удаления; для HTTP-каталога то же даёт правило «загрузка в incoming/, перенос в основной каталог — только оператором». Второй — версии: снимки Btrfs по таймеру (тема 7) или ежечасная копия rsync --link-dest, где неизменённые файлы — жёсткие ссылки и места почти не занимают. Корзина и версии не заменяют резервную копию на другом носителе (тема 9): они защищают от ошибки, но не от отказа диска.

Квоты ограничивают, сколько места займёт один пользователь или каталог: btrfs qgroup limit 20G /srv/storage/shared для подтома Btrfs или setquota на ext4 с включённой опцией usrquota. Проверка квоты — часть ЛР 8 только в ветке ВМ: на файловых образах без root квоты не включаются.

Корпус офлайн-знаний и локальные справочники

Архивы ZIM и платформа Kiwix

Главная ценность автономного узла на уровне деградации 1 (тема 1) — доступ к справочным знаниям. Стандартный формат для сжатого хранения веб-контента — ZIM, развиваемый проектом openZIM и читаемый программами Kiwix ⁹:

• статьи, стили, шрифты и изображения упакованы в один файл; содержимое сжато кластерами (zstd в современных архивах, LZMA2 в старых), и для чтения одной статьи распаковывается только её кластер;
• внутри архива хранится полнотекстовый индекс Xapian, поэтому поиск работает без отдельной индексации;
• архив только читается, и порча при внезапном отключении питания ему не грозит.

kiwix-serve раздаёт архивы по HTTP; запросы он обрабатывает пулом потоков (--threads), так что «однопоточным» его считать неверно:

kiwix-serve --address 10.88.0.1 --port 8080 --threads 4 \
  /srv/zim/wikipedia_ru_all_nopic.zim /srv/zim/wikimed_ru.zim

В ЛР 8 используется маленький архив zim/polygon_memo.zim (60 КиБ, три страницы памятки узла, исходники в zim/src/), собранный утилитой openZIM; на нём проверяется, что kiwix-serve запускается и отдаёт страницы и поиск, если пакет kiwix-tools установлен.

Размеры реальных архивов меняются с каждым выпуском, поэтому в тексте не приводятся: актуальный размер берётся из каталога https://download.kiwix.org/zim/ в день подготовки профиля (тема 2) и записывается в паспорт узла. Сам расчёт состава библиотеки под носитель варианта делается так. Пусть носитель имеет ёмкость C, под систему, конфигурации и резерв отводится доля r (в курсе 20 %), а архивы упорядочены по важности: 1 — медицина и безопасность, 2 — техника и ремонт, 3 — общая энциклопедия. Архивы добавляются по порядку, пока сумма их размеров S не превысит доступный объём:

S = \sum_{i=1}^{n} V_i \le C\,(1 - r)

На карту microSD 64 ГБ (59,6 ГиБ после разметки) при r = 0,2 помещается 59,6 · 0,8 = 47,7 ГиБ архивов. Если энциклопедия без иллюстраций не помещается вместе с остальным, правильное решение — взять её сокращённый вариант (_mini, _nopic), а не вычеркнуть медицину. Это правило «самое нужное — всегда, остальное — по требованию» из PLAN курса в виде арифметики; в ЛР 8 расчёт выполняется для носителя своего варианта по размерам из каталога.

Internet-in-a-Box — готовая сборка поверх Debian или Raspberry Pi OS, которая устанавливает Kiwix, офлайн-карты, Moodle, медиатеку и точку доступа Wi-Fi с одним веб-интерфейсом. Для учебного узла её полезно знать как образец состава, но собирать стек вручную по этой теме полезнее: готовая сборка скрывает именно те механизмы (DNS без апстрима, время, восстановление), ради которых тема написана, и обновляется по своему циклу.

Инженерная документация, man и DevDocs

Помимо общей энциклопедии, автономный узел должен содержать точную инженерную документацию по программным языкам и интерфейсам API ⁴⁹:

1. Системные руководства man и tldr. В обычных дистрибутивах при минимизации пакетов документация часто вырезается. На автономном узле устанавливаются полные пакеты руководств: manpages, manpages-dev, manpages-posix-dev. Дополнительно развёртывается база tldr — компактные примеры практических команд Linux с поиском по локальному кэшу.
2. Офлайн-каталог DevDocs. Платформа DevDocs объединяет документацию по десяткам языков и библиотек (Python, C/C++, Rust, Go, Bash, Linux Kernel, HTML/CSS). Локальный срез разворачивается в виде статического веб-приложения.

Офлайн-карты и векторные геоданные (OpenStreetMap)

В сценариях изоляции критически важна локальная навигация: топографическая обстановка, дороги, источники воды, высоты рельефа, линии электропередач.

Использование растровых скриншотов карт неэффективно: они занимают сотни гигабайт и теряют детализацию при масштабировании. Стандартом для автономных систем является хранение векторных тайлов OpenStreetMap в контейнерах формата MBTiles (база данных SQLite, содержащая векторные тайлы в формате Protocol Buffers) или PMTiles (однофайловый архив с возможностью считывания произвольных диапазонов байт) ¹⁰:

• Размер векторного архива области зависит от её площади и плотности застройки; его берут из каталога источника в день подготовки профиля и записывают в паспорт узла.
• Векторные тайлы содержат точные математические координаты всех объектов (дороги, дома, изолинии высот SRTM).
• Локальный тайловый сервер (например, компактный бинарник mbtileserver на Go) раздаёт тайлы во встроенный веб-интерфейс на базе библиотеки Leaflet или OpenLayers.
• Офлайн-маршрутизация выполняется встроенными движками (Valhalla или OSRM в режиме предварительно скомпилированного графа), позволяя строить оптимальные автомобильные и пешеходные маршруты полностью без интернета.

Для мобильных устройств группы удобнее не тайловый сервер, а готовые офлайн-приложения: OsmAnd и Organic Maps (Android, iOS) хранят векторные карты регионов OpenStreetMap и строят маршруты без сети. Файлы карт скачиваются заранее на машине с сетью и переносятся на устройства через файловый каталог узла; так телефон остаётся полезным навигатором даже без связи с узлом. Версии карт фиксируются в паспорте узла вместе с датой, потому что дорожная сеть меняется.

Полнотекстовый поиск: Recoll и Ripgrep

Для мгновенного поиска по сотням гигабайт накопленных PDF-книг, схем в формате DjVu, даташитов и исходных кодов используются два инструмента:

1. ripgrep (rg). Сверхбыстрый консольный инструмент построчного поиска, написанный на Rust. Оптимизирован под многопоточное сканирование директорий с аппаратным ускорением SIMD. Поиск по каталогу исходников или документации занимает доли секунды при данных в кэше страниц.
2. recoll (Recoll Search Engine). Демон индексирования документов на базе движка Xapian. В фоновом режиме извлекает текстовые слои из файлов PDF, DOCX, ODT, HTML, ePub, DjVu и почтовых архивов mbox. При поиске ключевой фразы (например, «расчёт сечения провода DC-DC») recoll выдаёт точные ссылки на страницы PDF-документов за доли секунды, избавляя инженера от необходимости вручную перебирать папки архива.

Координация, версионирование и локальная связь

Локальный Git и перенос через git bundle

В автономном узле распределённая система управления версиями Git служит не только для разработки программ, но и как центральный механизм управления инфраструктурой (конфигурации /etc/, сценарии восстановления, эксплуатационные журналы узла по теме 13) ⁴¹¹.

Для совместной работы нескольких специалистов внутри сегмента развёртывается локальный репозиторий Git. Для этого не требуются громоздкие веб-платформы: достаточно стандартного протокола SSH или легковесного демона git-daemon:

# Создание чистого общего репозитория на сервере
mkdir -p /srv/git/infrastructure.git
cd /srv/git/infrastructure.git
git init --bare --shared

# Разрешение анонимного чтения/клонирования через git-daemon (порт 9418)
touch git-daemon-export-ok
git daemon --reuseaddr --base-path=/srv/git --export-all --verbose &

Клиентские станции подключаются по локальному адресу:

git clone git://git.polygon.internal/infrastructure.git

Механизм git bundle для изолированного переноса коммитов

Когда узел находится в полной физической изоляции (Air-Gap) и прямого сетевого линка со внешней сборочной машиной нет, перенос изменений выполняется с помощью команды git bundle ¹¹:

1. На внешней машине, где были внесены изменения, создаётся монолитный бинарный контейнер («бандл»), содержащий всю цепочку коммитов, веток и тегов:

   # Упаковка ветки main в единый переносимый файл
   git bundle create /media/usb/updates.bundle main
   

2. Бандл верифицируется утилитой git bundle verify: контейнер включает в себя криптографические контрольные суммы объектов SHA-1/SHA-256.
3. На изолированном автономном узле бандл монтируется в карантинном режиме и импортируется напрямую в рабочий репозиторий:

   # Извлечение коммитов из файла на сменном носителе
   git fetch /media/quarantine/updates.bundle main:incoming-updates
   # Слияние изменений
   git merge incoming-updates
   

Технология git bundle исключает передачу разрозненных diff-патчей, гарантируя целостность графа истории коммитов.

Локальные текстовые коммуникации: IRC против XMPP

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

1. IRC (демон ngircd). Простой выбор для минимального узла: ngircd написан на C, настраивается одним файлом и почти не требует ресурсов. Поддерживает разделение на каналы (#operations, #hardware, #alerts), сохранение истории и защиту каналов паролями. Клиенты для IRC существуют под любые операционные системы (от консольного irssi до графических HexChat и мобильных приложений).
2. XMPP (демон prosody). Выбирается, если требуется передача графических изображений, файлов и поддержка сквозного шифрования OMEMO между мобильными клиентами (Conversations на Android). Prosody написан на Lua и настраивается на работу с внутренней доменной зоной chat.polygon.internal.
3. Голос: Mumble. Сервер mumble-server (Murmur) даёт голосовую связь с низкой задержкой в локальной сети, клиенты есть для Linux, Windows и Android. Голос в изоляции нужен там, где текст медленен: координация работ в разных помещениях. Нагрузка на канал определяется кодеком Opus и задаётся в настройках сервера; для Wi-Fi одного сегмента она несущественна, для радиоканала темы 10 — запретительна.

Синхронизация времени и аппаратные часы

Физика ухода часов

Часы реального времени (англ. Real-Time Clock, RTC) материнской платы тактируются камертонным кварцевым резонатором на 32 768 Гц (2¹⁵ колебаний в секунду) и идут, пока узел выключен. Пока узел работает, время ведёт ядро по другому генератору, но и тот кварцевый, и рассуждение для него то же. Ошибку частоты принято выражать в миллионных долях (англ. parts per million, ppm): 1 ppm означает уход на 86 400 · 10⁻⁶ = 0,0864 с за сутки.

Паспортная начальная ошибка такого кварца при 25 °C — ±20 ppm. Это даёт уход 1,728 с за сутки (C-08-01: 1,728 с/сут; расчёт rtc.py), а в одиночку часы с такой ошибкой отойдут от истинного времени на 300 с за 173,6 суток. Важнее начальной ошибки температура. Частота камертонного кварца зависит от температуры по параболе с вершиной около 25 °C:

\frac{\Delta f}{f} = -k\,(T - T_0)^2,\qquad k = 0{,}034\ \text{ppm/°C}^2,\quad T_0 = 25\ ^\circ\text{C}

(C-08-08: 0,034 ppm/°C², даташит Abracon ABS07). Знак минус означает, что вдали от 25 °C кварц всегда отстаёт — и при холоде, и при жаре. Для сценария В (+5 °C в помещении без отопления, teacher/polygon.json) температурная добавка равна −0,034 · 20² = −13,6 ppm (C-08-04: −13,6 ppm), для сценария Б (−20 °C) — уже −68,9 ppm, втрое больше паспортной начальной ошибки.

Коррекция по driftfile

Демон chrony, пока у узла есть источник времени (сценарий А), измеряет ошибку частоты своих часов и записывает её в файл driftfile. После потери источника он продолжает вводить эту поправку. Начальная ошибка экземпляра (те самые ±20 ppm) и температура в момент калибровки при этом вычитаются; остаётся только изменение частоты после калибровки — в основном температурное. Расчёт rtc.py для сценария В при калибровке в тёплом помещении (+22 °C) и работе при +5 °C:

(C-08-05: 16,2 с; C-08-06: 40,6 с). Коррекция убирает начальную ошибку, но не температуру. Отсюда практическое правило: калибровать часы (держать узел на связи с источником времени несколько часов) нужно в тех же условиях, в которых узел будет работать, а не на тёплом столе перед выездом. Для сценария Б разница ещё заметнее: при калибровке в +22 °C и работе в −20 °C остаточная ошибка 68,6 ppm, то есть 5,9 с за сутки.

Что на самом деле ломается от ухода часов

Распространённое утверждение «через полгода автономии Kerberos откажет» верно только для узлов, у которых нет общего источника времени. Протоколы делятся на две группы, и смешивать их нельзя ²¹².

Сравнивают часы двух сторон. Kerberos отвергает запрос, если часы клиента и KDC расходятся больше чем на clockskew — по умолчанию 300 с (C-08-09: 300 с; MIT Kerberos, krb5.conf(5), раздел [libdefaults]). TOTP (RFC 6238) делит время на шаги по 30 с, а проверяющая сторона рекомендованно принимает код соседнего шага (C-08-07: 30 с, ±1 шаг) ¹. Для таких протоколов важно расхождение сторон, а не точность. Если клиенты и сервер берут время с одного локального NTP-сервера, их расхождение определяется сетевой задержкой (доли миллисекунды в одном сегменте) и не растёт, сколько бы ни уходил сам сервер от UTC. Порог становится угрозой для двух узлов без общего источника: при ошибках +20 и −20 ppm они расходятся со скоростью 40 ppm, и TOTP перестаёт гарантированно приниматься через 8,68 суток (C-08-10: 8,68 сут), а Kerberos отказывает через 86,8 суток (C-08-02: 86,8 сут). Отсюда вывод для сценария В: два узла Полигона, которые обмениваются данными (тема 11), должны синхронизироваться друг с другом — один служит сервером времени другому, — а не каждый сам по себе.

Сравнивают часы с абсолютным временем. Сроки сертификатов X.509 (notBefore, notAfter), сроки подписей DNSSEC (RRSIG), поле Valid-Until в файлах Release APT (тема 7), сроки ключей OpenPGP. Здесь общий локальный сервер не помогает: если он сам ушёл на сутки вперёд, все клиенты одинаково посчитают сертификат, истекающий сегодня, уже истёкшим. Порога «300 с» у TLS нет — граница определяется сроком конкретного сертификата, и ошибка становится заметной в момент, когда часы переходят эту дату. Практические следствия: сертификаты локальных сервисов выпускают с запасом по сроку (тема 7, «Локальные сертификаты и время»); резолвер с проверкой DNSSEC на узле с ушедшими часами начинает отвергать все подписанные ответы (поэтому в изоляции DNSSEC-проверку для локальной зоны не включают, а для копии корня — следят за временем); после долгой автономии часы узла сверяют с независимым источником до того, как принимать решения по срокам.

Наконец, журналы. При разборе отказа события с разных машин сопоставляются по меткам времени; если часы двух машин расходятся на минуты, порядок событий в сводном журнале может оказаться обратным действительному.

Автономный сервер времени chrony

Узел раздаёт время сегменту сам. В отсутствие внешних источников chrony по умолчанию считает свои часы несинхронизированными и клиентов не обслуживает; директива local разрешает это ¹². Фрагмент conf/chrony-server.conf из ЛР 8:

local stratum 10           # раздавать своё время, объявив стратум 10
allow 10.88.0.0/24         # клиенты сегмента
driftfile /var/lib/chrony/chrony.drift
rtcsync                    # периодически переносить время ядра в RTC

Стратум 10 выбран намеренно большим: если в сети появится настоящий источник (GNSS-приёмник, связь с интернетом), клиенты предпочтут его. В ЛР 8 клиенты получают адрес сервера времени по DHCP (опция 42, ntp-server), а рассинхронизация проверяется опытом: часы сервера сдвигаются на 600 с (ISLAND_TIME_OFFSET=600, chronyd под libfaketime или запасной сервер offline_time.py), и клиент должен это обнаружить. Без прав root системные часы машины в опыте не меняются — клиент только измеряет смещение (chronyd -Q или offline_time.py query), и это осознанное ограничение опыта.

Аппаратные источники: DS3231 и GNSS

Термокомпенсированный генератор DS3231. Микросхема содержит датчик температуры и подстраивает частоту встроенного кварца; по даташиту (Analog Devices, бывш. Maxim) точность ±2 ppm в диапазоне 0…+40 °C и ±3,5 ppm в диапазоне −40…+85 °C (C-08-13: ±2 ppm). Для узла в неотапливаемом помещении правильная цифра — вторая. Модуль подключается по шине I²C: на одноплатных компьютерах — к выводам GPIO, на ноутбуке или ПК — через USB-адаптер I²C (например, на микросхеме CH341) и драйвер rtc-ds1307, который поддерживает DS3231. Простой USB-UART для этого не годится: у DS3231 нет последовательного порта. Если считать, что весь паспортный допуск ±2 ppm уже включает температуру (rtc.py --ppm 2 --k 0), одиночный узел уходит на 300 с за 1736 суток (C-08-14: 1736 сут); для сценария Б расчёт повторяют с 3,5 ppm.

GNSS-приёмник. Навигационный модуль даёт время по строкам NMEA через последовательный порт и импульс PPS раз в секунду. gpsd читает приёмник и передаёт время в chrony через общую память или сокет (refclock SHM 0 или refclock SOCK /run/chrony.ttyS0.sock, refclock PPS /dev/pps0). При видимости спутников это источник абсолютного времени, и с ним узел может раздавать время клиентам со стратумом 1. В 2026 году нужно учитывать, что сигнал GNSS может быть подавлен или подменён: приёмник без признаков подмены способен уверенно сообщить неверное время. Поэтому chrony настраивают так, чтобы GNSS не мог сдвинуть часы скачком (maxchange, refclock … maxlockage, сравнение с RTC узла), а расхождение больше заданного порога записывается в журнал для оператора, а не принимается молча.

Что эта модель не учитывает

1. Нагрузку многих клиентов. Стек рассчитан на небольшую группу. dnsmasq обслуживает запросы в одном процессе, kiwix-serve — пулом потоков (--threads); при десятках одновременных пользователей узким местом становятся диск с ZIM-архивами и процессор, а не сеть. Предел нагрузки своего узла измеряется, а не берётся из таблицы.
2. Суточные колебания температуры и старение кварца. rtc.py берёт одну постоянную температуру и линейное старение (±3 ppm за первый год по паспорту ABS07). При колебаниях температуры средний уход меньше худшего случая, но не равен нулю.
3. Достоверность GNSS. Модель считает GNSS источником абсолютного времени. При подавлении приёмник молчит (это видно), при подмене — сообщает неверное время (это не видно без сравнения с другим источником).
4. Совместное редактирование в реальном времени. Git и статические ZIM рассчитаны на асинхронную работу; аналога совместного редактора документов в стеке нет.
5. Повреждение баз при отключении питания. Индексы Recoll и базы SQLite при обесточивании во время записи могут потребовать восстановления по теме 9.

Итоги темы

Автономный сервисный узел превращает одну машину в инфраструктурный центр небольшой группы: имена, адреса, файлы, знания, координация и время работают без внешней сети. Принцип отбора сервисов — минимум программ, каждая настраивается одним текстовым файлом и восстанавливается одной командой; потребление ресурсов своего узла измеряется (ЛР 8), а не переписывается из таблиц.

Имена обслуживает dnsmasq в зоне polygon.internal; зона .internal зарезервирована ICANN и не будет делегирована. Без апстрима локальные имена получают ответ сразу, неизвестные имена в зоне — NXDOMAIN, внешние — REFUSED (C-08-03: REFUSED, код 5), и клиент не ждёт тайм-аутов. При пропаже апстрима кэш продолжает отдавать уже известные имена до истечения TTL, а новые внешние запросы зависают, поэтому апстрим из конфигурации убирают явно. unbound с копией корневой зоны и split-horizon — для узлов, где нужен полноценный резолвер. Клиенты получают адрес, DNS и сервер времени по DHCP; конфликт адресов dnsmasq ловит проверкой ping.

Знания хранятся в неизменяемых файлах: ZIM для энциклопедий и справочников, MBTiles и карты OsmAnd или Organic Maps для геоданных, man и tldr для документации; объём библиотеки подбирается под носитель варианта расчётом, а не наугад. Координация — Git с переносом через git bundle, текстовый чат и голос в локальной сети.

Время раздаёт chrony в режиме local stratum 10. Кварц с ошибкой 20 ppm уходит на 1,728 с за сутки (C-08-01: 1,728 с/сут), но главная составляющая ухода в холодном помещении — температура, и коррекция по driftfile её не убирает. Протоколы, сравнивающие часы двух сторон (Kerberos, TOTP), не страдают, пока все берут время с одного сервера; угроза для них — узлы без общего источника. От абсолютного времени зависят сроки сертификатов, подписей DNSSEC и файлов APT, и здесь помогает только независимый источник — DS3231 с известной погрешностью или GNSS, который нельзя принимать на веру.

Литература

1. RFC 6238. TOTP: Time-Based One-Time Password Algorithm. — IETF, 2011. https://www.rfc-editor.org/rfc/rfc6238
2. Anderson R. Security Engineering: A Guide to Building Dependable Distributed Systems. 3rd ed. — Wiley, 2020.
3. Kelley S. dnsmasq: manual page. https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
4. Shotts W. The Linux Command Line: A Complete Introduction. 2nd ed. — No Starch Press, 2019.
5. Albitz P., Liu C. DNS and BIND. 5th ed. — O'Reilly Media, 2006.
6. RFC 6762. Multicast DNS. — IETF, 2013. https://www.rfc-editor.org/rfc/rfc6762
7. RFC 8375. Special-Use Domain 'home.arpa.'. — IETF, 2018. https://www.rfc-editor.org/rfc/rfc8375
8. Ward B. How Linux Works: What Every Superuser Should Know. 3rd ed. — No Starch Press, 2021.
9. openZIM. ZIM file format. https://wiki.openzim.org/wiki/ZIM_file_format
10. MBTiles Specification. https://github.com/mapbox/mbtiles-spec
11. Chacon S., Straub B. Pro Git. 2nd ed. — Apress, 2014. https://git-scm.com/book/en/v2
12. chrony documentation: chrony.conf(5). https://chrony-project.org/doc/4.6/chrony.conf.html
13. RFC 8806. Running a Root Server Local to a Resolver. — IETF, 2020. https://www.rfc-editor.org/rfc/rfc8806
14. ICANN. Approved Board Resolutions, Special Meeting of the ICANN Board, 29 July 2024: Reserving .INTERNAL for Private-Use Applications. https://www.icann.org/

Дополнительные материалы

Вопросы для самопроверки

3. В чём назначение опций no-resolv, local=/polygon.internal/ и bogus-priv в конфигурации dnsmasq? Какой код ответа получит клиент на внешнее имя без апстрима и почему это REFUSED, а не NXDOMAIN?
4. Почему для локальных имён Полигона выбрана зона .internal, а не .local (RFC 6762) и не произвольный суффикс вроде .lan?
5. Какие сетевые тайм-ауты возникают в системных утилитах (curl, apt, ssh), если системный DNS-резолвер настроен на внешние серверы (8.8.8.8), а канал связи отсутствует?
6. В чём состоит назначение опций no-resolv и bogus-priv в конфигурации dnsmasq?
7. Почему стандарт RFC 8375 рекомендует суффикс .home.arpa для замкнутых домашних и полевых сетей и запрещает использование зоны .local для одноадресного DNS?
8. В чём различие между векторными тайлами (MBTiles/PMTiles) и растровыми спутниковыми снимками при подготовке офлайн-карт региона?
9. Как устроен формат ZIM (Zeno Improved Media) и почему библиотека kiwix-serve не требует распаковки архива на диск для поиска статей?
10. Каким образом команда git bundle позволяет передавать полную историю изменений и веток через физический накопитель без прямого сетевого соединения?
11. Почему текстовый протокол IRC (демон ngircd) остаётся актуальным для автономных узлов, превосходя по энергоэффективности современные распределённые мессенджеры?
12. Что такое уход частоты кварцевого резонатора (RTC clock drift) и почему он выражается в миллионных долях (ppm)?
13. Каков суточный уход часов при ошибке частоты 20 ppm и какая составляющая ухода в неотапливаемом помещении больше: начальная ошибка или температурная?
14. Почему Kerberos и TOTP не отказывают у клиентов одного локального NTP-сервера, даже если сервер ушёл от UTC? Что всё-таки зависит от абсолютного времени?
15. Какую функцию выполняет директива local stratum 10 в демоне chrony и почему стандартный демон ntpd без неё отключает синхронизацию клиентов?
16. Чем термокомпенсированный генератор TCXO (чип DS3231) отличается от обычного часового кварца материнской платы?
17. Как приёмник спутниковой навигации GNSS с выходом секундного импульса PPS превращает автономный узел в первичный эталон времени Stratum 1?
18. Какие меры на уровне файловой системы предотвращают блокировку операционной системы при исчерпании свободного места пользователями в сетевом хранилище?

Глоссарий темы

Шпаргалка по конфигурациям и инструментам

Минимальный /etc/dnsmasq.conf для изолированного узла

# Полный запрет внешних опросов
no-resolv
no-poll
domain-needed
bogus-priv

# Локальная доменная зона
domain=polygon.internal
local=/polygon.internal/
listen-address=127.0.0.1,192.168.88.1

# Статические записи хостов
addn-hosts=/etc/polygon/hosts.internal

# Настройка DHCP для клиентов
dhcp-range=192.168.88.100,192.168.88.200,255.255.255.0,12h
dhcp-option=option:router,192.168.88.1
dhcp-option=option:dns-server,192.168.88.1
dhcp-option=option:ntp-server,192.168.88.1

Минимальный /etc/chrony/chrony.conf (Автономный Stratum 10)

# Режим локального эталона времени при отсутствии интернета
local stratum 10

# Разрешённые клиентские сети
allow 192.168.88.0/24
allow 127.0.0.1

# Запись коэффициента дрейфа кварца
driftfile /var/lib/chrony/chrony.drift

# Обновление аппаратных часов RTC каждые 11 минут
rtcsync

# Разрешение ручной установки через chronyc
manual

Системный юнит systemd для Kiwix-сервера (/etc/systemd/system/kiwix.service)

[Unit]
Description=Kiwix Offline ZIM Knowledge Server
After=network.target

[Service]
Type=simple
User=www-data
# systemd не раскрывает шаблоны *.zim: архивы перечисляют в библиотеке
# (kiwix-manage /srv/zim/library.xml add /srv/zim/<архив>.zim)
ExecStart=/usr/bin/kiwix-serve --address 10.88.0.1 --port 8080 --threads 4 --library /srv/zim/library.xml
Restart=on-failure
RestartSec=5s
MemoryMax=150M

[Install]
WantedBy=multi-user.target

Работа с Git Bundle (перенос через флеш-накопитель)

# На внешней машине: создание бандла ветки main
git bundle create /media/usb/repo-update.bundle main

# Проверка целостности бандла
git bundle verify /media/usb/repo-update.bundle

# На изолированном узле: импорт изменений из файла
git fetch /media/usb/repo-update.bundle main:incoming
git merge incoming

Что читать и изучать дальше

1. RFC 5905. Network Time Protocol Version 4 Specification (2010). Официальный стандарт протокола NTPv4. Главы 3–5 содержат математическое описание фильтрации смещения часов, алгоритм пересечения интервалов Марзулло и правила стратификации серверов времени.
2. Kelley S. dnsmasq Manual and Configuration Reference (2023). Техническое руководство автора утилиты dnsmasq. Подробно рассмотрены тонкости взаимодействия локального кэша с файлами hosts и поведение при отсутствии апстримов.
3. RFC 8375. Special-Use Domain 'home.arpa.' (2018). Стандарт IETF, регламентирующий правила именования узлов в автономных и домашних локальных сетях без риска коллизий с глобальным корнем.
4. Chacon S., Straub B. Pro Git. 2nd ed. — Apress, 2014. Глава 7.4 полностью посвящена практическому использованию утилиты git bundle для изолированных сред без сетевого взаимодействия.
5. openZIM Technical Specification. — Wikimedia & openZIM Foundation. Официальное описание архитектуры формата ZIM, структур сжатия LZMA2/Zstd и организации инвертированных индексов поиска Xapian.
6. Mills D. L. Computer Network Time Synchronization: The Network Time Protocol on Earth and in Space. 2nd ed. — CRC Press, 2011. Фундаментальная монография создателя протокола NTP Дэвида Миллса. Детально исследована физика кварцевых генераторов, температурные эффекты и математические модели компенсации ухода часов.

Углубление

Формат PMTiles и бессерверная раздача геоданных OpenStreetMap

Традиционные тайловые серверы геоданных (TileServer GL, GeoServer) требуют запущенного фонового процесса, базы данных и интерпретатора Node.js или Java, потребляя сотни мегабайт ОЗУ.

Современной альтернативой для автономных узлов является формат PMTiles (ProtoMaps Tiles):

• Весь набор векторных тайлов планеты, страны или отдельного региона упаковывается в один монолитный файл.
• В заголовке файла находится многоуровневый компактный индекс диапазонов байт.
• Веб-браузер клиента (библиотека MapLibre GL) запрашивает фрагменты карты напрямую у стандартного легковесного HTTP-сервера (Nginx или встроенный Python-сервер) с помощью стандартных HTTP-запросов с заголовком диапазона байт:

  GET /maps/region.pmtiles HTTP/1.1
  Range: bytes=1048576-1052672
  

• Сервер не выполняет никаких вычислений: он просто отдаёт запрошенный кусок файла с диска методом sendfile. В результате потребление процессора сервером равно нулю, а скорость рендеринга векторной карты на клиенте достигает 60 кадров в секунду.

Алгоритм Марзулло и отбраковка источников ложного времени (Falsetickers)

При наличии нескольких автономных источников времени (например, локальный кварц, GNSS-приёмник и соседний узел по радиоканалу) сервер Chrony использует модифицированный алгоритм пересечения интервалов Марзулло (англ. Marzullo's algorithm).

Каждый источник времени i предоставляет не одну временную метку, а интервал неопределённости [Tᵢ − Eᵢ, Tᵢ + Eᵢ], где Eᵢ — суммарная погрешность, включающая сетевую задержку и дрейф генератора. Алгоритм находит наибольшее пересечение интервалов (когорту согласующихся источников):

• Источники, чей интервал не пересекается с большинством, объявляются источниками ложного времени (англ. falsetickers) и принудительно исключаются из расчёта;
• Оставшиеся источники (англ. truechimers) усредняются с весовыми коэффициентами, пропорциональными их дисперсии. Алгоритм отбраковывает источник, который расходится с большинством; если же источников два или подменены сразу несколько, большинства нет, и отбраковка не гарантирована. Поэтому для защиты от подмены GNSS нужен хотя бы третий, независимый источник (соседний узел, RTC с известной погрешностью).

Лабораторная работа 8. Автономный сервисный узел «Островок»

• Раздел курса: тема 8 «Локальные сервисы и офлайн-знания»

Введение

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

Все опыты идут на настоящих программах — dnsmasq, chrony, kiwix-serve, клиенте DHCP udhcpc — в сетевых пространствах имён Linux без прав root (unshare -rnm). Скрипт island.sh создаёт три пространства: узел (10.88.0.1), клиент (сегмент 10.88.0.0/24) и «провайдера» (198.51.100.2), которого можно отключить. Ни один пакет не уходит в настоящую сеть, системные часы машины не меняются.

Если какой-то программы нет, работа не останавливается. Для DNS и времени есть запасные серверы на Python (offline_dns.py, offline_time.py); они воспроизводят коды ответа, полученные на dnsmasq, но не заменяют его, и результат запасной ветки помечается в журнале. Для kiwix-serve и chrony запасной ветки нет: соответствующие опыты выполняются в ВМ из ЛР 7 или пропускаются с отметкой SKIP.

Цель работы

Поднять и проверить автономный узел с DNS, DHCP, временем, файлами и знаниями в изолированной сети и получить на опыте его поведение при исчезновении апстрима и уходе часов.

После выполнения работы можно будет:

• настроить dnsmasq для зоны polygon.internal без апстрима и объяснить коды ответа NOERROR, NXDOMAIN, REFUSED;
• выдать клиенту адрес, DNS и сервер времени по DHCP и измерить время выдачи;
• показать, что происходит с уже известными и новыми внешними именами при исчезновении апстрима;
• измерить смещение часов клиента относительно сервера узла и обнаружить ушедшие часы сервера;
• рассчитать уход часов для своего сценария (rtc.py) и объяснить, какие протоколы он затрагивает;
• измерить память и диск, занимаемые сервисами узла;
• рассчитать состав библиотеки ZIM под носитель своего варианта.

Теоретический минимум

• Тема 8, «Локальный DNS: специфика работы без корневых серверов» и «Исчезновение апстрима»: C-08-03 (REFUSED, rcode 5).
• Тема 8, «Сетевая адресация»: DHCP-опции 3, 6, 42; проверка адреса ping-запросом; C-08-11 (3,2 с).
• Тема 8, «Синхронизация времени»: C-08-01 (1,728 с/сут), C-08-04…06, C-08-02 (86,8 сут), C-08-10 (8,68 сут).
• Расчёт ухода часов: python3 teacher/sim/rtc.py --scenario <буква> (архив учителя) или формулы темы 8.

Коды выхода вспомогательных программ:

Перечень оснащения

• Ноутбук с Linux: Debian 13, Ubuntu 24.04 или 26.04; должны быть разрешены пространства имён пользователя (unshare -rn true завершается без ошибки).
• Обязательно: python3, iproute2, util-linux (unshare).
• Желательно: dnsmasq, busybox (клиент udhcpc), dnsutils (dig), chrony, faketime, kiwix-tools, git, curl. Установка: sudo apt install dnsmasq-base busybox dnsutils chrony faketime kiwix-tools git curl. Пакет dnsmasq-base ставит программу без системной службы, которая заняла бы порт 53 основной машины.
• Архив окружения: lr-env.zip.

Порядок выполнения работы

mkdir -p ~/polygon/lr08 && cd ~/polygon/lr08
unzip ~/Загрузки/lr-env.zip && cd lr-env
./selftest.sh                       # «selftest ЛР 8: OK»; строки SKIP показывают, чего нет

Все части выполняются внутри «острова». Команда ./island.sh up открывает оболочку в пространстве имён узла; выход из неё (exit) останавливает все службы. Команды для клиента выполняются через ./island.sh client <команда>. Если dig нет, вместо dig @10.88.0.1 <имя> используется python3 dnsq.py 10.88.0.1 <имя>.

Часть 1. Имена и адреса без апстрима

Задание

Поднять узел без апстрима, проверить ответы на локальные, неизвестные локальные и внешние имена, выдать клиенту адрес по DHCP. Затем поднять узел с апстримом и отключить апстрим.

Предсказание

1. Какой код ответа получит клиент на example.org, если у dnsmasq нет ни одного сервера пересылки: NXDOMAIN, SERVFAIL, REFUSED или тайм-аут?
2. Сколько времени займёт получение адреса по DHCP: доли секунды или секунды? Почему?
3. Апстрим работал, клиент спросил example.org, затем апстрим пропал. Что клиент получит на повторный запрос example.org и на запрос нового имени example.net?

Порядок выполнения

./island.sh up
cat run/dnsmasq.conf | grep -v '^#' | grep .        # фактическая конфигурация
./island.sh client dig @10.88.0.1 wiki.polygon.internal
./island.sh client dig @10.88.0.1 nosuch.polygon.internal | grep status
./island.sh client dig @10.88.0.1 example.org | grep status
time ./island.sh dhcp                                # адрес, DNS, NTP от узла
exit

С апстримом («провайдер» отвечает на example.org с TTL 300 с):

ISLAND_UPSTREAM=1 ./island.sh up
./island.sh client dig @10.88.0.1 example.org        # ответ через провайдера
./island.sh upstream-down
./island.sh client dig +time=3 +tries=1 @10.88.0.1 example.org
./island.sh client dig +time=3 +tries=1 @10.88.0.1 example.net
tail -n 5 run/dnsmasq.log
exit

Опыт «конфликт адресов»: в новой сессии острова занять на клиенте статически почти весь пул, оставив свободным один адрес, и запросить адрес по DHCP. Предсказать заранее, какой адрес будет предложен и сколько времени займёт выдача.

ISLAND_UPSTREAM=0 ./island.sh up
for i in $(seq 100 149); do ./island.sh client ip addr add 10.88.0.$i/24 dev c0; done
time ./island.sh dhcp
grep DHCPOFFER run/dnsmasq.log | tail -n 1
exit

Ветка без dnsmasq: те же команды с ISLAND_FALLBACK=1 (запасной offline_dns.py, без DHCP и кэша). Записать, какой из опытов на запасном сервере даёт иной результат, чем на dnsmasq, и почему.

Что должно получиться

• Таблица «имя — код ответа — адрес» для трёх имён без апстрима; сравнение с C-08-03 (REFUSED, rcode 5).
• Строка DHCP: адрес …, DNS 10.88.0.1, NTP 10.88.0.1 и время выдачи; сравнение с C-08-11 (3,2 с) и объяснение, на что ушло время.
• Результат опыта с пропавшим апстримом: известное имя — из кэша (до истечения TTL), новое — без ответа; выдержка из журнала dnsmasq.
• Результат опыта с конфликтом адресов.

Часть 2. Время: уход часов и рассинхронизация

Задание

Измерить смещение часов клиента относительно сервера узла, затем «увести» часы сервера на 600 с и убедиться, что клиент это обнаруживает. Рассчитать уход часов для своего сценария и сопоставить с порогами протоколов.

Предсказание

1. Какое смещение покажет клиент относительно сервера на той же машине: порядка секунд, миллисекунд или микросекунд?
2. Часы сервера ушли на 600 с. Что произойдёт с проверкой TOTP и Kerberos у клиентов, которые берут время с этого сервера? А с проверкой срока сертификата?
3. На сколько уйдут часы узла за сценарий своего варианта (длительность и температура — teacher/polygon.json) без коррекции и после коррекции по driftfile?

Порядок выполнения

./island.sh up
./island.sh client python3 offline_time.py query 10.88.0.1
exit
ISLAND_TIME_OFFSET=600 ./island.sh up
./island.sh client python3 offline_time.py query 10.88.0.1; echo "код $?"
exit

Если установлен chrony, island.sh запускает на узле настоящий chronyd с conf/chrony-server.conf (local stratum 10, ключ -x: системные часы не трогаются), а при ISLAND_TIME_OFFSET — под faketime. Клиент можно проверить и самим chrony: ./island.sh client chronyd -Q 'server 10.88.0.1 iburst' печатает смещение и ничего не меняет. Если chrony или faketime нет, сервер времени — запасной offline_time.py serve; в журнале это отмечается.

Расчёт для своего сценария (архив учителя или формулы темы 8):

python3 rtc.py --scenario В              # буква своего варианта
python3 rtc.py --scenario Б --cal-temp -20   # калибровка в тех же условиях
python3 rtc.py --ppm 2 --k 0             # DS3231 в 0…+40 °C

Ветка ВМ (по желанию): в ВМ из ЛР 7 установить chrony, отключить источники, сдвинуть время командой date -s '+10 min' и наблюдать chronyc tracking у клиента. Ветка требует root внутри ВМ и выполняется только там.

Что должно получиться

• Смещение клиента относительно своего сервера (порядок величины) и обнаруженный сдвиг 600 с с кодом выхода 3.
• Таблица расчёта rtc.py для своего сценария: уход без коррекции, после driftfile, при калибровке в рабочих условиях; сравнение с C-08-05 (16,2 с) и C-08-06 (40,6 с) для сценария В.
• Короткий ответ на вопрос 2 предсказания, проверенный по теме 8: что зависит от расхождения сторон, а что — от абсолютного времени.

Часть 3. Файлы, знания и бюджет ресурсов

Задание

Проверить с клиента HTTP-каталог, git и (если установлен) kiwix-serve с приложенным ZIM, измерить память и диск служб, рассчитать библиотеку ZIM под носитель своего варианта, оформить запуск одной командой и документ восстановления.

Предсказание

1. Какая из служб узла займёт больше всего резидентной памяти? Во сколько раз больше, чем dnsmasq?
2. Сколько гигабайт ZIM-архивов поместится на носитель своего варианта при резерве 20 %?

Порядок выполнения

./island.sh up
./island.sh client curl -s http://10.88.0.1:8000/README.txt
./island.sh client git clone -q git://10.88.0.1/notes.git /tmp/notes && echo клон есть
./island.sh client curl -s http://10.88.0.1:8080/ | head -n 5     # если есть kiwix-serve
./island.sh client curl -s 'http://10.88.0.1:8080/search?pattern=driftfile' | head -n 20
./island.sh status
exit

Расчёт библиотеки: выписать из каталога https://download.kiwix.org/zim/ (на машине с сетью) размеры трёх–пяти нужных архивов по приоритетам темы 8 и подставить в неравенство S ≤ C·(1 − r) для носителя своего варианта.

Документ восстановления (одна страница в ~/polygon/lr08/RECOVERY.md): что лежит в conf/, какая команда поднимает узел, как проверить каждую службу одной командой, что делать, если порт 53 занят (ss -lunp | grep :53).

Что должно получиться

• Ответы HTTP-каталога, git и kiwix-serve (или отметка SKIP) с клиента.
• Таблица ./island.sh status: служба — RSS, КиБ; сравнение dnsmasq с C-08-12 (4,5 МБ).
• Расчёт библиотеки ZIM для своего носителя с выбранными архивами.
• RECOVERY.md, по которому другой человек поднимет узел, не читая тему.

Журнал работы

Графы «Предсказание» заполняются до опыта, «Факт» — после. Ветка (dnsmasq / запасная, chrony / запасная) указывается в каждой строке, где она важна.

Контрольные вопросы

1. Почему dnsmasq без апстрима отвечает на внешнее имя REFUSED, а не NXDOMAIN? Чем эти ответы различаются для диагностики?
2. Что делает директива local=/polygon.internal/? Что изменилось бы без неё при включённом апстриме?
3. Почему при пропавшем апстриме известное имя ещё отвечает, а новое — нет? Как долго будет отвечать известное?
4. Почему dnsmasq в ЛР не ставят на порт 5353 и почему зона .local не годится для локальных имён?
5. На что уходит время при выдаче адреса по DHCP в опыте и что изменит опция no-ping? Чем это опасно?
6. Почему для Kerberos и TOTP важнее общий источник времени, чем точность часов? Приведите числа C-08-02 (86,8 сут) и C-08-10 (8,68 сут).
7. Какие проверки зависят от абсолютного времени и почему общий локальный сервер от их отказа не защищает?
8. Почему коррекция по driftfile не убирает температурную составляющую ухода? Как калибровать часы перед сценарием Б?
9. Чем DS3231 лучше кварца материнской платы и почему для неотапливаемого помещения берут ±3,5 ppm, а не ±2 ppm?
10. Почему приёмнику GNSS нельзя позволять сдвигать часы узла скачком без проверки?
11. Чем запасные серверы на Python отличаются от dnsmasq и chrony по наблюдаемому поведению в ваших опытах?
12. Какая служба определяет требования узла к памяти и диску и как это следует из ваших измерений?