Автономные сети и синхронизация

В теме 8 были развернуты базовые локальные службы одиночной вычислительной платформы: DNS-сервер, офлайн-библиотека знаний Kiwix, локальный NTP и git-сервер. В теме 10 подробно исследованы физические законы распространения радиоволн, расчет бюджета радиолинии и специальные цифровые протоколы пакетного обмена. Однако в реальном сценарии автономной эксплуатации (сценарии Б и В из темы 1) возникает задача объединения нескольких пространственно разнесенных вычислительных машин — рабочих мест операторов, шлюзов радиосвязи, контроллеров энергосистемы и датчиков — в согласованно работающий распределенный комплекс без обращения к внешней инфраструктуре провайдеров.

В стандартной сетевой архитектуре сетевые узлы опираются на централизованный маршрутизатор с выходом в интернет, арендуют адреса у вышестоящего DHCP-сервера, разрешают доменные имена через глобальные корневые серверы DNS и синхронизируют локальные базы с облачными репозиториями. В условиях автономного узла исчезает каждое из этих внешних звеньев. Топология сети становится динамической: узлы могут внезапно отключаться для сбережения заряда аккумуляторов (тема 3), каналы между ними подвержены затуханию и радиопомехам, а физический кабель может быть поврежден. Централизованный сервер превращается в классическую единую точку отказа (SPOF).

В этой теме рассматриваются принципы построения отказоустойчивых автономных сетей и распределенной синхронизации. Первая часть посвящена физической кабельной инфраструктуре, энергоэффективному питанию сетевого оборудования (PoE) и сегментации сети на доверенные и гостевые зоны под управлением маршрутизаторов OpenWrt. Во второй части исследуются децентрализованные ячеистые сети (mesh-сети) на основе протокола batman-adv и стандарта IEEE 802.11s. Третья часть разбирает одноранговую P2P-синхронизацию данных утилитой Syncthing на базе векторных часов и механизмы разрешения конфликтов. В четвертой части анализируется специфика передачи трафика стека TCP/IP по узкополосным радиоканалам с высоким RTT и потерями, настройка MTU и правила MSS Clamping. Завершают тему локальный мониторинг параметров автономности и правила безопасности изолированного сетевого периметра.

Сетевая инфраструктура и сегментация автономного узла

Проводная среда против радиоэфира

При проектировании локальной сети автономного узла часто возникает искушение полностью отказаться от кабелей в пользу беспроводной связи Wi-Fi. В условиях автономии этот подход порождает серьезные риски ¹.

В таблице представлено сопоставление физических сред передачи данных в стационарном периметре автономного узла:

Инженерное правило автономного узла: там, где возможно проложить медный кабель, используется провод. Проводная среда гарантирует выделенную полосу без коллизий, не тратит драгоценные милливатты энергии аккумулятора на радиопередатчики высокой мощности и не создает радиочастотного следа за пределами площадки. Беспроводной канал Wi-Fi резервируется исключительно для мобильных терминалов операторов и полевых датчиков, где кабель невозможен физически ¹.

Трехуровневая сегментация периметра

Объединение всех сетевых устройств автономного узла в единое несегментированное адресное пространство (flat network) — грубая архитектурная ошибка. Гостевой смартфон, подключившийся к локальному Wi-Fi, начинает рассылать широковещательные пакеты (mDNS, NetBIOS, ARP), перегружая радиоэфир, а вирусное ПО или скомпрометированный датчик получают прямой доступ к консолям управления накопителями и шиной электропитания.

Сеть автономного узла разделяется на три изолированные зоны безопасности:

Зона 1: Аппаратное ядро (Core / Infra)
        ├── Хранилище данных, Kiwix, локальный git (тема 8)
        ├── Резолвер DNS (unbound), сервер времени NTP
        ├── Шлюзы пакетной радиосвязи LoRa/AX.25 (тема 10)
        └── Контроллер BMS аккумулятора и шина телеметрии (тема 4)

Зона 2: Рабочая зона (Work / Operations)
        ├── Защищенные ноутбуки дежурных операторов
        └── Локальные рабочие терминалы с доступом по SSH-ключам

Зона 3: Гостевой периметр (Guest / Perimeter)
        ├── Личные мобильные устройства и смартфоны
        ├── Недоверенные внешние датчики
        └── Временные узлы соседних площадок

Сегментация реализуется на канальном уровне с помощью виртуальных сетей VLAN (стандарт IEEE 802.1Q) либо разделением физических портов управляемого коммутатора ⁴:

• VLAN 10 (Core): подсеть 192.168.10.0/24. Прямой доступ к портам администрирования закрыт для всех, кроме доверенных IP зоны Work по статическим сертификатам.
• VLAN 20 (Work): подсеть 192.168.20.0/24. Доверенные клиенты имеют доступ к сервисным портам ядра (DNS 53/udp, NTP 123/udp, HTTP Kiwix 8080/tcp, Syncthing 22000/tcp).
• VLAN 30 (Guest): подсеть 192.168.30.0/24. Зона изолирована: межсетевой экран блокирует любые попытки обращения к адресам VLAN 10 и VLAN 20, за исключением локального DNS-сервера. Внутри беспроводной сети VLAN 30 принудительно включен режим межабонентской изоляции (англ. client isolation), запрещающий прямой обмен кадрами между гостевыми клиентами.

Питание сетевого оборудования и технологии PoE

Сетевое оборудование автономного узла (коммутаторы, маршрутизаторы, внешние радиомосты) должно питаться непосредственно от шины постоянного тока 12 В, 24 В или 48 В (тема 3) без промежуточного инвертора 230 В. Питание роутера через инвертор и штатный блок «230 В → 12 В» означает два преобразования подряд и вдобавок ток холостого хода инвертора, который течёт и тогда, когда сеть простаивает; сколько это стоит в ватт-часах для конкретного инвертора и нагрузки, считается в теме 3 симулятором energy.py, а не принимается на веру.

Для передачи питания по сетевому кабелю витой пары совместно с данными используется технология PoE (англ. Power over Ethernet):

1. Пассивный PoE (англ. passive PoE): постоянное напряжение шины (12 или 24 В) подаётся в свободные пары кабеля 100BASE-TX (пара 4–5 — «плюс», пара 7–8 — «минус») через предохранитель. Это простое решение для уличных точек доступа и камер, но без согласования: источник не проверяет, что на другом конце устройство, рассчитанное на это напряжение. Две жилы пары включены параллельно, поэтому сопротивление петли «туда и обратно» на метр кабеля равно сопротивлению одной жилы 24 AWG — 0,0842 Ом/м (стандарт ограничивает его сверху значением 9,38 Ом/100 м, C-11-09). Для нагрузки 6 Вт от шины 12 В по 30 м кабеля на устройстве остаётся 10,57 В (C-11-08), то есть 12 % напряжения теряется в кабеле, а при 50 м — уже 23 % (net.py --poe-m 50). Многие платы с входом «12 В» при 9–10 В перезагружаются под нагрузкой передатчика.
2. Стандарты IEEE 802.3af и 802.3at (PoE и PoE+): активное питание напряжением около 48 В с мощностью на выходе источника 15,4 и 30 Вт (C-11-11) ³. Источник (PSE) сначала проверяет сигнатурное сопротивление нагрузки и только потом подаёт напряжение. При 48 В ток вчетверо меньше, чем при 12 В той же мощности, и потери в кабеле (P = I^2 R) меньше в 16 раз: на тех же 30 м падение составляет 0,66 % вместо 12 %.

Сетевая операционная система OpenWrt

В качестве ядра маршрутизации автономного узла оптимально применение аппаратных роутеров на архитектурах MIPS или ARM под управлением дистрибутива OpenWrt ⁴. В отличие от закрытых заводских прошивок, OpenWrt представляет собой полноценный Linux на базе ядра LTS с пакетным менеджером (opkg до версии 24.10, apk начиная с OpenWrt 25.x), подсистемой фильтрации nftables и поддержкой виртуальных сетевых интерфейсов.

Преимущества OpenWrt на автономном узле:

• Малое энергопотребление: роутер потребительского класса на SoC вроде MediaTek MT7621 потребляет единицы ватт. Это оценка по паспортам подобных устройств, а не измерение: потребление зависит от числа радиомодулей, мощности передатчиков и нагрузки на порты. Для энергобаланса темы 3 его измеряют на своём экземпляре ваттметром постоянного тока в режиме простоя и под нагрузкой.
• Единый текстовый конфигурационный интерфейс (UCI): все настройки сети хранятся в простых текстовых файлах каталога /etc/config/ (network, wireless, firewall, dhcp), что позволяет версионировать их в git (тема 8) и восстанавливать одной командой.
• Полная автономность: встроенный демон dnsmasq обеспечивает локальное разрешение DNS и выдачу адресов DHCP без обращения к внешним серверам.

Пример минимальной конфигурации сегмента ядра в /etc/config/network для устройств с драйвером DSA (OpenWrt 21.02 и новее): VLAN описывается секцией bridge-vlan на мосту, а старая запись вида eth0.10 относится к устройствам со встроенным коммутатором без DSA ⁴:

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'

config bridge-vlan
	option device 'br-lan'
	option vlan '10'
	list ports 'lan1:u*'

config interface 'core'
	option device 'br-lan.10'
	option proto 'static'
	option ipaddr '192.168.10.1'
	option netmask '255.255.255.0'

Распределенные mesh-сети без центрального шлюза

Архитектура и ограничения ячеистых сетей

Звездообразная топология с единственным маршрутизатором OpenWrt эффективна внутри компактной аппаратной, однако при территориальном рассредоточении узлов (несколько жилых построек, ретранслятор на мачте, полевой пост наблюдения) центральный маршрутизатор становится критической единицей отказа (SPOF) ⁵. Если мачта с центральным роутером обесточивается или повреждается ветром, связь между периферийными узлами полностью исчезает, даже если они физически видят друг друга по радиоканалу.

Решением является построение децентрализованной ячеистой сети (англ. mesh network). В mesh-сети каждый узел является одновременно и оконечной станцией, и транзитным маршрутизатором (ретранслятором). Пакеты передаются от источника к адресату по цепочке промежуточных узлов (англ. multi-hop forwarding). При выходе из строя любого промежуточного узла топология динамически перестраивается, направляя поток по альтернативным связям.

Однако ячеистые беспроводные сети подчиняются жесткому физическому ограничению: падение эффективной пропускной способности с каждым транзитным скачком (хопом) ⁵. Поскольку все узлы типовой mesh-сети работают на одном и том же радиоканале в полудуплексном режиме (англ. half-duplex), промежуточный узел-ретранслятор не может одновременно принимать кадр от предыдущего узла и передавать его следующему. Он вынужден сначала принять пакет в буфер, занять радиоканал повторно и передать его дальше.

Если все узлы цепочки слышат друг друга (одна область конкуренции), в каждый момент передаёт только один из них, и полоса цепочки из N одинаковых переходов равна C/N. В длинной цепочке далёкие узлы не мешают друг другу, и при идеальном расписании передачи через каждые три перехода идут одновременно: полоса перестаёт падать и упирается примерно в C/3; реальный MAC 802.11 со скрытыми узлами и коллизиями даёт ближе к C/4 ⁵. Для цепочки из 4 переходов по 20 Мбит/с модель net.py даёт 6,67 и 5,0 Мбит/с в двух предположениях (C-11-02). Число «20 Мбит/с» здесь — условие задачи: номинальные 54 Мбит/с относятся к 802.11g, а реальная полезная скорость одного перехода зависит от стандарта, ширины канала, расстояния и помех и измеряется iperf3. Отсюда инженерное правило: беспроводные mesh-сети проектируются с минимальным числом транзитных скачков (предпочтительно не более 2–3 хопов), а магистральные линки между кластерами прокладываются кабелем или направленными радиомостами на раздельных частотных каналах.

Протокол B.A.T.M.A.N. Advanced (batman-adv)

В классической маршрутизации (OSPF, RIP, Babel) каждый узел работает на сетевом уровне (Layer 3 OSI), манипулируя IP-пакетами и требуя назначения уникальных IP-подсетей на каждом физическом интерфейсе. Это создает колоссальные сложности в автономных сетях: при смене маршрута IP-адрес шлюза меняется, что приводит к разрыву активных сессий TCP и необходимости переконфигурации служб ⁵.

Протокол B.A.T.M.A.N. Advanced (Better Approach To Mobile Adhoc Networking, batman-adv) решает эту проблему радикально: он работает на канальном уровне (Layer 2 OSI) в виде модуля ядра Linux ⁶.

С точки зрения операционной системы и прикладных программ batman-adv выглядит как обычный виртуальный Ethernet-интерфейс bat0. Все узлы mesh-сегмента находятся в единой общей IP-подсети (например, 10.0.0.0/24). Компьютеры могут свободно мигрировать между точками доступа, а широковещательные запросы ARP и DHCP прозрачно передаются через всю ячеистую структуру.

Принцип работы алгоритма batman-adv ⁶:

1. Каждый узел периодически рассылает во все доступные физические интерфейсы короткие широковещательные пакеты — сообщения инициатора (англ. Originator Messages, OGM).
2. Сообщение OGM содержит адрес узла-источника и порядковый номер (Sequence Number). Соседи, получив OGM, регистрируют факт приема, пересчитывают метрику качества линка и ретранслируют пакет дальше.
3. Метрика качества передачи (англ. Transmit Quality, TQ) вычисляется как отношение успешно принятых OGM к общему числу отправленных за скользящее окно (обычно 64 пакета), с учетом асимметрии канала (проверка эхо-ответов от соседа). Значение TQ варьируется от 0 (канал мертв) до 255 (идеальный линк без потерь).
4. Узел не строит глобальную карту всей сети: для каждого известного адресата узел знает только одно значение — какой из непосредственных физических соседей обеспечивает наилучший интегральный TQ до цели.
5. При поступлении исходящего Ethernet-кадра ядро упаковывает его в заголовок batman-adv и отправляет в интерфейс выбранного лучшего соседа (next-hop).

Настройка интерфейса batman-adv в Linux:

# Добавление физического Wi-Fi интерфейса в mesh-мост
ip link set dev wlan0 down
iw dev wlan0 set type ibss
ip link set dev wlan0 up
iw dev wlan0 ibss join autonomy-mesh 2412

# Подключение wlan0 к batman-adv
batctl if add wlan0
ip link set dev bat0 up
ip addr add 10.0.0.1/24 dev bat0

Стандарт IEEE 802.11s и гибридные топологии

Альтернативой модулю ядра batman-adv является стандарт IEEE 802.11s — официальное расширение стандарта Wi-Fi для ячеистых сетей, поддерживаемое на уровне беспроводного стека mac80211 ядра Linux ⁷.

В 802.11s узлы (Mesh Points, MP) устанавливают прямые радиосвязи (Mesh Peering) без участия классической точки доступа. Маршрутизация кадров выполняется протоколом HWMP (англ. Hybrid Wireless Mesh Protocol), сочетающим реактивный поиск маршрутов по запросу (по аналогии с AODV) и проактивное построение дерева до корневого узла (Root Node) ⁷.

Сравнение batman-adv и IEEE 802.11s:

• 802.11s работает только поверх радиоинтерфейсов Wi-Fi и не умеет напрямую объединять разнородные каналы в одну сеть без внешнего сетевого моста (bridge).
• batman-adv не привязан к Wi-Fi: он объединяет в один интерфейс bat0 любые интерфейсы, передающие кадры Ethernet (радио в режиме ad-hoc или mesh point, витая пара, VLAN, туннель уровня L2), и выбирает путь с лучшей метрикой TQ — например, кабель, а при его обрыве радио. Последовательный радиомодем со SLIP в этот список не входит: SLIP переносит только IP-пакеты (уровень L3), а batman-adv работает с кадрами Ethernet (L2). Поверх такого канала маршрутизируют на уровне IP (Babel, статические маршруты).

Направленные линки, AREDN и грозозащита мачт

Между зданиями и постами, разнесёнными на сотни метров и километры, полудуплексную цепочку mesh заменяют направленными радиомостами точка — точка на отдельных каналах: каждый мост — отдельный переход, не мешающий соседям, и формула C/N к ним не применяется. Расчёт такого моста — бюджет линии из темы 10: усиление направленных антенн, потери фидера, свободная первая зона Френеля над препятствиями посередине трассы. Типичная ошибка — проверить «прямую видимость в бинокль» и не проверить зону Френеля: на трассе 2 км на 5 ГГц её радиус посередине 5,2 м, и крыша соседнего сарая уже ощутимо ослабляет сигнал (расчёт linkbudget.py --freq 5500 --dist 2 из темы 10).

AREDN (Amateur Radio Emergency Data Network) — готовая прошивка на основе OpenWrt для любительских mesh-сетей на частотах Wi-Fi, работающих в любительских диапазонах: узлы сами находят друг друга, маршрутизация (OLSR, в новых версиях Babel) и локальные службы настроены заранее. Ограничение то же, что у любой любительской связи: работа в любительских полосах требует позывного у каждого оператора, а шифрование трафика правилами любительской службы обычно запрещено. Для автономного узла без любительских позывных AREDN — образец архитектуры, а не готовое решение; в нелицензируемых полосах Wi-Fi ту же роль играют OpenWrt с batman-adv или 802.11s.

Мачта с антенной — самая высокая проводящая точка площадки. Мачту заземляют отдельным проводником кратчайшим путём, оплётку кабеля снижения заземляют у входа в здание, на ввод ставят грозоразрядник; кабель Ethernet с крыши заводят через устройство защиты от перенапряжений, а не напрямую в коммутатор ядра. Механизмы перенапряжений и выбор защиты разобраны в теме 12; в этой теме важен вывод для топологии: уличные точки доступа и мосты подключают к ядру через отдельный порт и предохранитель цепи PoE, чтобы удар в мачту не вывел из строя всю сеть.

Динамическая перемаршрутизация при отказах промежуточных узлов

Ключевое эксплуатационное свойство mesh-сети — скорость обнаружения аварии и сходимости топологии (англ. convergence time).

Если узел B внезапно обесточивается:

1. Соседние узлы A и C фиксируют прекращение поступления сообщений OGM от узла B.
2. Через несколько пропущенных интервалов OGM (по умолчанию OGM рассылается раз в секунду) метрика соседа B падает до нуля. Точное время зависит от версии алгоритма (B.A.T.M.A.N. IV или V) и параметров; в ЛР 11 время восстановления измеряется, а не берётся из текста.
3. В таблице транзитной пересылки маршрут к удаленным узлам переключается на альтернативного соседа с наилучшим из оставшихся TQ (например, через транзитный узел E на рисунке топологии).
4. Адреса конечных хостов не изменились, поэтому соединения TCP не рвутся: TCP видит паузу (одну или несколько повторных передач по RTO) и продолжает поток по новому пути. Это верно не только для batman-adv: при смене маршрута на уровне L3 (Babel, OSPF) адреса концов соединения тоже не меняются, и TCP переживает перестройку, если она укладывается в его таймауты. Рвётся соединение тогда, когда меняется адрес самого хоста (NAT на другом шлюзе, новый адрес по DHCP).

Статическая маршрутизация такого не умеет: если сосед B завис или потерял радиосвязь дальше, а его интерфейс к A остался поднят, ядро A продолжает отправлять пакеты в B. Отказ соседа без потери несущей замечает только протокол, который регулярно проверяет соседа. Именно это сравнивается в ЛР 11.

Распределенная синхронизация данных между узлами

Архитектура протокола Syncthing (BEP)

Когда сетевая связность между узлами налажена, возникает задача репликации файлов: базы оперативных заметок, журналов телеметрии, актуальных карт и конфигураций. Использование традиционных протоколов клиент-серверного доступа (SMB, NFS, HTTP) в автономных сетях неэффективно: если сервер файлов выключен или недоступен из-за радиопомех, работа остальных узлов останавливается ⁸.

Современным стандартом одноранговой децентрализованной репликации является Syncthing ⁸. Это открытая распределенная система синхронизации файлов, не требующая центрального сервера и функционирующая по протоколу обмена блоками (англ. Block Exchange Protocol, BEP).

Ключевые принципы архитектуры Syncthing:

1. Криптографическая идентификация узлов: у каждого узла нет логина и пароля; идентификатором узла служит Device ID — строка из 56 символов в формате Base32, представляющая собой SHA-256 хэш открытого ключа сертификата TLS, сгенерированного при первом запуске узла ⁸.
2. Взаимная аутентификация и сквозное шифрование: все сетевые соединения между узлами устанавливаются строго по протоколу TLS 1.3 с взаимной проверкой сертификатов (mTLS). Подмена данных или прослушивание пакетов в незащищенном радиоэфире mesh-сети криптографически исключены.
3. Блочная синхронизация: файл разбивается на блоки фиксированного размера (от 128 КиБ до 16 МиБ в зависимости от размера файла), каждый блок индексируется хешем SHA-256 ⁸. Если в файле заменить байты на месте, передаётся только изменённый блок. Но границы блоков стоят на фиксированных смещениях: вставка одной строки в начало файла сдвигает все последующие байты, хеши всех следующих блоков меняются, и передаётся весь хвост файла. Резервные копии в теме 9 используют другую схему — нарезку по содержимому (англ. content-defined chunking, CDC), где границы блоков привязаны к самим данным и вставка затрагивает один-два блока. Для журнала, дописываемого в конец, фиксированные блоки работают хорошо; для текста, правящегося в начале, — плохо.

Обнаружение соседей в изолированной сети

В стандартной заводской конфигурации Syncthing полагается на глобальные серверы обнаружения (Global Discovery) и общедоступные узлы ретрансляции трафика (Relay Servers), расположенные в сети Интернет.

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

Настройка Syncthing для полностью автономной работы:

1. Отключение глобального обнаружения: в конфигурации config.xml отключаются параметры globalAnnounceEnabled и relaysEnabled.
2. Активация локального обнаружения (Local Discovery): узлы находят друг друга автоматически путем периодической отправки широковещательных пакетов (IPv4 Broadcast на порт 21027/udp) и групповых пакетов (IPv6 Multicast на адрес ff12::8384). Пакет содержит Device ID отправителя и порт прослушивания (стандартно 22000/tcp).
3. Статические адреса для радиоканалов: если узлы соединены через медленный радиомодем или маршрутизатор, фильтрующий широковещательный трафик, адрес соседа задается статически в явном виде: tcp://10.0.0.2:22000.

Векторные часы и разрешение конфликтов параллельной правки

В распределенной системе без общего источника точного времени (тема 8) невозможно определить, какая версия файла новее, просто сравнивая метки времени операционной системы (mtime): часы на двух изолированных ноутбуках могут расходиться на минуты или часы ⁸.

Syncthing использует векторы версий (англ. version vectors) — разновидность векторных часов, предложенных Фиджем и Маттерном в 1988 году ⁹; скалярные часы Лампорта (1978) упорядочивают события, но не позволяют отличить «после» от «одновременно». Каждый файл сопровождается версионным вектором — списком пар вида:

V = \{ (\text{Device}_1, c_1), (\text{Device}_2, c_2), \dots, (\text{Device}_k, c_k) \}

где c_i — монотонно возрастающий локальный счетчик модификаций файла на узле \text{Device}_i.

Правило доминирования версий:

• Версия V_A признается более новой, чем V_B (V_A > V_B), если для всех узлов счетчики V_A не меньше счетчиков V_B (\forall i: c_i^A \ge c_i^B), и существует хотя бы один узел, где счетчик строго больше (c_j^A > c_j^B). В этом случае файл на узле B молча и безопасно обновляется содержимым файла A.
• Если же на узле 1 счетчик увеличился (c₁ = 5, c₂ = 2), а на узле 2 одновременно файл был изменен локально (c₁ = 4, c₂ = 3), ни один из векторов не доминирует над другим. Это состояние называется параллельным конфликтом (англ. concurrent conflict) ⁹.

Правило разрешения конфликта (описание в документации Syncthing, раздел «Conflicting Changes» ¹⁴). Вектор версий решает только вопрос «есть ли конфликт»; какая версия уступит, решает время изменения:

1. Версия с более старым временем изменения (mtime) переименовывается в конфликтную копию, под исходным именем остаётся более новая.
2. Только если mtime равны, конфликтной становится версия устройства с большим значением Device ID (сравниваются первые 63 бита).
3. Имя копии содержит дату, время и короткий ID устройства, которое последним изменило эту версию:

notes.sync-conflict-20261020-143015-V7XQ4KM.txt

4. Копия синхронизируется на все узлы как обычный файл; оператор сливает правки вручную (diff, редактор) и удаляет копию.

Из правила 1 следует практический вывод: разрешение конфликта всё же зависит от часов. Если часы одного ноутбука ушли на сутки вперёд (тема 8), его версия будет «побеждать» в каждом конфликте. Обе версии при этом сохраняются, поэтому данные не теряются, но под исходным именем может оказаться не та версия, которую ожидали. Если одна сторона файл изменила, а другая удалила, побеждает изменение: файл восстанавливается.

Синхронизация не заменяет резервную копию

Синхронизация реплицирует любое изменение — в том числе удаление, перезапись мусором и шифрование файлов вредоносной программой. Удалённый на одном узле файл через секунды исчезает на всех. Резервная копия (тема 9), наоборот, хранит состояние на моменты в прошлом и не меняется от того, что происходит с рабочими данными; поэтому её точка восстановления (RPO) — время последнего снимка, а у синхронизации «точки в прошлом» нет вовсе. Механизм версий файлов Syncthing (File Versioning) хранит прежние версии на принимающем узле и спасает от части ошибок, но живёт на том же диске, с той же папкой, и не защищает от отказа узла и от удаления самих версий. Поэтому на Полигоне синхронизация отвечает за доступность данных на нескольких машинах, а резервное копирование (restic или borg по теме 9) — за возможность вернуться назад; опыт «удаление реплицируется» входит в ЛР 11.

Что нельзя синхронизировать в P2P-сети

Попытка использовать Syncthing для синхронизации любых произвольных каталогов операционной системы приведет к сбоям и разрушению данных.

Через P2P-синхронизацию не передают:

1. Активные файлы баз данных (SQLite, PostgreSQL, MySQL): СУБД непрерывно пишут в файлы страниц и журналов упреждающей записи (WAL — Write-Ahead Log). Попытка поблочно реплицировать открытый файл .db во время активных транзакций приведет к записи на удаленном узле несогласованного состояния («разорванной страницы», англ. torn page), что необратимо разрушит базу данных. Синхронизировать можно только заблаговременно снятые дампы (например, файл, созданный командой sqlite3 data.db ".backup backup.sq3").
2. Виртуальные диски и образы ВМ (raw, qcow2): файлы размером в десятки гигабайт с постоянной случайной записью блоков создают непрерывную нагрузку на радиоканал и процессор.
3. Системные каталоги ОС (/etc, /var, /dev): Syncthing работает в пространстве пользователя и не сохраняет специфические права суперпользователя, расширенные атрибуты безопасности (SELinux/xattr) и специальные файлы устройств (пайпы, сокеты).

Для синхронизации текстовых конфигураций и программного кода лучшим инструментом остается Git ¹⁰. В условиях отсутствия онлайн-хостингов Git функционирует через локальные bare-репозитории либо отчуждаемые пакетные архивы git bundle (тема 8). Команда git bundle create updates.bundle master упаковывает всю историю коммитов и веток в единый файл, который переносится на соседний узел через Syncthing или на флеш-карте и распаковывается командой git pull updates.bundle.

Радиоканал как транспорт для протоколов стека TCP/IP

Инкапсуляция IP в радиопакеты: SLIP, PPP, AX.25

Когда требуется передать IP-трафик между удаленными автономными узлами, разделенными десятками километров, единственным физическим носителем становится УКВ или КВ радиостанция (тема 10) ¹¹.

Для передачи IP-пакетов через последовательные интерфейсы радиомодемов применяются протоколы инкапсуляции:

1. SLIP (Serial Line Internet Protocol, RFC 1055): предельно простой протокол кадрирования. Каждый IP-пакет обрамляется байтом 0xC0 (END). Если байт 0xC0 встречается внутри данных, он заменяется двухбайтовой последовательностью 0xDB 0xDC. Протокол не имеет механизмов согласования адресов, проверки контрольных сумм и сжатия заголовков.
2. PPP (Point-to-Point Protocol, RFC 1661): стандарт двухточечной связи. Включает контроль целостности кадра (FCS — 16-битный CRC), согласование сетевых параметров по протоколу IPCP и возможность аутентификации.
3. AX.25 (Amateur Packet Radio Protocol): радиолюбительский протокол канального уровня, поддерживающий аппаратные и программные модемы TNC (Terminal Node Controller, утилита direwolf, тема 10). Ядро Linux содержит встроенную поддержку AX.25: утилита kissattach связывает последовательный порт радиомодема с сетевым интерфейсом ax0, поверх которого операционная система способна маршрутизировать стандартные IPv4-пакеты ¹¹.

Проблема высокого RTT, потерь и деградация TCP

Протокол TCP разрабатывался для проводных сетей с низкой задержкой (RTT единицы миллисекунд) и крайне низкой вероятностью битовых ошибок (BER < 10⁻⁹). В проводном Ethernet практически единственной причиной потери пакета является переполнение очереди коммутатора (англ. buffer overflow) при перегрузке ¹².

При передаче через радиоэфир физическая реальность меняется кардинально ¹²:

• Круговая задержка велика из-за низкой скорости и полудуплекса. Кадр 1500 + 18 байт на 1200 бит/с передаётся 10,12 с (C-11-05); с подтверждением и задержкой включения передатчика 300 мс RTT одного радиоперехода не меньше 11,1 с (C-11-06) — и это нижняя граница, без ожидания свободного канала. Начальное значение таймера повторной передачи TCP — 1 с (C-11-07) ¹³: первый сегмент будет повторён раньше, чем могло прийти подтверждение.
• Ошибки бит в радиоканале на порядки чаще, чем в проводе. Значение BER зависит от запаса линии (тема 10); в примерах этого раздела взято BER = 2 \cdot 10^{-4} как условие задачи.

Когда пакет теряется из-за помехи, алгоритм управления перегрузкой TCP (Reno, CUBIC) принимает эту потерю за перегрузку сети ¹². Реакция зависит от того, как потеря обнаружена. Если пришли три повторных подтверждения (сегменты после потерянного дошли), окно перегрузки (англ. congestion window, cwnd) уменьшается примерно вдвое и включается быстрое восстановление. Если же подтверждений нет вовсе и истёк таймер RTO, cwnd сбрасывается до одного сегмента, начинается медленный старт, а RTO удваивается при каждом следующем истечении. На медленном радиоканале с длинными кадрами срабатывает как раз второй случай: окно мало, повторным подтверждениям неоткуда взяться.

Итог: скорость падает почти до нуля, а повторы занимают тот же полудуплексный канал, по которому должны прийти подтверждения. Подробно механизмы TCP разобраны в курсе «Компьютерные сети», тема 13; здесь важно следствие для автономного узла: по радиоканалу передают короткие сообщения поверх UDP с собственным подтверждением (CoAP — RFC 7252, протоколы store-and-forward из темы 10) или используют TCP с увеличенными таймаутами и малым MSS, а большие файлы переносят носителем или ночным окном связи.

Алгоритм BBR (net.ipv4.tcp_congestion_control=bbr) не считает каждую потерю перегрузкой и на каналах со случайными потерями ведёт себя лучше Reno и CUBIC, но таймер RTO и полудуплекс он не отменяет.

Оптимизация MTU и MSS Clamping

Стандартный размер максимального блока передачи (англ. Maximum Transmission Unit, MTU) в сетях Ethernet составляет 1500 байт ¹.

В радиоканале с высокой вероятностью битовой ошибки MTU 1500 байт почти не работает. Вероятность успешного прохождения кадра длиной L бит при вероятности ошибки в одном бите BER рассчитывается по формуле Бернулли:

P_{success} = (1 - BER)^L

Соответственно, вероятность искажения хотя бы одного бита (и, как следствие, сброса всего пакета контрольной суммой CRC32):

P_{loss} = 1 - (1 - BER)^L

Числовой пример: расчет потерь пакетов от размера MTU

Сравним поведение двух пакетов при передаче по радиоканалу с типичным уровнем шума, обеспечивающим вероятность битовой ошибки BER = 2 \cdot 10^{-4} (один сбойный бит на каждые 5000 бит):

• Пакет 1: Стандартный Ethernet MTU = 1500 байт (1500 · 8 = 12 000 бит).
• Пакет 2: Оптимизированный радио-MTU = 256 байт (256 · 8 = 2048 бит).

Вероятность потери пакета 1 (MTU 1500): P_{loss}(1500) = 1 - (1 - 2 \cdot 10^{-4})^{12\,000} = 1 - (0,9998)^{12\,000} \approx 1 - 0,0907 = 0,9093 \text{ (то есть } 90,93 \% \text{)}

Вероятность потери пакета 2 (MTU 256): P_{loss}(256) = 1 - (1 - 2 \cdot 10^{-4})^{2048} = 1 - (0,9998)^{2048} \approx 1 - 0,6638 = 0,3362 \text{ (то есть } 33,62 \% \text{)}

Таким образом, при BER = 2 \cdot 10^{-4} кадр 1500 байт теряется с вероятностью 90,9 % (C-11-01, расчёт net.py).

Кадр 256 байт при той же BER теряется с вероятностью 33,6 % (C-11-03): доля доставленных с первой попытки растёт с 9 % до 66 %. Уменьшать MTU бесконечно тоже нельзя: заголовки IP и TCP (40 байт) занимают всё большую долю кадра. Если считать полезную долю с учётом повторов, \eta = \frac{L - 40}{L}(1 - P_{loss}), то её максимум при BER = 2 \cdot 10^{-4} достигается при MTU 179 байт и равен 58,3 % (C-11-04). Оптимум зависит от BER: при 10^{-4} он около 244 байт, при 10^{-3} — около 93 байт (net.py --ber 1e-3). Формула предполагает независимые ошибки бит; в радиоканале ошибки идут пачками, и это ограничение названо в шапке net.py.

Однако простого уменьшения MTU на сетевом интерфейсе радиомодема (ip link set dev ax0 mtu 256) недостаточно: удаленные клиенты в сети Ethernet не знают об узком месте и продолжают отправлять пакеты размером 1500 байт с установленным флагом «Не фрагментировать» (DF — Don't Fragment). Пакеты отбрасываются, а сообщения ICMP «Destination Unreachable, Fragmentation Needed» часто блокируются некорректно настроенными экранами (проблема «черной дыры Path MTU Discovery», PMTUD Black Hole) ¹.

Решение: принудительная перезапись максимального размера сегмента (MSS Clamping) на пограничном маршрутизаторе OpenWrt с помощью nftables ⁴:

# Правило nftables: перехват рукопожатия TCP SYN и принудительное ограничение MSS
nft add rule inet fw4 forward tcp flags syn tcp option maxseg size set 216

(При MTU = 256 байт вычитание 20 байт заголовка IP и 20 байт заголовка TCP даёт MSS = 256 − 40 = 216 байт.)

Локальный мониторинг и телеметрия узла

Метрики автономности: питание, температура, дисковый износ

В автономной системе мониторинг решает принципиально иную задачу, чем в корпоративном ЦОД. Вместо загрузки очередей веб-сервера первостепенными становятся метрики живучести аппаратной платформы и энергосистемы:

1. Энергетические метрики (от контроллера заряда и BMS, тема 4):
   • Напряжение главной шины питания (U_шины, В) с точностью до 0,05 В.
   • Ток заряда/разряда (I_шины, А).
   • Расчетная глубина разряда и оставшаяся емкость (SOC, %).
2. Температурные метрики (от датчиков I²C/1-Wire и термозон процессора):
   • Температура аккумуляторного блока (критично для LiFePO4: заряд ниже 0 °C разрушает структуру электродов).
   • Температура радиатора пассивного охлаждения процессора и контроллера SSD.
3. Состояние накопителей (по данным демона smartd):
   • Рост атрибутов дефектных секторов (Reallocated / Pending).
   • Свободное дисковое пространство на корневом и архивном разделах (порог тревоги: менее 15 % остатка).
4. Сетевые метрики:
   • Доступность шлюзов и ключевых узлов кластера.
   • Уровень шума в эфире (RSSI / SNR) и статистика потерянных пакетов.

Легковесный сбор телеметрии без внешних облаков

Развертывание тяжелых промышленных систем мониторинга (Zabbix, стек ELK) на автономном узле нерационально: они потребляют гигабайты оперативной памяти и сотни мегабайт дисковой записи в сутки, расходуя ресурс флеш-памяти и батарей.

Архитектура локального сбора телеметрии строится на легковесных компонентах:

• Периодический сбор скриптами (Cron / Systemd Timers): легковесный скрипт на Bash или Python опрашивает интерфейсы /sys/class/thermal/ и /sys/class/power_supply/ раз в 60 секунд.
• Хранилище временных рядов (TSDB): использование локальной базы данных SQLite с кольцевой перезаписью или компактного экземпляра VictoriaMetrics в режиме одного бинарника без внешних зависимостей.
• Кольцевые журналы в оперативной памяти (tmpfs): оперативные логи пишутся в RAM-диск /run, сбрасываясь на энергонезависимый накопитель только при аварийных событиях, что предотвращает износ SSD.

Локальные оповещения и аварийная сигнализация

Поскольку отправка email-уведомлений или push-сообщений в Telegram без интернета невозможна, каналы оповещения оператора реализуются физическими и локальными средствами:

1. Аппаратный звуковой сигнализатор (пьезоэлектрический зуммер / buzzer): подключен к контактам GPIO одноплатного компьютера. При критическом падении напряжения шины (например, U < 11,8 В) звучит прерывистый сигнал тревоги, пробуждающий дежурного оператора.
2. Светодиодная шкала статуса: дискретная индикация уровней деградации узла (зеленый — Уровень 0–1, желтый — Уровень 2, мигающий красный — авария питания).
3. Локальный пейджинг через XMPP/IRC (тема 8): бот рассылает текстовые предупреждения в локальный групповой чат автономного узла.

Распределение ролей между машинами и координация людей

Службы темы 8 (DNS, время, справочные материалы, файлы, мониторинг) не обязаны жить на одной машине, но и разносить их на все машины подряд вредно: каждая лишняя копия службы — лишний потребитель энергии и лишний источник рассинхронизации. Рабочее разбиение для Полигона: «сервер» (одноплатный компьютер или ноутбук с наименьшим потреблением) держит DNS, DHCP, время, мониторинг и основную копию данных; рабочие места хранят свои рабочие папки и синхронизируют их с сервером; резервная машина выключена большую часть времени, получает резервные копии по расписанию (тема 9) и умеет за известное время взять на себя роль сервера. Что именно и за сколько минут переносится на резервную машину, записывается в регламент темы 13 и проверяется учением.

Организационная часть ломается раньше технической: два оператора правят один документ, никто не знает, кто сейчас дежурит, сообщение по радио принято, но не передано дальше. Поэтому на сервере держат простые локальные инструменты координации: доску задач (текстовый файл или вики wiki.polygon.internal), общий календарь окон связи и дежурств, журнал смен, куда каждый записывает принятые решения и изменения конфигурации. Правило записи «кто — что — когда — почему» дешевле любого протокола разрешения конфликтов.

Безопасность изолированного сетевого сегмента

Защита периметра и изоляция клиентов (Client Isolation)

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

Базовые правила фильтрации трафика nftables на шлюзе OpenWrt:

# Создание таблицы фильтрации автономного шлюза
nft add table inet autonomy_filter
nft add chain inet autonomy_filter forward '{ type filter hook forward priority 0; policy drop; }'

# 1. Разрешить установленные и связанные соединения
nft add rule inet autonomy_filter forward ct state established,related accept

# 2. Разрешить трафик из рабочей зоны (Work) к службам ядра (Core)
nft add rule inet autonomy_filter forward iifname "veth-rw" oifname "veth-rc" accept

# 3. Разрешить гостям (Guest) доступ ТОЛЬКО к локальному DNS и Kiwix на ядре
nft add rule inet autonomy_filter forward iifname "veth-rg" oifname "veth-rc" ip daddr 192.168.10.2 udp dport 53 accept
nft add rule inet autonomy_filter forward iifname "veth-rg" oifname "veth-rc" ip daddr 192.168.10.2 tcp dport 8080 accept

# Все остальные попытки пересылки из Guest в Core и Work блокируются политикой drop

В беспроводной точке доступа гостевого периметра в обязательном порядке активируется опция isolate:

# /etc/config/wireless
config wifi-iface 'guest_ui'
	option device 'radio0'
	option mode 'ap'
	option ssid 'Autonomy-Guest'
	option network 'guest'
	option isolate '1'

Флаг isolate '1' запрещает радиомодулю Wi-Fi пересылать кадры между беспроводными клиентами одной и той же сети. Зараженный смартфон гостя не сможет атаковать соседние телефоны или сканировать порты других пользователей.

Предотвращение утечек трафика и принудительный перехват DNS

Мобильные операционные системы и браузеры проверяют наличие интернета: запрашивают по HTTP служебные адреса (детектор адаптивного портала, англ. captive portal detection: у Android — http://connectivitycheck.gstatic.com/generate_204, у устройств Apple — http://captive.apple.com/hotspot-detect.html) и могут шифровать DNS-запросы: DNS-over-TLS (DoT) работает на порту 853 (C-11-10) ², DNS-over-HTTPS (DoH) — на порту 443 вместе с обычным HTTPS.

В изолированной сети такое поведение приводит к зависанию приложений и ложным сообщениям «Сеть без доступа к интернету, отключиться?».

Для нейтрализации утечек на маршрутизаторе настраивается принудительный перехват (DNS Hijacking):

# Перенаправление всех запросов на 53 порт любого внешнего IP на локальный DNS узла
nft add table inet nat
nft add chain inet nat prerouting '{ type nat hook prerouting priority -100; }'
nft add rule inet nat prerouting udp dport 53 redirect to :53
nft add rule inet nat prerouting tcp dport 53 redirect to :53

# DoT (853/tcp) отклоняется сразу: клиент переходит на обычный DNS,
# а не ждёт таймаута
nft add rule inet autonomy_filter forward tcp dport 853 reject with tcp reset

Перехват обычного DNS (порт 53) прост; DoT отклоняется по порту; DoH по порту отличить от HTTPS нельзя, его можно ограничить только списком адресов известных резолверов, и полностью это не удаётся. Без интернета это не утечка, а задержка: клиент ждёт ответа резолвера, которого нет.

Чтобы детектор адаптивного портала счёл сеть исправной, нужны две службы. DNS не умеет отвечать кодом HTTP: он лишь возвращает адрес. Поэтому локальный резолвер (dnsmasq или unbound, тема 8) отвечает на имена проверочных узлов адресом шлюза, а на шлюзе работает HTTP-ответчик, который на /generate_204 отдаёт пустой ответ с кодом 204, а на страницу Apple — ожидаемую страницу «Success». Если ответчика нет, устройство пишет «сеть без доступа к интернету» — для автономного узла это честное сообщение, и многие операторы оставляют его. Если же нужна страница с правилами для гостей, ответчик отдаёт её вместо 204, и устройство само откроет окно портала. Обе ветки собираются в ЛР 11.

Обновления только из локального зеркала

Узел, не смотрящий наружу, обновляется только из своего зеркала пакетов с проверенной подписью (тема 7). На уровне сети это одно правило: машинам сегментов Work и Guest разрешено обращаться к зеркалу на сервере ядра по HTTP, но не наружу, даже если внешний канал временно появился; роутеры OpenWrt получают пакеты (apk в 25.x) из того же локального зеркала. Тогда появление канала связи не превращается в неконтролируемое обновление всех машин сразу, а обновление проходит тот же путь проверки подписи, что и в теме 7.

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

1. Преднамеренные помехи радиоканалу не рассматриваются: от них нет сетевой защиты, есть только провод там, где он возможен (раздел о проводной среде) и запасной канал (тема 10).
2. Модель не учитывает византийские отказы (англ. Byzantine faults) в mesh-сети: ситуацию, когда скомпрометированный или неисправный узел намеренно транслирует фиктивные сообщения OGM с максимально возможным TQ, затягивая весь транзитный трафик сети на себя («черная дыра» маршрутизации).
3. Модель протокола Syncthing предполагает достаточный объем дискового пространства на каждом принимающем узле: при исчерпании свободного места репликация блокируется для всей общей папки.
4. Сети с длительными разрывами связности (DTN, RFC 9171) не рассматриваются: при разрывах на часы и сутки TCP/IP неприменим, нужен перенос сообщений с хранением (тема 10).
5. net.py считает ошибки бит независимыми, цепочку mesh — однородной, а RTT — без ожидания канала и очередей; реальные значения хуже по задержке и могут быть лучше по потерям (пачки ошибок).
6. Падение напряжения PoE посчитано для холодного кабеля без разъёмов; при +40 °C сопротивление меди выше примерно на 8 %.

Итоги темы

Сеть автономного узла строится без провайдера, центрального шлюза и облачных служб. Провод там, где его можно проложить, надёжнее и экономнее радио; сегменты Core, Work и Guest с проверенной матрицей доступа защищают службы ядра от ошибок и от гостевых устройств. Питание сетевого оборудования от шины постоянного тока убирает лишние преобразования, но пассивный PoE от 12 В на десятках метров теряет заметную долю напряжения, и это считается, а не угадывается.

Mesh-сеть устраняет единую точку отказа, но платит полосой: в одной области конкуренции цепочка даёт C/N, в длинной цепочке — около C/3–C/4. Отказ соседа без потери несущей статическая маршрутизация не замечает; это делает только протокол, регулярно проверяющий соседей, и время восстановления у него — измеримая величина, а не обещание. Смена маршрута не рвёт TCP, пока адреса концов соединения не меняются.

Syncthing обнаруживает конфликт по векторам версий, а уступающую версию выбирает по времени изменения, поэтому часы узлов всё равно важны. Блоки фиксированного размера экономны для дописывания и расточительны для вставки. Синхронизация реплицирует и удаление, поэтому не заменяет резервную копию из темы 9.

Радиоканал как транспорт IP требует малого MTU, учёта RTT в секундах и осторожности с TCP: потеря кадра растёт с его длиной, а оптимальный MTU определяется BER. Детектор адаптивного портала удовлетворяется только HTTP-ответчиком, а не DNS. Обновления приходят только из локального зеркала, а роли машин и правила координации людей записываются заранее и проверяются учениями темы 13.

Литература

1. Perahia E., Stacey R. Next Generation Wireless LANs: 802.11n and 802.11ac. — 2nd ed. — Cambridge University Press, 2013.
2. RFC 7858. Specification for DNS over Transport Layer Security (TLS). — IETF, 2016. https://www.rfc-editor.org/rfc/rfc7858
3. IEEE Std 802.3bt-2018. IEEE Standard for Ethernet — Amendment 2: Physical Layer and Management Parameters for Power over Ethernet over 4 Pairs. — IEEE, 2019.
4. OpenWrt Documentation: Network configuration (UCI, DSA). — https://openwrt.org/docs/guide-user/network/dsa/dsa-mini-tutorial
5. Akyildiz I. F., Wang X. A survey on wireless mesh networks // IEEE Communications Magazine. — 2005. — Vol. 43, No. 9. — P. S23–S30.
6. Seither D., König A., Hollick M. Routing performance of Wireless Mesh Networks: A practical evaluation of BATMAN advanced // IEEE 36th Conference on Local Computer Networks (LCN). — IEEE, 2011.
7. IEEE Std 802.11s-2011. Amendment 10: Mesh Networking. — IEEE, 2011.
8. Syncthing Project. Block Exchange Protocol v1. — https://docs.syncthing.net/specs/bep-v1.html
9. Mattern F. Virtual Time and Global States of Distributed Systems // Parallel and Distributed Algorithms. — North-Holland, 1989. — P. 215–226.
10. Chacon S., Straub B. Pro Git. — 2nd ed. — Apress, 2014. https://git-scm.com/book
11. Beech W. A., Nielsen D. E., Taylor J. AX.25 Link Access Protocol for Amateur Packet Radio. Version 2.2. — Tucson Amateur Packet Radio (TAPR), 1998.
12. Fall K., Floyd S. Simulation-based Comparisons of Tahoe, Reno, and SACK TCP // ACM SIGCOMM Computer Communication Review. — 1996. — Vol. 26, No. 3. — P. 5–21.
13. RFC 6298. Computing TCP's Retransmission Timer. — IETF, 2011. https://www.rfc-editor.org/rfc/rfc6298
14. Syncthing Documentation. Understanding Synchronization (раздел Conflicting Changes). — https://docs.syncthing.net/users/syncing.html

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

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

1. Почему в стационарном периметре автономного узла использование экранированной витой пары (STP) предпочтительнее беспроводной сети Wi-Fi не только с точки зрения стабильности, но и с позиции радиомаскировки и энергопотребления?
2. Какие угрозы безопасности возникают при объединении всех устройств автономного узла в единое несегментированное адресное пространство (flat network)?
3. В чем разница между пассивным PoE (Passive PoE) и активными стандартами IEEE 802.3af/at? Почему на протяженных линиях напряжение 48 В эффективнее шины 12 В?
4. Почему централизованный маршрутизатор с протоколом DHCP и DNS в автономном узле является классической единой точкой отказа (SPOF)?
5. Каким образом в полудуплексной беспроводной mesh-сети на одном частотном канале происходит падение эффективной пропускной способности с ростом числа транзитных скачков (C/N)?
6. В чем состоит принципиальное различие между L2-маршрутизацией протокола batman-adv и L3-маршрутизацией протоколов OSPF или Babel?
7. Что такое метрика Transmit Quality (TQ) в протоколе batman-adv и каким образом узлы оценивают асимметрию радиоканала?
8. Почему в изолированном сегменте сети для работы утилиты Syncthing необходимо принудительно отключать механизмы Global Discovery и Relays?
9. Что такое Device ID в Syncthing и почему взаимная проверка сертификатов по Device ID защищает от подмены соседа? Что при этом остаётся на совести оператора (обмен ID по надёжному каналу)?
10. Как векторы версий (векторные часы Фиджа — Маттерна) отличают последовательные правки от параллельных и почему для этого не нужны общие часы? Почему Syncthing всё же смотрит на mtime при выборе конфликтной копии?
11. Почему Reno и CUBIC резко снижают скорость на зашумлённом радиоканале? Чем отличается реакция на три повторных подтверждения от реакции на истечение RTO?
12. Каким образом правило MSS Clamping на межсетевом экране предотвращает проблему «чёрных дыр Path MTU Discovery» при связи через узкополосные радиомодемы?
13. Почему синхронизация не заменяет резервную копию? Приведите сценарий, в котором Syncthing распространяет потерю данных на все узлы.
14. Почему локальный DNS не может удовлетворить детектор адаптивного портала и что для этого нужно? На каких портах работают DoT и DoH?
15. Почему статическая маршрутизация не замечает отказ соседа, у которого интерфейс остался поднят?

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

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

Управление сетевыми пространствами имен (ip netns)

# Создание нового сетевого пространства имен
ip netns add node_core

# Создание виртуальной пары интерфейсов и перемещение в netns
ip link add veth-core type veth peer name veth-router
ip link set veth-core netns node_core

# Назначение адреса и подъем интерфейса внутри пространства имен
ip netns exec node_core ip addr add 192.168.10.2/24 dev veth-core
ip netns exec node_core ip link set veth-core up
ip netns exec node_core ip link set lo up

# Выполнение команды внутри целевого пространства
ip netns exec node_core ping -c 3 192.168.10.1
ip netns exec node_core ip route add default via 192.168.10.1

# Удаление сетевого пространства
ip netns del node_core

Настройка протокола batman-adv (batctl)

# Загрузка модуля ядра
modprobe batman-adv

# Подключение физического Wi-Fi интерфейса к mesh-мосту bat0
batctl if add wlan0
ip link set up dev wlan0
ip link set up dev bat0

# Назначение IP-адреса на виртуальный L2-интерфейс
ip addr add 10.0.0.1/24 dev bat0

# Просмотр обнаруженных соседей и их качества линка (TQ)
batctl n
batctl o     # Таблица инициаторов (Originators) с метриками TQ
batctl tg    # Глобальная таблица трансляции MAC-адресов

Правила изоляции периметра и MSS Clamping (nftables)

# Принудительное ограничение MSS для радиоканала с MTU 256
nft add rule inet fw4 forward tcp flags syn tcp option maxseg size set 216

# Изоляция гостевого сегмента: запрет форвардинга из Guest в Core
nft add rule inet fw4 forward iifname "veth-guest" oifname "veth-core" drop

# Принудительный перехват DNS на локальный адрес шлюза
nft add rule inet fw4 prerouting iifname "veth-guest" udp dport 53 redirect to :53

Автономная настройка Syncthing CLI

# Просмотр собственного Device ID
syncthing cli config devices list

# Добавление соседа со статическим адресом (без глобального discovery)
syncthing cli config devices add --device-id "V7XQ4KM-..." --name "Node-Core" --addresses "tcp://10.0.0.1:22000"

# Отключение глобального обнаружения и релеев в конфигурации
syncthing cli config options global-announce-enabled set false
syncthing cli config options relays-enabled set false
syncthing cli config options local-announce-enabled set true

Что почитать и посмотреть

1. Akyildiz I. F., Wang X. Wireless Mesh Networks. — John Wiley & Sons, 2009. Фундаментальный академический труд по теории многоузловых ячеистых сетей: протоколы канального и сетевого уровней, метрики качества линков и математические модели затухания полосы при транзитных скачках.
2. OpenWrt User Guide: Firewall and Network Segmentation. Официальное руководство сообщества OpenWrt по настройке виртуальных сетей VLAN, зон безопасности и правил подсистемы фильтрации nftables.
3. Seither D., König A., Hollick M. Routing performance of Wireless Mesh Networks: A practical evaluation of BATMAN advanced (IEEE LCN, 2011). Экспериментальная оценка batman-adv на испытательной сети: пропускная способность и поведение маршрутизации при числе переходов больше одного.
4. Syncthing Project. Block Exchange Protocol v1 Specification. Официальное описание протокола BEP: структуры сообщений, криптографические алгоритмы TLS/mTLS, индексирование блоков и векторные часы версий файлов.
5. Beech W. A., Nielsen D. E., Taylor J. AX.25 Link Access Protocol for Amateur Packet Radio. Version 2.2. — TAPR, 1998. Спецификация канального уровня AX.25: формат кадра, адресация по позывным, режимы подтверждения.
6. Fall K. R., Stevens W. R. TCP/IP Illustrated, Volume 1: The Protocols. — 2nd ed. — Addison-Wesley, 2011. Классический учебник по сетевым протоколам: исчерпывающий разбор алгоритмов контроля перегрузки TCP, таймаутов повторной передачи и проблемы Path MTU Discovery.
7. Syncthing Documentation: Understanding Synchronization. https://docs.syncthing.net/users/syncing.html Раздел «Conflicting Changes»: какая версия становится конфликтной копией (более старый mtime, при равенстве — по Device ID) и как образуется имя копии.

Углубление

Очерк 1. Алгоритм B.A.T.M.A.N. V: разделение метрик линка и эвристики OGM

В исходной версии протокола batman-adv (алгоритм B.A.T.M.A.N. IV) метрика качества пути TQ вычислялась исключительно на основе подсчета успешно принятых служебных пакетов OGM. Этот подход обладал существенным недостатком: пакет OGM имеет минимальную длину (несколько десятков байт) и может успешно проскакивать через канал с высоким уровнем шума, тогда как полноразмерные прикладные кадры Ethernet (1500 байт) в этом же канале будут фатально разрушаться помехами. Кроме того, TQ не учитывал физическую скорость модуляции Wi-Fi линка: канал 1 Мбит/с с нулевыми потерями получал более высокий TQ, чем канал 54 Мбит/с с 5 % потерь.

В современном алгоритме B.A.T.M.A.N. V сбор метрик разделен на два независимых уровня:

1. Эвристика измерения линка (Link-Level Sensing, L2S): соседние узлы обмениваются направленными служебными эхо-сообщениями (ELP — Echo Location Protocol), непрерывно считывая у драйвера беспроводной карты реальную физическую скорость передачи (throughout) и уровень потерь. Метрика линка вычисляется в единицах микросекунд задержки на передачу эталонного пакета.
2. Маршрутизатор OGMv2: протокол распространяет вектор расстояний, суммируя затраты (metric cost) вдоль каждого пути. Лучшим маршрутом выбирается не путь с минимальным числом скачков, а путь с минимальным сквозным временем доставки полезных данных.

Очерк 2. От часов Лампорта к векторным часам

В теории распределенных систем невозможно синхронизировать физические часы разных машин с идеальной точностью без постоянного доступа к спутниковым сигналам GNSS или серверам атомного времени. Лесли Лампорт (1978) показал, что для упорядочения событий физическое время не требуется — достаточно отношения причинно-следственного предшествования (англ. happened-before relation, обозначается \to).

Если событие a породило событие b на одном узле, то a \to b. Если событие a — отправка сообщения, а b — его прием на другом узле, то a \to b.

Скалярные часы Лампорта гарантируют лишь, что из a → b следует C(a) < C(b), но по двум числам нельзя понять, были ли события параллельны. Векторные часы, независимо предложенные Фиджем и Маттерном (1988), сопоставляют каждому событию вектор целочисленных счетчиков V = (v_1, v_2, \dots, v_N) для системы из N узлов. Правила обновления:

1. Перед выполнением внутреннего события узел i увеличивает свой компонент вектора: V_i[i] = V_i[i] + 1.
2. При отправке сообщения узел прикрепляет текущее значение вектора V_i к телу сообщения.
3. При получении сообщения с вектором V_{msg} узел j обновляет каждый компонент своего вектора по правилу максимума: V_j[k] = \max(V_j[k], V_{msg}[k]), \quad \forall k \in \{1, \dots, N\} после чего увеличивает собственный счетчик V_j[j] = V_j[j] + 1.

Векторные часы гарантируют выполнение точного критерия: a \to b \iff (\forall k: V(a)[k] \le V(b)[k]) \land (\exists k: V(a)[k] < V(b)[k])

Если для двух версий файла A и B ни вектор V(A) не предшествует V(B), ни V(B) не предшествует V(A), события признаются конкурентными (параллельными: A \parallel B). Это условие позволяет Syncthing выявлять параллельное редактирование файла изолированными операторами и сохранять обе версии. Какая из них останется под исходным именем, вектор уже не решает: конфликтной копией становится версия с более старым временем изменения, а при равных mtime — версия устройства с большим Device ID.

Лабораторная работа 11. Сеть из нескольких узлов: сегменты, отказ соседа, синхронизация

• Раздел курса: тема 11 «Автономные сети и синхронизация»

Введение

В теории темы 11 сеть автономного узла собрана из сегментов с межсетевым экраном между ними, обходных путей на случай отказа узла и одноранговой синхронизации данных. Каждое из этих утверждений можно проверить на одном ноутбуке: сетевые пространства имён Linux (англ. network namespaces, netns) дают несколько независимых сетевых стеков — со своими интерфейсами, адресами, таблицами маршрутов и правилами nftables — внутри одной системы. Всё выполняется в пользовательской песочнице unshare -rnm, без sudo и без доступа к сети хоста.

Работа построена вокруг опытов, которые могут провалиться. Главный из них — отказ соседа. Выключить собственный интерфейс и увидеть, что трафик ушёл в обход, легко, но это не отказ mesh-узла: при выключении своего интерфейса ядро само снимает маршруты. Когда соседний узел зависает или обесточивается за радиомостом, несущая на своей стороне остаётся, интерфейс остаётся в состоянии UP, и статическая маршрутизация продолжает слать пакеты в пустоту. Заметить такой отказ может только механизм, который проверяет соседа — протокол маршрутизации или хотя бы монитор.

Второй опыт касается синхронизации. Конфликт — это не «файлы различаются», а «правки параллельны»: одностороннее изменение конфликтом не является. Отличить одно от другого позволяет вектор версий. Третий опыт показывает, почему синхронизация не заменяет резервную копию: удаление реплицируется так же исправно, как правка.

Сетевые числа работы — потери, время восстановления, матрица доступа — получаются на ядре Linux в момент запуска; синтетических данных в работе нет. Модель синхронизации sync_demo.py — учебная модель, а не Syncthing; там, где установлен настоящий Syncthing, тот же опыт повторяется на двух его экземплярах.

Цель работы

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

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

• поднять топологию из нескольких netns, соединённых парами veth, и объяснить выбор маршрута командой ip route get;
• построить матрицу доступа между сегментами до и после правил nftables и найти ошибку в правилах по этой матрице;
• объяснить, почему детектору captive portal нужен HTTP-ответчик, а не только DNS;
• воспроизвести отказ соседа при живой несущей (tc netem loss 100%) и показать, что статическая маршрутизация его не замечает;
• измерить время восстановления при обнаружении отказа по hello и метрике ETX и сравнить его с периодом hello и размером окна;
• по векторам версий отличить одностороннее изменение от параллельного и предсказать, какая версия станет конфликтной копией;
• показать, что удаление реплицируется, и восстановить файл из снимка.

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

Разделы теории: «Сегментация и межсетевой экран», «Отказ соседа и динамическая маршрутизация», «Векторы версий и конфликты Syncthing», «Синхронизация — не резервная копия», «Captive portal и DNS в изолированной сети».

Монитор соседа netlab.py monitor — не протокол маршрутизации. Он не обменивается маршрутами и управляет одним заранее известным маршрутом. Он показывает тот механизм, на котором стоят babel (RFC 8966), OLSR и batman-adv: hello, метрика качества, порог. Если установлен babeld, тот же опыт повторяется с настоящим протоколом (babel_branch.sh).

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

Обязательная часть (П0): ноутбук с Linux (Debian 13 «trixie» или Ubuntu 26.04 LTS; Windows — WSL2 с включёнными user namespaces). Пакеты: iproute2 (ip, tc), nftables, util-linux (unshare), iputils-ping, Python 3 без дополнительных модулей. Права root не нужны.

Необязательные пакеты: dnsmasq (часть 3, ответ DNS на имя детектора), syncthing версии 2.x (часть 5, настоящие экземпляры), babeld (часть 4, протокол маршрутизации). Без них соответствующие скрипты печатают SKIP: <причина> и завершаются успешно.

П1 и выше (продвинутая часть): виртуальная машина с модулем batman-adv или две платы с OpenWrt 25.x. В пользовательской песочнице и в WSL2 модули ядра не загружаются, поэтому batman-adv и 802.11s в обязательную часть не входят.

Архив окружения: lr-env.

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

mkdir -p ~/polygon/lr11 && cd ~/polygon/lr11
unzip ~/Загрузки/lr-env.zip
chmod +x *.sh *.py
./selftest.sh

Самопроверка selftest.sh проходит базовую часть во временном каталоге и проверяет, что опыты умеют провалиться; если она завершилась с ошибкой, окружение неисправно и результаты работы не будут ничего значить. Затем открывается песочница, в которой выполняются части 1–5:

unshare -rnm --propagation private bash
mount -t tmpfs none /run
mkdir -p /run/netns

Перед каждой командой опыта записывается предсказание в журнал (раздел «Журнал работы»), после — факт.

Часть 1. Топология из пяти пространств имён

Задание

1. Прочитайте up.sh и нарисуйте топологию: пять netns (core_ns, router_ns, work_ns, transit_ns, guest_ns), шесть линков, сервисный адрес 172.16.0.2 на work_ns.
2. Предсказание: каким интерфейсом и через какой шлюз core_ns пойдёт к 192.168.20.2 и к 172.16.0.2? Какой TTL придёт в ответе ping к 192.168.20.2 из core_ns и из router_ns?
3. Поднимите топологию и проверьте связность.

./up.sh
ip netns exec core_ns ip -br addr
ip -n core_ns route
./test_connectivity.sh
ip netns exec core_ns   ping -c 1 192.168.20.2 | grep ttl
ip netns exec router_ns ping -c 1 192.168.20.2 | grep ttl

4. Сломайте и почините: выключите пересылку на маршрутизаторе и повторите проверку связности; затем включите обратно.

ip netns exec router_ns sysctl -w net.ipv4.ip_forward=0
./test_connectivity.sh
ip netns exec router_ns sysctl -w net.ipv4.ip_forward=1

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

Все проверки test_connectivity.sh — OK; маршрут к 192.168.20.2 идёт через 192.168.10.1, к 172.16.0.2 — через прямой линк veth-cw. Ответ из core_ns приходит с TTL на единицу меньше, чем из router_ns: пакет прошёл маршрутизатор. При ip_forward=0 проверки, идущие через router_ns, падают, а прямой линк и transit_ns продолжают работать — это и есть способ локализовать отказ по матрице связности.

Часть 2. Сегменты и межсетевой экран

Задание

1. Предсказание: какие соединения из таблицы test_firewall.sh откроются в плоской сети (без правил)? Какие должны быть закрыты после firewall.nft?
2. Постройте матрицу без правил и с правилами.

./test_firewall.sh --flat
./test_firewall.sh
ip netns exec router_ns nft list ruleset

3. Сломайте: замените в копии правил policy drop на policy accept и найдите по матрице, что именно сломалось.

sed 's/policy drop/policy accept/' firewall.nft > broken.nft
./test_firewall.sh broken.nft
./test_firewall.sh

4. Объясните две строки матрицы, которые не относятся к доступу к сервисам: guest -> 8.8.8.8:53 (открыто) и guest -> 1.1.1.1:853 (закрыто). Почему перехват DNS-over-TLS на 853/tcp невозможен так же, как перехват обычного DNS, и почему DNS-over-HTTPS (443/tcp) по порту вообще не отличить от обычного HTTPS?

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

В плоской сети гость достаёт до порта 22 сервера и до рабочего места — это то, от чего защищает сегментация. С firewall.nft все строки — OK: гостю доступны только DNS, ответчик на 80 и вики на 8080 сервера Core. Запрос гостя к 8.8.8.8:53 попадает на сервер Core (DNAT), соединение на 853 сбрасывается сразу, а не по таймауту. С broken.nft матрица показывает FAIL в строках гостя: ошибка политики по умолчанию видна только при проверке закрытых направлений.

Часть 3. Captive portal и детектор подключения

Задание

1. Предсказание: что получит детектор Android, если локальный DNS отвечает на connectivitycheck.gstatic.com адресом сервера, но HTTP-сервера на сервере нет? Может ли DNS-резолвер сам вернуть «HTTP 204»?
2. Проверьте ответчик и (если есть dnsmasq) ответ DNS:

./captive_check.sh

3. Сломайте: остановите ответчик и повторите запрос.

kill "$(cat run/http_core.pid)"
ip netns exec guest_ns python3 netlab.py tcpcheck 192.168.10.2 80 && echo открыт || echo закрыт
./captive_check.sh

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

GET /generate_204 с гостевого сегмента возвращает 204. С dnsmasq имя детектора и имя wiki.polygon.internal разрешаются в 192.168.10.2 — в том числе при запросе к 8.8.8.8, благодаря перехвату из части 2. DNS возвращает только адрес; код ответа HTTP отдаёт HTTP-сервер. Без ответчика порт 80 закрыт, детектор сочтёт сеть «без интернета». Повторный запуск captive_check.sh поднимает ответчик снова.

Часть 4. Отказ соседа и восстановление маршрута

Задание

1. Прочитайте test_failover.sh: три части A, B, C.
2. Предсказание для части A: вернётся ли маршрут metric 100 после ip link set veth-cw up?
3. Предсказание для части B: на стороне соседа (work_ns) включается tc netem loss 100% — сосед «завис», но несущая есть. Какой интерфейс выберет core_ns во время отказа, какая доля зондов потеряется за 6 с, если отказ начался на второй секунде?
4. Предсказание для части C: монитор шлёт hello раз в 0,2 с, ждёт ответа 0,15 с, окно — 5 hello, маршрут снимается при ETX > 2 (то есть при доставке меньше половины hello в окне). Оцените время обнаружения отказа и длительность перерыва для зондов. Запишите расчёт.
5. Запустите опыт и сохраните журналы зондов.

./test_failover.sh
head run/dynamic.csv
cat run/monitor.log

6. Сломайте: тот же опыт без монитора.

./test_failover.sh --no-monitor

7. Измените параметры монитора (например, --interval 1 --window 10) в части C скрипта и повторите. Как меняется время восстановления? Чем платят за быстрое обнаружение (подумайте о радиоканале, где каждый hello занимает эфир)?
8. Если установлен babeld, выполните ./babel_branch.sh и сравните перерыв с монитором.

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

Часть A: после выключения своего интерфейса трафик ушёл через veth-ct, после включения — остался там: статический маршрут ядро удалило, а не отложило. Часть B: интерфейс veth-cw остаётся выбранным, зонды после начала отказа теряются до конца опыта (ends_ok=0) — статическая маршрутизация отказ соседа не замечает. Часть C: в журнале монитора есть строки DOWN и UP, перерыв (RECOVERY_S) меньше 3 с при отказе длительностью 5 с, после восстановления соседа прямой маршрут вернулся. Без монитора часть C проваливается: перерыв равен всей длительности отказа. Значение RECOVERY_S записывается в журнал как измерение на своей машине; оно зависит от параметров монитора, а не от «скорости сети».

Часть 5. Синхронизация: векторы версий, конфликт, удаление

Задание

1. Предсказания для sync_demo.py:
   • правка только на узле A и синхронизация — будет ли конфликт?
   • параллельные правки на A (mtime T₀ + 60 с) и на B (mtime T₀ + 120 с) — какая версия останется под исходным именем, какая станет конфликтной копией, чей ID будет в имени копии?
   • параллельные правки с одинаковым mtime — что решит?
   • удаление на A — что станет с файлом на B?
2. Запустите модель:

python3 sync_demo.py all --workdir ./sync
cat sync/concurrent/index_A.json
ls sync/concurrent/node_B/

3. Сломайте: сравнение по хешу содержимого вместо векторов версий (так работал прежний скрипт этой работы).

python3 sync_demo.py one-sided --naive --workdir ./sync_naive

4. Слейте конфликт вручную: объедините plan.md и конфликтную копию в узле A в один файл и объясните, почему автоматическое слияние текста здесь небезопасно.
5. Если установлен syncthing, повторите опыт на двух настоящих экземплярах (локальное обнаружение, глобальные серверы и ретрансляторы выключены):

./syncthing_netns.sh

6. Завершите работу:

./down.sh
exit

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

Одностороннее изменение даёт conflicts=0: вектор A доминирует, B молча обновляется. Параллельные правки дают конфликт; под исходным именем остаётся версия с более новым mtime (B), конфликтной копией становится версия A, и в имени копии стоит ID устройства A. При равных mtime конфликтной становится версия устройства с большим ID. Удаление на A удаляет файл на B (deleted_on_b=1), а восстановить его можно только из снимка, сделанного до синхронизации. В режиме --naive одностороннее изменение ошибочно объявлено конфликтом. С настоящим Syncthing результат конфликта сверяется с предсказанием модели; если он расходится, расхождение записывается вместе с версией Syncthing.

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

Графы «предсказание» заполняются до запуска команды, «факт» — после. Расхождение предсказания и факта разбирается письменно в графе «разбор».

Окружение для записи: версия ядра (uname -r), версия iproute2 (ip -V), версии syncthing, babeld, dnsmasq, если они использовались.

Продвинутая часть (П1, виртуальная машина)

1. В виртуальной машине с Debian 13 загрузите модуль mac80211_hwsim (три эмулируемых радиоинтерфейса) и batman-adv, объедините интерфейсы в bat0 и повторите часть 4: отказ соседа через tc netem на эмулируемом интерфейсе. Сравните время переключения с монитором, учитывая, что OGM batman-adv по умолчанию рассылается раз в секунду.
2. Поднимите на core_ns dnsmasq с DHCP для гостевого сегмента и получите адрес клиентом udhcpc или dhclient в guest_ns. Что произойдёт с клиентами, если сервер DHCP выключить на время, превышающее срок аренды?
3. Посчитайте python3 teacher/sim/net.py (из материалов курса) для своего радиоканала: при каком MTU потеря кадра падает ниже 10 % при BER, оценённой в теме 10?

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

1. Почему выключение собственного интерфейса — плохая модель отказа mesh-узла? Что именно делает ядро с маршрутами при ip link set ... down?
2. Почему статический маршрут не замечает отказ соседа при живой несущей? Какие физические ситуации дают такой отказ в автономном узле?
3. Как связаны период hello, размер окна и порог ETX с временем обнаружения отказа? Чем платят за быстрое обнаружение на радиоканале?
4. Чем монитор соседа из этой работы отличается от протокола маршрутизации? Чего он не умеет?
5. Почему матрицу доступа проверяют и по закрытым направлениям, а не только по открытым?
6. Почему DNS не может вернуть «HTTP 204»? Какие две службы нужны, чтобы детектор captive portal счёл сеть исправной?
7. Почему обычный DNS (53) перехватывается DNAT, а DNS-over-TLS (853) — нет? Что делает клиент, когда его соединение на 853 сброшено?
8. Чем вектор версий отличается от сравнения содержимого и от сравнения mtime? Почему сравнение по хешу объявляет конфликтом обычное обновление?
9. По какому правилу Syncthing выбирает версию, которая станет конфликтной копией? Что происходит при конфликте правки и удаления?
10. Почему синхронизация не заменяет резервную копию? Какой механизм Syncthing частично помогает и почему его недостаточно (тема 09)?
11. Почему batman-adv не входит в обязательную часть и что для него нужно?