Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Маршрутизация VLAN через IPSEC STS VPN next-hop, UniFi Network
 
У меня несколько локаций, связанных через IPSEC-ссылки. В каждой удалённой точке у меня есть отдельная VLAN, для которой я хочу задать статический маршрут с указанием next-hop на роутер в центральной (hub) локации. Я проверил связь и могу пинговать IP роутера, но проблема в том, что команда next-hop, которая должна направлять весь трафик из удалённой VLAN в центральный узел, не работает.

Я пробовал несколько вариантов через GUI UniFi, чтобы настроить параметры на USG3 и USG4: использовал next-hop — не сработало, выбирал интерфейс — тоже провал, потом в GUI сменил обратно на next-hop, и при этом интерфейс поменялся с WAN на LAN (а это правильный интерфейс), но результата всё равно не было. Использование GUI не изменило маршрутизацию, весь трафик по-прежнему выходил через WAN-интерфейс на стороне сайта.

Затем я попробовал использовать CLI и PBR (Policy Based Routing). Однако при добавлении маршрута для интерфейса адрес шлюза на WAN-интерфейсе слетал, хотя я указывал данные для VLAN-интерфейса. Искал примеры, но ничего действительно полезного не нашёл. Балансировку нагрузки не использую, у меня только 1 WAN и 1 LAN.

Вопрос: как правильно настроить маршрут, чтобы весь трафик из удалённой VLAN (сайт B) шел через IPSEC-туннель и выходил именно на центральном сайте (сайт A), а не на удалённом (spoke)? При этом удалённый VPN (сайт B) имеет полный доступ к центральной LAN (сайт A), так что нужно только правильно определить статический маршрут для VLAN на сайте B, не затрагивая другие VLAN в той же удалённой точке (сайт B).
 
@UBNT-jaffe

- При использовании вручную созданных IPSEC-соединений список интерфейсов VTI отсутствует. Я видел предыдущие примеры использования VTI для маршрутизации через конкретные подключения, но при выполнении sudo infconfig отображаются только VLAN-интерфейсы.
 
Вы можете попробовать добавить 0.0.0.0/1 и 128.0.0.0/1 в поле «remote subnets» в настройках VPN на сайте B. Но проблема в том, что это направит весь трафик с сайта B, а не только конкретный VLAN. Если хотите проксировать трафик именно определённого VLAN, то, насколько я знаю, единственный способ — использовать политическую маршрутизацию через VTI VPN.
 
@UBNT-jaffe

Спасибо, что ответили. В этом примере eth0 — это LAN1. По сути, я пытался разгрузить (возможно, неправильный термин) трафик, идущий с VTI65 и попадающий в нужный диапазон источников, отправляя его на следующий хоп — другой роутер в моей локальной сети. Однако я только что наткнулся на информацию про асимметричную маршрутизацию и задумался, что, возможно, мне нужно использовать LAN2 для передачи трафика с VTI на другой роутер, который не является основным USG.

На удалённом объекте я выставил следующий хоп на нужный роутер (я могу его пинговать, могу сделать трассировку), но попытка переправить трафик на удалённый шлюз не удаётся. Похоже, нужно использовать другой LAN-интерфейс, а не пытаться делать всё через LAN1. Поэтому я попробую LAN2, чтобы посмотреть, продвинусь ли дальше.

По поводу правила 5005 — оно было нужно на основном объекте, чтобы доставлять трафик с VTI с удалённого сайта и выводить его через локальный WAN-интерфейс. USG не обрабатывал внешний трафик, который шёл через VTI. Я проверял: настраивал VTI, указывал следующий хоп от удалённой сети на LAN IP основного USG. Пинги, трассировка работают как надо. Но попытка открыть веб-страницы и пинги внешних IP — всё падало. Добавление SNAT для маскировки трафика с VTI, который идёт с удалённого сайта, позволило пройти веб-трафику через основной USG из удалённой сети.

Добавление подсетей из других примеров типа 0.0.0.0/128 и подобных в GUI не принимается, поэтому единственным рабочим вариантом оставались правила.

Правило 5005 не помогло с передачей трафика с VTI на другой роутер в той же локальной сети, так что, как сказал выше, попробую LAN2, чтобы решить возможные проблемы с асимметричной маршрутизацией.
 
@Ubiquified

Ты видишь, что правило 4950 срабатывает при команде "show nat statistics"? Если трафик приходит на прокси с правильного хоста, значит PBR/NAT работает как задумано. Причина появления пакетов с нулевой длиной скорее всего в чём-то другом — все TCP-соединения начинаются с пакетов syn/synack/ack с нулевой длиной. Ты смог сделать захват трафика на прокси и посмотреть, что именно приходит?

Ещё можно сделать tcpdump входящего трафика по VPN на vti65, а потом проверить, что он уходит с того LAN-интерфейса, к которому подключён прокси.

sudo tcpdump -npi <interface> host <IP_of_host>

Я не совсем понял правило 5005 — оно на удалённом роутере? Я не вижу случая, когда сеть 10.43.44.0/24 выходила бы через eth0 (предполагаю, WAN) на роутере, который не является локальным для неё.
 
@UBNT-jaffe

Да, была странная ситуация, когда на интерфейсе pptpc0 постоянно сбрасывалось расстояние, и маршрутизация переставала работать. Использование GUI для повторного добавления или CLI временно решало проблему, пока снова не выпадало (даже в json). Двигаясь дальше, я заметил ещё одну проблему, которую, очевидно, я что-то упустил.

У меня есть STS-сайт с включённым и настроенным IPSEC, я включил динамическую маршрутизацию (без неё PBR-правила не работают). Я настроил next-hop на VLAN в PBR-правиле на IP-адрес внутреннего прокси, который запущен в моей основной локальной сети. С удалённого сайта я могу пинговать и делать tracert до прокси, как и ожидалось.

Я экспериментировал с SNAT, DNAT и PBR, пытаясь направить трафик удалённого сайта из определённого VLAN через STS IPSEC-ссылку к прокси в основном офисе. Сейчас хотя бы вижу, что трафик доходит до прокси, хоть и с нулевым размером. Пробовал несколько правил SNAT, но безуспешно, поэтому работает только PBR на удалённом сайте и DNAT на локальном — явно чего-то не хватает на локальном сайте для правильной передачи трафика прокси. Есть идеи, чего не хватает в этой ситуации?

set firewall group address-group VPN_grp address 10.43.44.0/24  
set service nat rule 4950 description 'VPN routed traffic'  
set service nat rule 4950 log disable  
set service nat rule 4950 protocol all  
set service nat rule 4950 inbound-interface vti65  
set service nat rule 4950 inside-address address <proxyip>  
set service nat rule 4950 source group address-group VPN_grp  
set service nat rule 4950 type destination  

set service nat rule 5005 description 'VPN_grp_localredir'  
set service nat rule 5005 log disable  
set service nat rule 5005 exclude  
set service nat rule 5005 protocol all  
set service nat rule 5005 outbound-interface eth0  
set service nat rule 5005 source group address-group VPN_grp  
set service nat rule 5005 type masquerade  

В итоге в логах прокси появляется вот что:  
1518279231.355 0 10.43.44.6 TAG_NONE/400 2127 GET / - HIER_NONE/- text/html
 
Всё уладилось теперь?
 
@UBNT-jaffe нужно было добавить правило SNAT.
 
@UBNT-jaffe

Наконец-то у меня всё заработало: маршрутизация через PBR поверх VTI. Но явно что-то упускаю, потому что трафик вне локальной сети, то есть веб-трафик, не выходит за пределы удалённого шлюза. Удалённый шлюз использует соединение PPPoE на WAN-интерфейсе. Нужно ли выдавать какие-то дополнительные команды, чтобы удалённый сайт получил доступ в интернет через удалённый WAN, как я и пытаюсь сделать? В кратце: IPSEC поднят, VTI/динамическая маршрутизация включены, PBR перенаправляет трафик на удалённый шлюз – и дальше он останавливается.
 
@UBNT-jaffe

Спасибо за это, я видел это в другой теме. Тем не менее, таблица 2 тоже ни к чему не приводит, а маршрут интерфейса игнорируется. Невероятно раздражает, что такие базовые вещи, как маршрут, почему-то просто не работают. Это и в GUI, и в CLI — всё просто уходит через шлюз, и никакой PBR не применяется.
 
@Ubiquified

Тебе стоит использовать таблицу «2» вместо «1». Пока неясно почему, но таблицы 1 и 5 как-то не дружат с интерфейсными маршрутами.
 
@UBNT-jaffe

Использование удалённых подсетей, которые ты упомянул, просто выдаёт ошибку пересечения и нагрузку. Также маршрутизация VTI не работает. Я пытаюсь переслать одну группу VLAN (пробовал всё, как описано выше), но VLAN так и не отправляется на интерфейс, указанный в команде VTI. Тестировал с твоим примером настройки фаервола — всё равно автoмаршрутизация не срабатывает.
Страницы: 1
Читают тему (гостей: 1)