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

Траблшутинг маршрутизации в Hub-and-Spoke VPN: запрет и фильтрация транзита

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

Филиалы (Spokes) имеют доступ к ресурсам Центрального Офиса (Hub), но связь между филиалами (Spoke-to-Spoke) отсутствует.
Пакеты между удаленными офисами сбрасываются межсетевым экраном Центрального шлюза (Drop: U-Turn / Hairpinning traffic).
Петли маршрутизации в динамических протоколах (BGP/OSPF), приводящие к 100% утилизации CPU на Hub-роутере.
Ошибки в Cisco ASA: Deny IP-spoofing / Reverse Path Forwarding (uRPF) interface check failed.

1. Диагностика причин блокировки транзитного трафика

В классической топологии Hub-and-Spoke маршрутизатор Hub получает пакет от одного филиала через интерфейс туннеля и должен отправить его обратно через тот же самый физический или логический интерфейс к другому филиалу (Intra-Interface Routing / Hairpinning). По умолчанию многие фаерволы (Cisco ASA, FortiGate, Linux iptables) блокируют такой транзит из соображений безопасности.

2. Разрешение Intra-Interface транзита на Cisco ASA

! Разрешение перенаправления трафика внутри одного интерфейса
same-security-traffic permit intra-interface
same-security-traffic permit inter-interface

! Отключение строгого uRPF на VPN-интерфейсе при необходимости
no ip verify reverse-path interface outside

3. Настройка BGP / OSPF на Hub-роутере (Cisco IOS)

Для корректной маршрутизации филиалов через Hub без прямого Spoke-to-Spoke Dynamic туннеля:

router bgp 65000
 neighbor SPOKES peer-group
 neighbor SPOKES remote-as 65000
 neighbor 10.255.0.2 peer-group SPOKES
 neighbor 10.255.0.3 peer-group SPOKES
 !
 address-family ipv4
  ! Принудительное назначение Hub следующим переходом для всех Spoke сетей
  neighbor SPOKES next-hop-self
  neighbor SPOKES route-reflector-client
 exit-address-family

4. Настройка политик фильтрации Spoke-to-Spoke на Linux Hub (iptables/nftables)

Если транзит между определенными филиалами должен быть строго запрещен (сегментация безопасности):

# Запрет связи между филиалом 1 (10.10.0.0/24) и филиалом 2 (10.20.0.0/24)
iptables -I FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j DROP
iptables -I FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j DROP

# Разрешение только доступа к ресурсам центрального ЦОД (192.168.0.0/16)
iptables -A FORWARD -s 10.0.0.0/8 -d 192.168.0.0/16 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

5. Проверка транзитных счетчиков на межсетевом экране

# Диагностика сбросов RPF и FORWARD
show ip traffic | include Drop
show log | include %ASA-1-106021

💡 Практика специалистов: При использовании DMVPN всегда проверяйте соответствие Phase 1 (только Hub-and-Spoke) и Phase 2/3 (динамические Spoke-to-Spoke). Смешивание конфигураций туннельных скриптов приводит к скрытым асимметричным сбросам пакетов.

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

Почему Spoke-роутер не видит маршруты других филиалов по BGP?

В iBGP маршруты от одного iBGP соседа не передаются другим соседям во избежание петель. Hub должен быть настроен как BGP Route Reflector (директива neighbor route-reflector-client).

Что такое Unicast RPF (uRPF) Drop в Hub-and-Spoke?

Это сброс пакета маршрутизатором, когда адрес источника входящего пакета не совпадает с маршрутом в таблице FIB для интерфейса, с которого пришел пакет. На туннельных интерфейсах Hub рекомендуется режим loose uRPF.

Как снизить нагрузку на Hub, если филиалы передают гигабайты данных напрямую друг другу?

Переходите от классического Hub-and-Spoke к динамическим топологиям типа DMVPN Phase 2/3 (NHRP Shortcuts) или FlexVPN, где Hub участвует только в обмене ключами, а данные идут напрямую Spoke-to-Spoke.

Нужно ли настраивать NAT/Masquerade на Hub для трафика между филиалами?

Нет, чистая маршрутизация между филиалами должна происходить без NAT. Наличие трансляции адресов нарушит работу сквозных корпоративных протоколов и Active Directory.