Политика VPN для доступа, которая не метит трафик с VLAN

Привет!

Пытаюсь настроить профиль VPN для трафика в сеть. Хочу сделать так, чтобы VIP для VPN находился на (например) 192.168.10.10, однако он назначает пользователям IP из пула IP (192.168.11.10-20). Каждый из которых — отдельная подсеть/VLAN. Сейчас, судя по захватам пакетов, он корректно назначает пользователям IP из пула, но есть две проблемы: 1) IP не отображается в таблицах ARP и 2) Он не маркирует трафик, исходящий из назначенного IP-адреса, вследствие чего, как кажется, маршрутизатор его отбрасывает из-за несоответствия.

Я довольно запутался с этим вопросом и не нашёл хороших статей по нему. Есть ли у кого идеи, куда смотреть? Включил proxy ARP в политике.

  1. IP не отображается в таблицах ARP

Если диапазон IP пула (192.168.11.0/24) находится вне реальной подсети физического интерфейса (192.168.10.0/24), он не будет отображаться в таблице ARP, так как это маршрутизируемый трафик. ARP применим только для локально подключённой подсети, так что, если диапазон IP пула не входит в подсеть физического интерфейса, ARP для этого диапазона не имеет смысла.

  1. Он не маркирует трафик, исходящий из назначенного IP-адреса, что кажется, вызывает его сброс маршрутизатором из-за несоответствия.

А зачем было бы его маркировать? VLAN тегирование — это концепция уровня 2, а этот трафик — уровень 3. Либо у вас настроен интерфейс с тегом VLAN на F5, и весь исходящий через этот интерфейс трафик будет иметь VLAN-метку, либо он — порт доступа (без тега), и он не будет. Однако, вероятно, это не связано с вашей проблемой, потому что:

Что, вероятно, нужно, — маршруты на маршрутизаторе, указывающие на диапазон IP пула через сам F5, маршрутизатор должен знать, как отправлять ответный трафик. Ему нужно указать маршрут, который скажет ему маршрутизировать трафик для 192.168.11.0 к 192.168.10.10.

Простым способом — включить SNAT на виртуальном сервере, тогда весь трафик из пула будет скрыт за IP-адресом интерфейса F5, и маршрутизация станет проще, но весь трафик будет выглядеть как приходящий с IP самого F5, а не отдельных адресов пула.

Должен ли маршрут указывать обратно к VIP? У меня есть подсеть в маршрутизаторе и VLAN, назначенный ему. Также этот VLAN тегирован на F5 и назначен интерфейсу, с которого выходит трафик. Я также вижу, как он маршрутизируется в некоторых случаях и применён неверный тег, совпадающий с подсетью IP VIP.

Из ваших слов следует, что у вас работает двухрукавный режим (две arm-режима), с VIP на “наружи” и маршрутизатором внутри (даже если это два тега VLAN на одном физическом интерфейсе).

В таком сценарии маршрутизатору нужен маршрут для диапазона IP_POOL, который отправит трафик обратно к интерфейсу, из которого он выходит, скорее всего, к устройству само по себе.

Нужно нарисовать схему сети, так как пока не полностью понятно, как у вас организована топология сети.

В конце концов, ваша сеть должна знать, куда отправлять трафик обратно — считать F5 маршрутизатором для этих целей. У него есть своя таблица маршрутов, и трафик из IP Pool выйдет из F5 через тот VLAN, который маршрут укажет.

Если явных дополнительных маршрутов нет, то напрямую подключённые подсети (например, та, что у вас на маршрутизаторе) будут маршрутизироваться правильно, а всё остальное — по умолчанию. Это, вероятно, происходит, когда вы видите, что “применяется неправильный тег”.

Тег применяется исключительно в зависимости от интерфейса (VLAN или физический), через который идёт трафик, и это регулируется маршрутами на F5.

Итак, F5 нужно явно указать маршруты для всех подсетей, расположенных за маршрутизатором, иначе он будет использовать маршруты по умолчанию.

https://imgur.com/lPWRsMd

Вот диаграмма, которую я быстро создал.

Вы правы, мой шлюз по умолчанию — это интерфейс, который получает неправильную маркировку.

Дополнительно мой маршрутизатор — pfSense. Связь происходит через коммутатор Ubiquiti. Самое устройство — Android с клиентом F5 Access Edge. (Подумал также запустить виртуальную машину под Windows и использовать Wireshark или старый ПК, чтобы лучше видеть трафик.)

Согласен, что, похоже, никакие устройства не знают, как маршрутизировать обратно, и я немного запутался, что именно нужно сделать.

Я добавил VIP, который был высокопроизводительным L4 VIP, с исходным трафиком — VPN-сеть клиента и назначением — 0.0.0.0/0, пул — IP-шлюза. Он вроде бы работал, но клиент получал сертификат маршрутизатора, что вызывало ошибки SSL. Не уверен, стоит ли возвращаться к тому же истреблению или что-то измениться.

Кстати, раньше я думал, что хорошо разбираюсь в F5 и сетях, а сейчас чувстую себя студентом — ха-ха!

Забудьте про тегирование. Тегирование — несущественно, F5 ведёт себя как положено.

Если смотреть по диаграмме, то нет необходимости настраивать подсеть IP пула как VLAN на маршрутизаторе, она технически существует только внутри F5, и её следует рассматривать как маршрутизируемую сеть с F5 как следующим узлом.

  • Удалите настройку VLAN 100 на маршрутизаторе, она не нужна (предполагая, что она только для IP пула)
  • Удалите любые тегированные VLAN для VLAN 100 на F5, нужна только конфигурация IP пула без VLAN.
  • Добавьте маршрут для 192.168.12.0/24 на маршрутизаторе, указывающий на интерфейс F5 в VLAN 50 (или на VIP IP, оба варианта допустимы; предпочтительнее — IP интерфейса, так как проще управлять)
  • Удалите ваш VIP с высоким уровнем L4 — он не нужен в данном сценарии.

Затем всякий трафик к VIP от клиента будет следовать по умолчанию маршруту к маршрутизатору, у маршрутизатора есть интерейс в этой подсети, он передаст трафик к F5 по напрямую подключённому маршруту.

Все адреса из IP пула будут следовать по пути выхода из F5 по VLAN 50, с исходным IP 192.168.10.x, что правильно. Маршрутизатор при этом сможет отправить ответный трафик назад через интерфейс VLAN 50, и всё будет работать.

Я немного обновил диаграмму, чтобы показать, как это должно работать логически.](https://imgur.com/a/r6zfogd) Извините за быструю работу, не стал делать профессиональную схему. Указание своих IP — 192.168.14.X — интерфейс F5 или виртуальный IP коммуны, а 192.168.14.Y — IP маршрутизатора в VLAN.

П.С.: на F5, если подключены к access-порту — VLAN нужно разместить без тега, иначе trunk с одним тегированным VLAN также подойдёт, но главное — не делать VLAN 100 определённым где-либо, кроме IP пула. Вместо этого используйте IP пул как диапазон адресов внутри F5, чтобы было понятнее.

Понял, заработало! Наконец-то я понял, что нужно было — добавить правила брандмауэра, разрешающие трафик с F5 на маршрутизатор.

Теперь всё работает!

Очень благодарен за помощь и за обновлённую схему!

Я следовал всем рекомендациям: удалил VLAN и подсеть из маршрутизатора, в настройках F5 создал шлюз для его self IP в подсети 14.0, создал статический маршрут для сети 12.0/24 через этот шлюз. (Пока так единственно мог сделать в pfSense).

Ранее тестировал VPN-клиент, всё равно не получилось. В захвате пакетов видно, что трафик выходит из F5, маркирован VLAN 14, а ответной реакции не видно. Может, стоит проверить маршруты на маршрутизаторе?

Это логично с вашей точки зрения — что F5 — это маршрутизатор, и его роль в маршрутизации — понятна. Всё ещё разбираюсь, совсем свежие знания, использовал только GTM/LTM в простых задачах. Спасибо за поддержку, очень ценно!

Отличная работа. Рад помочь.

На основе всего вышесказанного, есть ли дополнительные рекомендации? Думаю, стоит ли сделать прямое соединение между маршрутизатором и F5 или стоит менять некоторые IP-адреса и сети? Эта сеть (14) предполагалась как выделенная серверная сеть, но теперь я думаю, что нужно что-то изменить.

Использование коммутатора или прямое подключение к маршрутизатору обычно не сильно отличается. В крупных сетях лучше использовать коммутатор, так как у маршрутизатора в портах ограниченное число. Обычно подключают к топ-оф-строка или к верхним коммутаторам.