Обновлено: 27.01.2026
Ситуация
В компании с распределённой сетью (головной офис + несколько филиалов) произошёл плановый переезд сетевого оборудования. Головной маршрутизатор MikroTik RB1100Dx4, к которому подключались все филиалы через VPN и IPIP-туннели, был физически перемещён на другую площадку.
- публичные IP-адреса изменились;
- резервный канал был подключён к новому провайдеру;
- филиальные маршрутизаторы остались на старых адресах.
Для «упрощения» настройки один из подрядчиков применил MikroTik QuickSet. И именно здесь начались проблемы.
Что пошло не так
QuickSet — удобный инструмент для домашнего интернета, но в корпоративной сети он опасен, потому что перезаписывает интерфейсы/адреса/правила под типовые сценарии, не учитывая вашу архитектуру.
После автоматической перенастройки
- публичные IP-адреса были назначены не тем интерфейсам;
- один из WAN-адресов оказался в LAN-бридже;
- IPIP-туннели начали «смотреть в самого себя»;
- в firewall и NAT остались старые IP;
- маршруты и policy routing указывали на несуществующие шлюзы.
Итог для бизнеса
- филиалы потеряли связь с головным офисом;
- RemoteApp и RDP перестали работать;
- часть сервисов оказалась недоступна.
В таких случаях «перезагрузить и посмотреть» — плохая стратегия. Нужна восстановленная логика маршрутизации и доступов.
Почему такие аварии опасны
В распределённой инфраструктуре (офисы, кассы, IP-телефония, терминалы, RDP-доступ) отказ головного узла приводит к:
- остановке работы филиалов;
- сбоям в учёте и 1С;
- невозможности подключиться удалённо;
- риску потери данных.
Важно
В таком состоянии сеть нельзя «пощёлкать» или «перегрузить». Нужен инженер, который понимает маршрутизацию, VPN, NAT и failover.
Что было сделано
Мы восстановили архитектуру корпоративной сети по шагам — так, чтобы не потерять удалённый доступ в процессе.
1) Правильно разделили WAN и LAN
- убрали публичные IP с bridge-интерфейсов;
- привели WAN-интерфейсы к чистой схеме: основной провайдер + резервный провайдер;
- проверили, что LAN-сегменты не смешиваются с внешними адресами.
2) Настроили резервный канал связи (сначала)
Перед тем как исправлять основной трафик, мы подняли и проверили резервный доступ:
- подключили резервного провайдера;
- настроили NAT;
- проверили выход в интернет через него;
- обеспечили безопасный удалённый доступ.
Это позволило выполнять остальные работы без риска потерять связь.
3) Исправили VPN и IPIP-туннели
Привели в порядок туннели и маршруты так, чтобы филиалы гарантированно подключались к HQ.
- IPIP-туннели между HQ и филиалом (Volvo6);
- L2TP-подключения офисов;
- резервные маршруты и сценарии переключения.
Теперь:
- филиалы всегда подключаются к головному офису по новым публичным IP;
- при падении одного канала автоматически используется второй.
4) Привели NAT и firewall к реальной схеме
Мы убрали привязки к старым IP и сделали:
- корректные правила по
dst-address-list=WAN(вместо «жёстко прошитых» адресов); - безопасный доступ к RDP, IP-телефонии, RemoteApp;
- правильную маршрутизацию между офисами.
Результат
- филиалы снова видят головной офис;
- RemoteApp и RDP работают;
- IP-телефония восстановлена;
- резервный канал готов к автоматическому переключению;
- инфраструктура больше не зависит от QuickSet.
Вывод
MikroTik — мощный инструмент, но корпоративные сети нельзя настраивать QuickSet-ом.
Если у вас несколько офисов, VPN-туннели, кассы/телефония/1С/RDP и резервные интернет-каналы — нужна инженерная настройка, а не «домашний мастер».
Услуги, которые помогают в таких кейсах
- Восстановление сети после аварии — когда VPN, RDP, филиалы или интернет перестали работать.
- Настройка MikroTik под корпоративную сеть — RB1100/RB3011/RB4011/hAP/CCR.
- VPN между офисами — L2TP, IPIP, SSTP и др.
- Резервирование интернет-каналов — чтобы бизнес не вставал из-за одного провайдера.
Связаться: sa2002.ru · denis@sa2002.ru