ISE Netscaler Loadbalancing Cross-Service Persistence

[sebastianrei]

Привет всем, Я следую этому руководству для настройки:
[) Я также ознакомился с этой дискуссией о постоянстве радиуса на Netscaler:
[) На данный момент балансировка нагрузки radius работает нормально. Однако я пытаюсь понять, как обеспечить кросс-сервисную персистентность между гостевым порталом (размещенным на ISE для веб-аутентификации в беспроводной настройке dot1x) и соответствующей сессией radius. На F5 —
из того
,
что я прочитал
— есть явная опция для кросс-сервисной персистентности, которая удерживает веб-трафик и трафик radius для клиента, привязанного к тому же бэкэнд ISE PSN. Я не уверен, как добиться такого же поведения на Netscaler. Я уже использую группу персистентности, но она работает только для radius, я не могу добавить свой портал vserver. Насколько я понимаю, контекст гостевой сессии (для саморегистрации и состояния портала) существует только на PSN, к которому пользователь первоначально подключается — он не реплицируется на другие PSN. Если перенаправление или запрос radius позже попадает на другой PSN, этот узел не распознает сессию, что может нарушить поток. Может ли кто-нибудь подтвердить, верно ли это понимание, и есть ли способ настроить межсервисную постоянность на Netscaler, чтобы как веб-трафик, так и radius-трафик от клиента всегда попадали в одну и ту же PSN? Спасибо за любой совет!

[andrewswanson]

Спасибо за обновление, Себастьян. Этот пост на форуме F5 отражает то, что вы обнаружили с Netscaler: https://community.f5.com/discussions/technicalforum/irule-http-traffic-to-the-same-real-server-as-radius-session/26354 Я подумал, что, возможно, стоит подать запрос на улучшение портала ISE, чтобы в заголовке указывался MAC-адрес клиента, но Netscaler должен будет прекратить SSL, чтобы увидеть этот заголовок. Ничто не бывает простым! С уважением Энди

[andrewswanson]

Привет Для групп постоянства существует опция «
Использовать постоянство vServer
». В документации NetScaler указано: Используйте этот параметр, чтобы включить постоянство на уровне vserver для членов группы. Это позволяет vserver-членам иметь собственное постоянство, но они должны быть совместимы с правилами постоянства других членов. Когда этот параметр включен, сеансы постоянства, созданные любым из членов, могут использоваться другими vserver-членами. Я сам не использовал эту функцию, но она похожа на функцию F5. hth
Andy

[sebastianrei]

Спасибо за ответ, я протестировал опцию «Использовать постоянство vServer», но столкнулся с проблемой несовместимости протоколов. Когда я пытаюсь привязать vserver гостевого портала (который является tcp) к той же группе постоянства, что и для radius, я получаю:

bind lb group ise-lab guest-portal-ise-lab
ERROR: Операция не разрешена
., потому что я использую следующее выражение: CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T. Я не знаю, как заставить это работать как для tcp, так и для radius/udp.

[andrewswanson]

Привет, в ссылке Netscaler ниже конкретно указано, как это сделать для radius и http: https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-persistence/sharing-persistent-sessions.html Предположим, что v1 и v2 привязаны к группе балансировки нагрузки, v1 — виртуальный сервер типа RADIUS, а v2 — виртуальный сервер типа HTTP. Постоянство «Radius.req.avp(8).value.typecast_text_t» настроено на v1, а «client.ip.src» — на v2. Когда трафик проходит через виртуальный сервер RADIUS v1, он создает постоянную запись на основе оцененной строки правила. Позже, когда трафик достигает виртуального сервера типа HTTP v2, v2 проверяет записи постоянства в группе балансировки нагрузки и использует ту же сессию постоянства для направления трафика на тот же бэкэнд-сервер. hth Энди

[andrewswanson]

В статье NetScaler показаны виртуальные серверы, использующие следующие правила Сохранение vserver RADIUS: Radius.req.avp(8).value.typecast_text_t (кадровый IP-адрес) Сохранение
vserver HTTP: client.ip.src они имеют одинаковый тип атрибута постоянства, т. е. исходный IP-адрес клиента Ваше правило RADIUS использует Calling-station-id с резервным IP-адресом NAS. Calling-station-id обычно является MAC-адресом клиента (а не его IP-адресом — если это беспроводные клиенты, я думаю, что вы можете изменить wlc, чтобы отправлять IP-адрес клиента в Calling-station-id. Таким образом, вы могли бы использовать RADIUS vsever persistence: CLIENT.UDP.RADIUS.ATTR_TYPE(31) ALT RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T
HTTP vserver persistence: client.ip.src NetScaler сможет использовать IP-адрес клиента для persistence в обоих vservers — я не пробовал ничего из этого (просто мыслю нестандартно) hth
Andy

[sebastianrei]

Краткое обновление — я не смог найти в WLC никакой опции, позволяющей отправлять IP-адрес клиента в Calling-Station-Id (настраивать можно только Called-Station-Id, что в данном случае не помогает). Я проверил с помощью:
Radius.req.avp(8).value.typecast_text_t ALT CLIENT.UDP.RADIUS.ATTR_TYPE(31) Вручную все работает нормально при тестировании с radclient с использованием следующих параметров: User-Name = "abcdef"
Calling-Station-Id = "aa:bb:cc:dd:ee:ff"
Framed-IP-Address = 192.168.1.100 Затем, когда я использую curl для LB VIP, я вижу это как постоянную сессию. Завтра я протестирую это с реальными запросами radius в лаборатории и отчитаюсь. Большое спасибо за помощь, Энди — очень ценю ваши предложения! С уважением,
Себастьян

[andrewswanson]

Спасибо за обновление, Себастьян. Возможно, стоит оставить IP-адрес NAS в качестве последнего атрибута «catch all» для обеспечения постоянства RADIUS. Возможно, для этого подойдет правило, подобное приведенному ниже (в нем используется выражение эксперта приложения «radius.req» для получения всех 3 необходимых атрибутов radius) RADIUS.REQ.FRAMED_IP_ADDRESS.VALUE.TYPECAST_TEXT_T ALT
RADIUS.REQ.CALLING_STATION_ID.VALUE.TYPECAST_TEXT_T ALT
RADIUS.REQ.NAS_IP_ADDRESS.VALUE.TYPECAST_TEXT_T Добавив «.VALUE.TYPECAST_TEXT_T» к выражениям атрибутов, он преобразует атрибут в текстовую строку. Удачи,
Энди!

[sebastianrei]

После дополнительных тестов я столкнулся с некоторыми ограничениями: В первоначальном запросе доступа у меня нет информации о Framed-IP, поэтому я могу полагаться только на MAC-адрес, отправленный в качестве Calling-Station-ID для обеспечения постоянства. Поскольку я использую внешний DHCP, я думаю, что нет возможности получить IP в первоначальном запросе доступа. У меня есть Framed-IP в запросе учета, что полезно для обеспечения постоянства с TCP VIP (гостевой портал). Проблема заключается в том, что я не могу создать постоянство между Auth (только MAC), Accounting (IP+MAC) и Guest Portal (только IP), потому что Netscaler позволяет только одну запись постоянства на правило (насколько я знаю). Поэтому мой текущий подход, который соответствует моим требованиям, даже если он не совсем соответствует тому, что я изначально хотел, заключается в следующем: Создать VIP для 1812 и неадресуемый VIP, связанный для отказоустойчивости (через защиту) + сделать то же самое для 1813 и гостевого портала.
Мне не нужна реальная балансировка нагрузки — только отказоустойчивость на случай перезагрузки или обновления узла в кластере — поэтому это соответствует моим потребностям. Если у кого-то есть другие идеи по обеспечению постоянства между Auth, Accounting и Guest Portal с учетом этих ограничений, я с удовольствием протестирую их в своей лаборатории. Еще раз спасибо за помощь, Энди!
С уважением,
Себастьян