Связанные одной сетью: почему «просто настроить VPN» между офисами больше не работает для бизнеса

Представьте стандартную ситуацию: компания растет, открываются новые филиалы в разных городах — от Иркутска до Казани. Чтобы сотрудники могли работать в единой цифровой среде, сисадмин настраивает Site-to-site VPN. Вроде бы все работает: базы 1С открываются, файлы копируются.

Но со временем начинаются необъяснимые проблемы. То в одном офисе внезапно «залипает» RDP-сессия, то в другом 1С запускается по 10 минут, то при кратковременном сбое связи у сотрудников филиала пропадает вообще весь интернет, включая внешние сайты. Местный провайдер божится, что с его стороны потерь нет, а перезагрузка роутера помогает лишь на время.

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

Четыре скрытые угрозы для распределенной сети: разбор кейсов

1. Конфликты маршрутизации и «петли» в сети

Когда сеть разрастается, статическая маршрутизация (прописывание путей вручную) становится бомбой замедленного действия. Достаточно одной опечатки или наложения подсетей, чтобы трафик ушел в никуда.

• →Как это выглядит на практике: В одном из филиалов Томска компьютеры внезапно потеряли доступ к ресурсам центрального дата-центра. Интернет есть, а рабочие сервисы недоступны.
• →В чем была причина: При диагностике мы обнаружили дублирующийся маршрут в подсети. Из-за некорректной настройки один и тот же сетевой путь транслировался через два разных маршрутизатора в городе. Трафик просто «заблудился».
• →Решение: Мы внедрили динамическую маршрутизацию на базе протоколов OSPF и BGP и жестко разграничили права с помощью фильтрации маршрутов. Статические маршруты были исключены, что устранило конфликт раз и навсегда. В другом похожем случае (сбой связки Wireguard + BGP) сеть упала из-за ошибки в параметре allowed address на туннеле — вместо локальной подсети там по ошибке указали подсеть другого филиала. Корректировка настроек мгновенно вернула офис к жизни.

2. «DNS-ловушка»: почему падение туннеля убивает весь интернет в филиале

Часто внутренние ресурсы компании завязаны на контроллер домена (Active Directory), который находится в головном офисе или в облаке. Роутеры в филиалах настроены так, чтобы отправлять все DNS-запросы на этот контроллер.

• →Как это выглядит на практике: Падает VPN-туннель до центрального офиса. Логично, что сотрудники теряют доступ к общей файловой помойке. Но почему у них перестает работать даже обычный поиск в Google и корпоративная почта на внешнем сервере?
• →В чем была причина: Поскольку туннель упал, роутер филиала не может достучаться до корпоративного DNS-сервера. Без этого он не способен преобразовать буквенные адреса сайтов (например, yandex.ru) в IP-адреса. Интернет фактически есть, но воспользоваться им сотрудники не могут, так как браузеры выдают ошибку разрешения имен.
• →Решение: Мы разработали и внедрили скрипт автоматизации через инструмент Netwatch на оборудовании MikroTik. Теперь при падении VPN-туннеля роутер в филиале мгновенно понимает, что связь с контроллером домена потеряна, и автоматически переключает DNS-серверы на публичные (Google, Yandex, Cloudflare). Как только туннель восстанавливается, система возвращает локальные настройки DNS. Всё это мы автоматизировали с помощью Ansible-плейбуков и распространили на всю филиальную сеть в нерабочее время.

3. Нестабильность туннелей и капризы провайдеров

Бизнес часто зависит от одного интернет-провайдера в регионе, который может блокировать определенные типы трафика, принудительно разрывать сессии или резать скорость VPN-протоколов.

• →Как это выглядит на практике: Скорость работы в 1С падает до критического минимума, базы постоянно «вылетают», а файлы скачиваются часами. При этом обычный тест скорости интернета показывает отличные результаты.
• →В чём была причина: Провайдеры на своих промежуточных узлах могут некорректно обрабатывать или даже блокировать трафик VPN (особенно L2TP/IPsec или PPTP). В других случаях из-за ограничений канала (например, при переходе на резервный LTE-модем) стандартный размер пакетов приводит к их потере.
• →Решение: Единого «идеального» протокола не существует — инфраструктура должна быть гибкой. В одном из кейсов в Красноярске мы заменили нестабильный L2TP/IPsec на OpenVPN, что полностью решило проблему регулярных разрывов. В другом случае в Улан-Удэ замена PPTP на L2TP подняла скорость в туннеле с ничтожных 30 Кбит/с до стабильных 20 Мбит/с. А для филиала в Иркутске мы решили проблему медленной работы сети тонкой настройкой параметров туннеля — снизили показатель MTU до 1418, убрав потерю пакетов на стороне провайдера.

4. Резервные каналы связи: почему недостаточно просто «воткнуть модем»

Для непрерывности бизнеса критически важно иметь резервный канал связи (например, 4G/LTE-модем), который подстрахует при аварии у основного провайдера. Но без правильной настройки резервный канал либо не включится вовремя, либо создаст петли маршрутизации.

• →Как это выглядит на практике: При падении основного провайдера резервный модем работает, но трафик не идёт, либо в сети возникают дублирующиеся маршруты, ломающие доступ к серверам.
• →В чём была причина: Некорректная настройка таблиц маршрутизации (VRF) и отсутствие маркировки трафика (Mangle). Роутер пытается одновременно отправлять пакеты через оба канала, что приводит к хаосу в сети. В некоторых случаях резервный модем может банально не определиться системой из-за аппаратной несовместимости прошивок или нехватки питания по USB-порту.
• →Решение: Для стабильного переключения каналов мы настраиваем таблицы VRF, маркируем трафик через правила Mangle в MikroTik и жестко разграничиваем приоритеты (distance) в таблице маршрутизации. При аварии основного канала роутер автоматически перенаправляет VPN-туннель на резервный интерфейс. Кроме того, мы тщательно подбираем совместимые модели модемов (например, Brovi E3372-325) и адаптируем настройки питания портов.