Связность магазинов, складов и офиса: сеть без единой точки отказа

Связность начинается с автономности площадки

У магазина, склада и офиса разные последствия потери связи. В магазине могут остановиться облачная кассовая система, эквайринг, проверка цен или обмен с учётной системой. На складе критичны терминалы сбора данных, печать этикеток и задания WMS. Офис чаще концентрирует каталоги, ERP, телефонию и администрирование. Поэтому одна схема «два провайдера везде» не отвечает на главный вопрос: какие операции должны продолжаться при каждом типе отказа.

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

Связность — это цепочка: питание, операторский ввод, маршрутизатор, туннель, DNS, межсетевые правила, целевой сервис и его база. Мониторинг только ICMP до роутера показывает малую часть. Архитектура должна различать отказ локальной линии, туннеля, центральной площадки и приложения, чтобы дежурный не переключал канал там, где недоступен сервер.

• Определить минимальный набор операций каждой площадки в автономном режиме.
• Разделить зависимости от интернета, VPN и центральных приложений.
• Не считать два тарифа резервом, пока не проверены независимые трассы и питание.
• Назначить владельца бизнес-проверки после технического переключения.

Топология: звезда, прямые туннели или SD-WAN

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

Прямые туннели между каждой парой площадок сокращают путь, но количество связей и правил растёт примерно квадратично. Для десятков точек ручное управление становится источником дрейфа. Динамическая маршрутизация поверх защищённых туннелей или SD-WAN может упростить выбор пути и application-aware policy, однако добавляет требования к компетенциям, лицензиям и контроллеру.

Разумный компромисс часто выглядит как hub-and-spoke для внутренних систем и локальный выход в интернет для SaaS, обновлений и гостевого трафика. Доступ к облачным сервисам защищается их механизмами идентичности и фильтрацией площадки. Решение о полном или локальном выходе принимают после измерения потоков, требований к фильтрации и оценки пропускной способности центральных каналов.

Адресный план и сегменты торговой точки

Пересекающиеся подсети — одна из самых дорогих мелочей при объединении площадок. Если каждый подрядчик устанавливал 192.168.1.0/24, маршрутизация требует NAT-костылей, а диагностика становится неоднозначной. Адресный план резервирует блок на площадку и кодирует назначение сегмента одинаковым способом. Запас адресов оставляют заранее, но не раздают филиалу чрезмерно широкую сеть.

Внутри магазина отделяют кассы и платёжную инфраструктуру в соответствии с документацией поставщиков, корпоративные рабочие места, терминалы и принтеры, видеонаблюдение, телефонию, управление и гостевой Wi‑Fi. На складе отдельно рассматривают ТСД, точки доступа, автоматику и WMS. Сам факт VLAN не ограничивает трафик: на маршрутизаторе или межсетевом экране задают разрешённые направления.

Управление MikroTik, коммутаторами и точками доступа доступно только из административной зоны или через защищённый jump host. Winbox, SSH и веб-интерфейс не публикуют в интернет. Список разрешённых source-адресов дополняет, но не заменяет персональные учётные записи, сильную аутентификацию, обновления RouterOS и резервные копии конфигурации.

VPN и маршрутизация без скрытой асимметрии

WireGuard и IPsec могут построить надёжные туннели, но выбор протокола не исправляет плохую маршрутизацию. Для каждого направления нужно понимать, какой узел объявляет сеть, где применяется NAT, какой MTU доступен и что произойдёт при появлении второго пути. Асимметричный маршрут может проходить в одну сторону и блокироваться stateful firewall в обратную.

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

MTU проверяют прикладным тестом, особенно поверх PPPoE, LTE и нескольких уровней инкапсуляции. Маленькие пакеты ping могут проходить, а TLS-сессии или передача файлов зависать. MSS clamping применяют осознанно после диагностики. DNS также проектируют для аварии: филиал должен разрешать необходимые имена при потере одного концентратора, а split DNS не должен указывать на недоступный адрес.

1. Назначить непересекающиеся подсети и перечень разрешённых префиксов для каждой площадки.
2. Поднять туннель с минимальными маршрутами и без широкого NAT между внутренними сетями.
3. Проверить направление инициирования, stateful-правила и обратный маршрут.
4. Измерить доступный MTU и протестировать крупную HTTPS-передачу, ERP и печать.
5. Добавить резервный путь с худшей метрикой или управляемой политикой выбора.
6. Имитировать отказ основного канала и убедиться, что маршрут отозван, а сессии восстанавливаются ожидаемо.
7. Зафиксировать фактические маршруты, параметры туннеля и команды диагностики.

Резервирование: канал, устройство и питание

LTE-модем рядом с основным маршрутизатором — полезный резерв, но не гарантия. Оба канала могут зависеть от одного электропитания, кабельного коллектора или базовой станции с перегруженным транспортом. Для критичных точек выясняют физическую независимость вводов и проверяют резерв под рабочей нагрузкой. Объём тарифа, CGNAT, входящие соединения и изменяющийся адрес учитывают до аварии.

Переключение по ping одного публичного адреса даёт ложные решения: адрес может не отвечать, хотя интернет работает, или отвечать через шлюз оператора при обрыве дальше. Используют несколько независимых целей и проверку необходимого сервиса. На RouterOS рекурсивная маршрутизация, check-gateway или сценарии автоматизации требуют защиты от дребезга и понятного возврата на основной канал.

Два канала через один маршрутизатор не защищают от отказа устройства. Пара маршрутизаторов повышает доступность, но усложняет состояние VPN, NAT, DHCP и протокол первого перехода. Иногда быстрее держать настроенный запасной маршрутизатор и документированную замену. Выбор определяется допустимым временем восстановления, наличием персонала на точке и стоимостью простоя, а не максимальной сложностью.

• ИБП рассчитан на маршрутизатор, терминал оператора, коммутаторы и точки доступа, необходимые для процесса.
• LTE-антенна и уровень сигнала проверены в часы нагрузки.
• Резервный тариф не заблокирован и имеет контролируемый лимит.
• VPN автоматически поднимается через резервный адрес без ручной правки peer.
• Возврат на основной канал не создаёт циклических переключений.
• Запасная конфигурация и версия RouterOS совместимы с резервным оборудованием.

Мониторинг от физического порта до бизнес-сценария

Хорошая панель отвечает, где нарушилась цепочка. Для WAN собирают доступность шлюза и внешних целей, задержку, потери, jitter, загрузку и состояние LTE. Для VPN — handshake, число маршрутов и доступность адреса внутри удалённой сети. Для оборудования — CPU, память, температура, ошибки интерфейсов, питание и изменения конфигурации. Для сервиса — DNS, TCP-порт и короткая безопасная транзакция.

Опрос только из центрального офиса создаёт слепую зону: при разрыве VPN мониторинг объявит недоступным всё, хотя локальный интернет магазина работает. Локальный агент или внешняя точка наблюдения позволяет различить эти случаи. С другой стороны, агент на каждой площадке требует обновлений и защиты. Выбирают минимальный набор, который меняет действия дежурного.

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

Эксплуатация MikroTik и проверка аварий

Конфигурации площадок должны собираться из стандарта, но не быть бездумными копиями. Шаблон задаёт имена интерфейсов, firewall baseline, NTP, DNS, журналирование, пользователей, мониторинг и резервирование. Переменные площадки — адреса, провайдеры, туннельные ключи и локальные зависимости — хранят отдельно. Экспорт без чувствительных данных удобен для сравнения, а бинарный backup полезен для восстановления на совместимом оборудовании; это разные артефакты.

Обновления RouterOS сначала проверяют на стенде или ограниченной группе. Читают release notes, проверяют совместимость VPN, routing и CAPsMAN, создают копию и план возврата. Одновременное обновление всех площадок превращает единичную несовместимость в массовый простой. RouterBOOT и пакеты также учитывают в политике версий.

Аварийные учения проводят регулярно и безопасно: отключают основной WAN в согласованное окно, наблюдают смену маршрута, проверяют кассовый или складской сценарий и возврат. Затем моделируют недоступность hub, а не только кабеля филиала. Результаты измеряют фактически, не обещая универсального времени переключения: активные TCP-сессии могут оборваться даже при быстром изменении маршрута.

1. Сверить текущую конфигурацию с утверждённым шаблоном и убрать неиспользуемые сервисы.
2. Создать экспорт и backup, проверить доступ к консоли или резервному управлению.
3. Отключить основной канал и зафиксировать время обнаружения и смены маршрута.
4. Выполнить реальную безопасную операцию магазина или склада через резерв.
5. Восстановить основной канал и убедиться в стабильном возврате без flapping.
6. Проверить отказ центрального VPN-узла и переход ко второму, если он предусмотрен.
7. Обновить инструкцию, пороги мониторинга и план ёмкости по результатам.