Объединить филиалы - не значит один раз поднять VPN между маршрутизаторами. Туннель может быть активен, а сотрудники все равно потеряют 1С, файлы или телефонию из-за неверного маршрута, DNS, MTU, асимметрии трафика либо отказа центральной площадки. Поэтому филиальную сеть проектируют как систему доставки конкретных сервисов с заранее описанными отказами.
Начните с сервисов и потоков, а не с модели маршрутизатора
До выбора протокола и оборудования нужно записать, что именно проходит между площадками. Формулировка «филиалу нужен доступ в Москву» слишком общая: она не показывает направление соединения, допустимую задержку, владельца сервиса и последствия сбоя.
| Сценарий | Необходимый поток | Что важно проверить |
|---|---|---|
| Работа в 1С или RDS | Клиент филиала обращается к центральному приложению | Задержка, потери, DNS, время и поведение при переключении канала |
| Общий файловый ресурс | Пользователь открывает и изменяет файлы на сервере | Объем операций, блокировки файлов и пригодность SMB для фактического WAN-канала |
| IP-телефония | Телефон или шлюз обращается к АТС | Задержка, jitter, потери и сохранение регистрации после смены маршрута |
| Техническое управление | Мониторинг и администраторы обращаются к оборудованию | Отдельные источники доступа, журналирование и аварийный канал |
| Интернет и SaaS | Трафик идет напрямую либо через центральный узел | Что продолжит работать при недоступности VPN или центральной площадки |
После такой карты видно, какие потоки действительно должны пересекать VPN, а какие разумнее оставить локальными. Передавать весь интернет каждого филиала через один центральный офис иногда оправданно политикой безопасности, но это одновременно превращает центральный канал и шлюз в общую точку отказа.
Три базовые топологии
| Модель | Когда подходит | Главное ограничение |
|---|---|---|
| Hub-and-spoke | Основные серверы находятся в одном центре, филиалы редко общаются напрямую | Центральный узел принимает весь межфилиальный трафик и требует резервирования |
| Прямые связи между отдельными площадками | Есть значимый обмен между конкретными филиалами или резервными центрами | Число туннелей, маршрутов и правил быстро растет |
| Гибридная схема | Внутренние сервисы доступны через центр, а интернет и SaaS выходят локально | Нужны единые политики DNS, защиты конечных устройств и контроля доступа |
Полная mesh-топология редко нужна небольшой компании. Она выглядит отказоустойчивой, но добавляет много связей и неоднозначных маршрутов. Обычно разумнее определить центральный путь, несколько действительно необходимых прямых связей и отдельный порядок работы при потере центра.
Адресный план нужно согласовать до соединения площадок
Частая проблема возникает, когда несколько офисов годами используют одинаковую подсеть, например один и тот же диапазон для рабочих мест. Пока площадки изолированы, это незаметно. После соединения маршрутизатор не понимает, в какой филиал отправлять одинаковый адрес.
Диапазоны RFC 1918 предназначены для частных сетей, но не гарантируют уникальность внутри конкретной компании. Для распределенной инфраструктуры нужен собственный план: отдельный блок на площадку, запас для серверов, пользователей, телефонии, камер, гостей и управления, а также возможность агрегировать маршруты. NAT между пересекающимися сетями может временно восстановить связь, но усложняет журналы, диагностику, правила и приложения, которые передают адреса внутри протокола. Это обход, а не хороший постоянный фундамент.
Резервный канал не равен проверенному резервированию
Второй провайдер или LTE-модем приносит пользу только после проверки всей цепочки переключения. Нужно определить, кто обнаруживает отказ, когда меняется маршрут, как перестраивается VPN, сохраняется ли обратный путь и возвращается ли трафик на основной канал после восстановления.
- Основной и резервный каналы желательно разводить не только по договорам, но и по физической среде, вводу в здание и питанию, насколько это возможно.
- Проверка доступности должна контролировать значимый путь, а не только ближайший шлюз провайдера.
- Приоритеты маршрутов и условия возврата должны исключать постоянное переключение туда-сюда при нестабильном канале.
- Пропускной способности резерва должно хватать хотя бы для заранее выбранных критичных сервисов.
- Тест проводят с обеих сторон: установленный туннель еще не доказывает корректный обратный маршрут.
Скрытые зависимости: DNS, время, MTU и состояние соединений
Многие «проблемы VPN» на самом деле находятся рядом с ним.
| Зависимость | Как проявляется ошибка | Что должно быть определено |
|---|---|---|
| DNS | По IP сервис открывается, по имени - нет или открывается не тот узел | Какие зоны внутренние, где находятся резолверы и что происходит без центра |
| Синхронизация времени | Ошибки аутентификации, сертификатов и журналов | Иерархия источников времени и контроль расхождения |
| MTU и фрагментация | Небольшие запросы проходят, загрузка файлов и отдельные сайты зависают | Допустимый размер пакета по фактическому пути и поведение PMTUD |
| Асимметричная маршрутизация | Запрос уходит одним шлюзом, ответ приходит другим и отбрасывается | Согласованный прямой и обратный путь, особенно при двух провайдерах |
| Stateful firewall и NAT | После переключения старые сессии не восстанавливаются автоматически | Ожидаемое время переподключения приложений и очистки состояния |
VPN дает связность, но не должен выдавать полное доверие
Площадка не становится безопасной только потому, что она «внутренняя». Между сегментами нужно разрешать конкретные потоки: например, пользователям доступ к приложению, телефонам к АТС, камерам к регистратору, а управлению оборудованием - только с административных узлов. Компрометация одного рабочего места не должна автоматически открывать все серверы и остальные филиалы.
NIST в архитектуре Zero Trust отдельно указывает, что сетевое расположение само по себе не является основанием для доверия. Для небольшой компании это не требует покупки отдельного продукта: принцип можно применять через идентификацию пользователей и устройств, минимальные правила между сегментами, MFA для внешнего доступа и раздельный административный контур.
Какие функции оставить в филиале
Не каждый сервис нужно централизовать. Решение зависит от того, должен ли офис продолжать работу при потере связи.
| Функция | Возможный локальный слой | Вопрос при отказе WAN |
|---|---|---|
| DHCP | Локальная выдача адресов на шлюзе или сервере | Смогут ли новые устройства подключиться без центра |
| DNS | Локальный кэширующий резолвер с понятными upstream | Будут ли доступны интернет и локальные имена |
| Печать и локальные устройства | Прямой локальный путь без поездки трафика через центр | Сохраняется ли базовая офисная работа |
| Файлы и приложения | Центральный сервис, реплика или публикация приложения | Допустим ли простой и как исключаются конфликты данных |
| Телефония | Локальный шлюз или аварийный маршрут | Можно ли совершить критичный звонок без центральной АТС |
Локальная копия данных не всегда повышает надежность: двусторонняя синхронизация может создать конфликты и распространить повреждение. Ее внедряют только с понятной моделью владельца, разрешения конфликтов, защиты и восстановления.
Наблюдаемость должна повторять путь пользователя
Одного индикатора «туннель up» недостаточно. Полезный мониторинг разделяет уровни:
- доступность и состояние каждого внешнего канала;
- состояние туннеля и смена активного маршрута;
- задержка, потери и jitter до значимых точек;
- работа DNS и синхронизации времени;
- доступность прикладного сервиса из конкретного филиала;
- запас пропускной способности и ошибки интерфейсов;
- события изменения конфигурации и повторяющиеся переключения.
Если мониторинг видит только центральное оборудование, он может показывать зеленый статус в момент, когда пользователи конкретного филиала уже не работают.
Матрица отказов
| Событие | Ожидаемое поведение | Доказательство |
|---|---|---|
| Отказ основного провайдера филиала | Критичные сервисы переходят на резерв в согласованное время | Замер переключения и журнал изменения маршрута |
| Недоступность центрального VPN-шлюза | Срабатывает второй узел либо филиал переходит в ограниченный автономный режим | Проверка сервисов, которые должны сохраниться |
| Отказ внутреннего DNS | Определен набор работающих и неработающих сценариев, есть контролируемый обход | Тест разрешения внутренних и внешних имен |
| Пересечение подсетей после подключения новой площадки | Площадка не вводится в эксплуатацию до устранения конфликта | Проверка адресного реестра и таблиц маршрутизации |
| Резервный канал заметно медленнее | Некритичный трафик ограничивается, приоритет получают рабочие сервисы | Тест под нагрузкой, а не только ping |
Обезличенный пример рабочей схемы
Компания имеет центральную площадку с серверами и несколько филиалов. Каждый филиал получает уникальный адресный блок и локальные сегменты пользователей, телефонии, гостей и управления. Внутренние сервисы идут по двум site-to-site путям к паре центральных шлюзов, интернет и SaaS выходят локально. На резервном мобильном канале разрешены только критичные приложения и управление. DNS, время, маршруты и пользовательский сценарий 1С проверяются из каждого филиала. Изменения хранятся вместе со схемой, таблицей потоков и процедурой отката.
В этой модели нет требования использовать определенного производителя. Ее качество определяется тем, можно ли объяснить каждый маршрут, воспроизвести отказ и получить ожидаемый результат.
Что принять перед запуском
- утвержденная схема площадок, сегментов, адресов и шлюзов;
- таблица разрешенных потоков с владельцами сервисов;
- отсутствие пересекающихся подсетей либо документированный временный план миграции;
- результаты тестов основного и резервного каналов;
- проверка DNS, времени, MTU и прикладных сценариев;
- мониторинг каждой площадки с понятными адресатами уведомлений;
- резервные копии конфигураций и проверяемый порядок отката;
- описание ограниченного режима работы при потере центральной площадки.
Первичные источники
- RFC 1918: Address Allocation for Private Internets
- NIST SP 800-207: Zero Trust Architecture
- CISA #StopRansomware Guide: сегментация и документирование сети
При обслуживании сети, Wi-Fi и VPN такую схему важно поддерживать после каждого нового филиала, провайдера или сервиса. Иначе первоначально аккуратная архитектура постепенно превращается в набор исключений.
Итог: управляемая филиальная сеть - это не коллекция VPN-туннелей, а согласованная модель сервисов, адресов, маршрутов, доверия и отказов. Ее надежность подтверждается не зеленым статусом интерфейса, а воспроизводимыми проверками работы бизнеса при нормальном режиме и при сбоях.