VPN_DEFAULT_GW_ROUTING_LEAK Сетевое оборудование и VPN

Настройка маршрутизации трафика филиалов через центральный офис (Default Gateway via VPN)

Обновлено: 25.08.2026 · Официальная документация ↗

Интернет-трафик пользователей филиала уходит напрямую через локального провайдера в обход корпоративных политик безопасности (DLP/NGFW).
Утечка DNS-запросов (DNS Leak) мимо корпоративного DNS-сервера в центральном офисе.
Падение туннеля VPN сразу после добавления статического маршрута 0.0.0.0/0 через туннельный шлюз (рекурсивный блэкхол).
Ошибки сегментации TCP-сессий (MTU/MSS Blackhole) при открытии сайтов через центральный шлюз.

1. Предотвращение падения VPN при установке Default Gateway

При перенаправлении маршрута по умолчанию 0.0.0.0/0 через туннель сам маршрутизатор теряет маршрут к внешнему IP-адресу VPN-сервера HQ. Для решения этой проблемы создается явно заданный маршрут типа Host Route (/32) до внешнего адреса шлюза HQ через локального провайдера.

2. Конфигурация MikroTik RouterOS v7 (WireGuard / IPIP over IPsec)

# 1. Задаем специфичный маршрут до внешнего адреса центрального офиса
/ip route
add dst-address=203.0.113.1/32 gateway=198.51.100.1 comment="Host route to HQ VPN Server"

# 2. Создаем отдельную таблицу маршрутизации для клиентов LAN
/routing table add name=to-hq-vpn fib

# 3. Добавляем шлюз по умолчанию в кастомную таблицу через туннельный интерфейс
/ip route
add dst-address=0.0.0.0/0 gateway=wg-hq-tunnel routing-table=to-hq-vpn

# 4. Направляем трафик локальной сети филиала в таблицу to-hq-vpn
/routing rule
add src-address=192.168.10.0/24 action=lookup-only-in-table table=to-hq-vpn

# 5. Корректировка MSS для предотвращения фрагментации
/ip firewall mangle
add chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp tcp-mss=1361-65535

3. Конфигурация центрального маршрутизатора (HQ / Hub)

# Разрешаем NAT для подсети филиала на внешнем интерфейсе HQ
/ip firewall nat
add chain=srcnat src-address=192.168.10.0/24 out-interface=ether1-wan action=masquerade comment="NAT for Branch Traffic"

4. Проверка прохождения трафика

/tool traceroute address=8.8.8.8 src-address=192.168.10.1

💡 Практика специалистов: При маршрутизации всего трафика через головной офис накладывается двойная нагрузка на канал HQ (входящий трафик из туннеля и исходящий в интернет). Рассчитывайте ширину канала центрального офиса с запасом x2 относительно суммарной полосы филиалов.

Частые вопросы (FAQ)

Почему при добавлении маршрута 0.0.0.0/0 через VPN сразу падает сам туннель?

Потому что пакеты инициализации и поддержания самого VPN-соединения (UDP 500/4500 или WireGuard) начинают маршрутизироваться внутрь еще не поднявшегося туннеля. Требуется создать жесткий хостовый маршрут /32 до публичного IP-адреса VPN-сервера через физический шлюз провайдера.

Как избежать фрагментации пакетов внутри туннеля?

Используйте механизм Clamp-MSS-to-PMTU в таблице firewall mangle или жестко зафиксируйте MSS (например, 1360 байт для WireGuard и 1380 байт для IPsec IKEv2).

Как предотвратить утечку локального трафика при падении VPN?

В правилах Policy-Based Routing (Routing Rules) укажите действие lookup-only-in-table вместо lookup. Если таблица VPN недоступна, трафик будет сброшен, а не отправлен через основной шлюз локального провайдера.

Как направить через центральный офис только трафик определенных ПК?

Сформируйте Address List с нужными IP-адресами и привяжите правило /routing rule или Mangle mark-routing исключительно к этому списку источников.