Как ограничить количество сессий?

Если AppDirector не может вам помочь, вот еще один подход, который потребует небольшого кода. Я бы решил эту проблему следующим образом:

• В цикле продолжайте читать файл журнала apache (и повторно открывайте его при logrotate)
• Когда пользователь посещает любую страницу (не только входит в систему), добавьте их в белый список iptables.
• Когда пользователь выходит из системы или после бездействия (так что сохраняйте таймеры для активных сеансов!), Удалите его из белого списка.
• Если белый список заполнен, перенаправить весь трафик, не внесенный в белый список, на специальный порт
• Запустите простой виртуальный хост на этом порту с вашей пользовательской ошибкой

. Графическое отображение количества сеансов становится таким же простым, как графическое отображение длины цепочки iptables. Сервер мониторинга можно просто добавить в белый список.

Эту проблему можно решить как с помощью RadWare AppDirector, так и (для полноты), вероятно, также с помощью Apache mod_security, согласно вашему превосходному выводу в комментарии ниже.

Для решения AppDirector я полагают, что можно создать сопоставление двух ферм с одним и тем же внутренним сервером (ами). Эти фермы могут иметь разные критерии и условия работы. Одна ферма будет «по умолчанию», а другая будет отвечать на URI: s, которые вы определяете как «сеанс». Последний получит ограничение на количество сеансов, которые он принимает в балансировщике нагрузки.

С этого момента я собираюсь заменить термин «сеанс» на «вошел в систему» ​​по двум причинам:

• Это позволяет избежать двусмысленности, поскольку он четко определяет желаемое состояние, в котором пользователь аутентифицирован.
• Руководство пользователя AppDirector и графический интерфейс пользователя переопределяют термин «соединение», чтобы он имел значение для всех практических целей, идентичное «сеансу», см. Ниже. Это добавляет путаницы, которую мы стараемся избежать.

Также возможно показать страницу с сожалением, если "авторизованная" ферма достигла выбранного лимита подключений.

Прежде чем перейти к тому, как я должен четко заявить, что у меня есть нет опыта работы с продуктом AppDirector, но ежедневно администрируйте конкурирующий и немного менее продвинутый балансировщик нагрузки. Продукт, который я использую, может сразу же выполнить этот сценарий. Я нашел информацию в руководстве пользователя AppDirector и в доступной онлайн-документации, которая предполагает, что то же самое верно и для AppDirector. Однако, хотя концепции схожи, терминология отличается. Я просто действую в Риме в отношении формулировок, надеясь сделать это правильно, не будучи слишком явно невежественным идиотом.

Самым большим препятствием было получение доступа к руководству, которое не предоставляется, если только один является активным покупателем. Путем некоторого поиска в Google удалось найти старую версию, которая, я надеюсь, не слишком устарела, я также нашел пару статей из базы знаний и эту ссылку: Radware AppDirector - Configuration: Basic Application .

Вот черновик решения, интерпретируемый в основном в Руководстве пользователя:

Вход клиента в балансировщик нагрузки осуществляется через VIP, который используется для подключения как «сеансов по умолчанию», так и «сеансов, вошедших в систему». Это достигается с помощью политики L4 согласно стр. 99 в Руководстве пользователя:

"When AppDirector receives the first packet of a session destined to a
Virtual IP address, it searches for a Layer 4 Policy that matches the
Layer 4 Protocol, Destination port, Source IP, etc. Then, based on this
information, AppDirector selects the farm allocated to this service and
the best server for the task from that farm, and forwards the packet to
that server.

Политика L4 может быть связана с политиками L7, которые используются для выбора подходящей фермы. Процесс политики L7 описан, таким образом, в Руководстве пользователя на стр.104:

"The Layer 7 content aware decision making mechanism allows you to have
a single point of entry to the site, and provides differentiated service
for different user groups.

A Layer 7 decision is made using a mechanism called Delayed Binding.
When Delayed Binding is used, AppDirector first performs a TCP handshake
with the client to receive the HTTP request. AppDirector parses the HTTP
request’s data, usually HTTP headers, and performs the load balancing
decision. Only after that, does AppDirector select a farm and a server.
Lastly, AppDirector initiates a TCP handshake with the server and
forwards the traffic to it
[...]
When Layer 7 Policies are used, farm selection is based on matching the
request data with a list of Layer 7 Policies defining the Layer 7
parameters differentiating the service. The process of server selection
within the farm can also be content-based, using a third Layer 7
parameter."

Методы, доступные для определения поведения L7, описаны на стр.106, из которых вы можете выбрать подходящий метод для выбора маршрутизации к вашему "зарегистрированному" Ферма, а не ферма «по умолчанию»:

"Methods are the basic building blocks for Layer 7 service selection.
They define content by which traffic is differentiated. You can use
the same Method to select one or more services. The following Method
Types are available:

- URL: Looks for a specified host name and/or path in the HTTP request.
- File Type: Looks for a specified File Type in the HTTP request.
- Header Field: Looks for a specified Header Field in the HTTP request.
- Cookie: Looks for a specified Cookie in the HTTP request.
- Regular Expression: Looks for a regular expression anywhere in the
HTTP request. AppDirector supports Posix 1002.3 regular expressions;
the string can be up to 80 characters.
- Text: Looks for a text string anywhere in the HTTP request."

Как видно из ссылки Базовое приложение , можно, например, создать политику L7, оценивающую шаблоны URI для маршрутизации в разные фермы. Созданные шаблоны URI «^ / login? = True» и «^ / loggedin» могут быть перенаправлены на вашу ферму «авторизованных». Созданный шаблон '^ / logout' (и все остальные URI: s) можно аналогичным образом направить в ферму "по умолчанию".

Ферма определяется в Руководстве пользователя на стр.121 следующим образом: "

"The Layer 3 Client Table is always used when Entry Per Session is used.
AppDirector uses the Layer 3 Client Table to ensure Layer 3 persistency.

This table contains information about the server selected for each client
(Source IP address) in each farm, and it allows AppDirector to select a
server for a new session.
[...]
In the Regular mode, AppDirector maintains Layer 3 persistency. In this mode,
each entry is identified by the following parameters:
• Layer 4 Policy VIP Address
• Client IP Address
• Destination TCP/UDP Port Used from the Client to the Server"

"Connection Limit

Maximum number of Client Table entries that can run simultaneously on 
the physical server. This depends on the farm’s Sessions mode (see 
Sessions Modes, page 150). When the limit is reached, new requests are 
no longer directed to this server. All open sessions are continued.

When the Connection Limit parameter is configured to 0 (default), this 
mechanism is disabled for this physical server and there is no user 
number limit.

Note: When configuring the physical server, ensure that the Connection 
Limit in the farm servers with the same Server Name is lower than or 
equal to the Connection Limit in the physical server. Total number of 
active sessions that run simultaneously on the farm servers must not 
be higher than the Connection Limit value defined on the physical server."

After the specified session limit has been reached, the next user should be
directed to a custom error page.

When all servers belonging to a farm cannot be used for a specific
session, AppDirector can reply to a Web request (destined to port 80)
with a simple Web page, indicating that the service is currently not
available. Servers that cannot be used for a session include servers
in Not In Service or in No New Sessions mode. No HTTP Service Page is
configured for each farm. Each Web page is limited to 1K of HTML code.

track the current number of sessions for monitoring purposes

whitelist the monitoring server (which is issuing queries to the webapp
periodically) and exempt it from the limit.