Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Маршрутизация на основе политик в USG PRO 4, UniFi Network
 
Привет, сообщество!  
Я новичок в USG, так что, возможно, это объясняет проблему, с которой столкнулся при настройке PBR через OpenVPN-туннель.

Для начала — конфигурация:  
Vtun1 OpenVPN: настроен через конфигурационный файл и поднят. Трафик с и в удалённую сеть проходит без проблем.  

openvpn vtun1 {  
   config-file /config/ovpn/ch-zh01.ovpn  
}  

vtun1 10.127.198.50 u/u  

Теперь я хочу использовать этот VPN-туннель для одного клиента как основной маршрут / доступ в интернет.  
Клиент имеет IP 10.100.1.52 и находится за L3-коммутатором на LAN-интерфейсе eth0 10.127.199.254.  

Вот правило PBR, которое я применяю к eth0:  
set protocols static table 100 route 0.0.0.0/0 next-hop 10.127.198.49  
set firewall modify LOAD_BALANCE rule 3000 action modify  
set firewall modify LOAD_BALANCE rule 3000 modify table 100  
set firewall modify LOAD_BALANCE rule 3000 source address 10.100.1.52  
set firewall modify LOAD_BALANCE rule 3000 protocol all  
set interfaces ethernet eth0 firewall in modify LOAD_BALANCE  

Для теста запускаю ping к адресу 193.99.144.80.  
Правила применяются, но ничего больше не работает.

Я сделал tcpdump на удалённой стороне OpenVPN-туннеля и вижу, что пакеты доезжают до цели, возвращаются и идут обратно в туннель.  

Удалённая сторона:  
00:40:49.374490 IP 10.100.1.52 > 193.99.144.80: ICMP echo request, id 1, seq 912, length 40  
00:40:49.381753 IP 193.99.144.80 > 10.100.1.52: ICMP echo reply, id 1, seq 912, length 40  

На USG, интерфейс VTUN1:  
7  2.350930  10.100.1.52 > 193.99.144.80 ICMP 60 Echo (ping) request id=0x0001, seq=612/25602, ttl=126 (ответ в 8)  
8  2.384820  193.99.144.80 > 10.100.1.52 ICMP 60 Echo (ping) reply id=0x0001, seq=612/25602, ttl=242 (запрос в 7)  

А теперь на USG, интерфейс eth0:  
1  0.000000  10.100.1.52 > 193.99.144.80 ICMP 74 Echo (ping) request id=0x0001, seq=654/36354, ttl=127 (ответ не найден!)  
4  4.973559  10.100.1.52 > 193.99.144.80 ICMP 74 Echo (ping) request id=0x0001, seq=655/36610, ttl=127 (ответ не найден!)  
7  9.972599  10.100.1.52 > 193.99.144.80 ICMP 74 Echo (ping) request id=0x0001, seq=656/36866, ttl=127 (ответ не найден!)  

Похоже, USG фильтрует входящие reply-пакеты, когда они приходят с vtun1.  

VTUN1 создан не через GUI, так как другая сторона — PFSense-узел. Возможно, не хватает каких-то настроек фаервола, но, будучи новичком в этом продукте, я не знаю, что именно.  

Надеюсь, кто-то поможет направить меня в нужное русло.  
Спасибо за внимание и помощь!  
Мартин  

USG Firmware: 4.4.22.5086057  
Controller: 5.8.16
 
@dbrosy

Я это написал и добавил туда вчера.
 
@UBNT-jaffe

Спасибо за ответ, после двух дней мучений с настройкой ваше сообщение дало мне правильное направление. У меня работает edgerouter (1.10.5), а вот USG3P (4.4.22) не запускается. Я сравнивал эту строку в edgerouter и в usg:  
Edgerouter: set firewall source-validation disable  
USG: set firewall source-validation strict  
Поэтому я поменял source-validation с strict на disable, и теперь мой PBR работает. Есть ли какая-то проблема с source-validation?
 
Я объясняю основную причину этой проблемы здесь: https://community.ui.com/questions/4744895c-c9f6-4774-8ce0-a9c12468be12#answer/1f10eb33-d026-41f5-bc7e-1397e5b265a6. Проверка источника — это то, что блокирует пакет. Это означает, что если пакет приходит на интерфейс из интернета, который не совпадает с маршрутом по умолчанию, то его сбрасывают. Проверка источника не умеет работать с несколькими таблицами маршрутизации, поэтому контроллер автоматически создает конфигурационный узел, который отключает проверку источника при использовании multiWAN (при настройке WAN2).
 
Подозреваю, что у меня такая же проблема. У меня настроен vtun1 с маршрутизацией на основе назначения. Трафик выходит через интерфейс vtun1 и, кажется, возвращается обратно в vtun1, но на этом всё и заканчивается. Очень много повторных передач TCP. Раньше у меня это работало, но, похоже, после обновления USG3P или контроллера что-то сломалось. До сих пор не удалось настроить, поэтому буду признателен за любую помощь. Есть ли какие-то шаги для поиска и устранения неполадок, чтобы понять, такая ли же у меня проблема? Использую один WAN (PPPoE) и один LAN. OpenVPN.
 
Похоже, у меня тоже возникла эта проблема. После обновления моего Cloud Key до версии v0.11.2 и контроллера до 5.8.23-11014 маршруты на основе политики на моём USG (прошивка 4.4.22.5086045) перестали работать. Я могу пинговать всё в сетях без проблем, но любой трафик, соответствующий правилу модификации в файрволе, просто отбрасывается. Это просто маршруты с одного VLAN на другой, то есть VPN у меня нет. Добавление фиктивного WAN2, который даже не подключен, сразу решило проблему. Спасибо за этот пост! Я потратил как минимум 8 часов, уставясь в настройки и не понимая, что происходит. Никогда бы не додумался настроить WAN2.
 
Только что нашёл это: https://help.ubnt.com/hc/en-us/articles/360005460813-UniFi-USG-Advanced-Policy-Based-Routing-
Страницы: 1
Читают тему (гостей: 1)