IKuznetsov: Новая страница: « = Прокси для частных локаций = В развертывание Ключ-АСТРОМ можно включать прокси-серверы, балансировщики нагрузки и обратные прокси-серверы. В частности, конфигурация АктивногоШлюза позволяет определить один или несколько прокси-серверов для исходящ...»

2026-09-03T16:20:08Z

Новая страница: « = Прокси для частных локаций = В развертывание Ключ-АСТРОМ можно включать прокси-серверы, балансировщики нагрузки и обратные прокси-серверы. В частности, конфигурация АктивногоШлюза позволяет определить один или несколько прокси-серверов для исходящ...»

Новая страница

= Прокси для частных локаций =
В развертывание Ключ-АСТРОМ можно включать прокси-серверы, балансировщики нагрузки и обратные прокси-серверы. В частности, конфигурация АктивногоШлюза позволяет определить один или несколько прокси-серверов для исходящих соединений.

Для настройки прокси-сервера для связи с тестируемым ресурсом отредактируйте файл <code>custom.properties</code> и задайте свойства в соответствующем разделе <code>[synthetic]</code>.

Чтобы настроить прокси-сервер только для внутренней связи с кластером Ключ-АСТРОМ, см. раздел «Настройки для связи только с кластером Ключ-АСТРОМ».

Чтобы настроить один и тот же прокси-сервер как для тестируемого ресурса, так и для кластера Ключ-АСТРОМ, задайте свойства в соответствующем разделе <code>[http.client]</code>.

== Свойства конфигурации прокси ==
При настройке прокси для АктивногоШлюза с поддержкой синтетических алгоритмов можно использовать следующие свойства:
{| class="wikitable"
!Свойство
!Описание
|-
|<code>proxy-server</code>
|Адрес сервера (имя хоста или IP-адрес)
|-
|<code>proxy-port</code>
|Порт (необязательный). Если оставить поле пустым, будет использоваться порт по умолчанию <code>8080</code>.
|-
|<code>proxy-scheme</code>
|Схема (необязательный). Если поле оставить пустым, используется схема по умолчанию <code>http</code>. Применяется наиболее распространённая конфигурация, при которой соединение с прокси-сервером инициируется с использованием '''HTTP''' и автоматически преобразуется в защищённое. Вся дальнейшая связь АктивногоШлюза через прокси-сервер защищена протоколом '''SSL'''/'''TLS'''. Этот параметр необходимо установить в <code>https</code> для прокси-серверов, которые вообще не поддерживают '''HTTP'''.
|-
|<code>proxy-user</code>
|Имя пользователя (необязательный)
|-
|<code>proxy-domain</code>
|Домен пользователя в случае аутентификации '''NTLM'''
|-
|<code>proxy-password</code>
|Пароль (необязательный). После перезапуска АктивногоШлюза пароль, указанный в свойстве <code>proxy-password</code>, шифруется, и зашифрованный пароль сохраняется в свойстве <code>proxy-password-encr</code>. Если запятая (<code>,</code>) является частью значения, перед ней необходимо добавить экранирующую обратную косую черту (<code>\</code>). Например, <code>proxy-password = foo\,bar</code>.
|-
|<code>proxy-off</code>
|Если установить это значение <code>true</code>, прокси-сервер будет отключён для данного типа связи.
|-
|<code>proxy-non-proxy-hosts</code>
|. В качестве символа-заменителя можно также использовать звёздочку (<code>*</code>). Допускается только один символ-заменитель, либо в начале, либо в конце имени хоста. Например, <code><nowiki>proxy-non-proxy-hosts=*.foo.com|localhost</nowiki></code> означает, что доступ ко всем хостам в домене <code>foo.com</code> и <code>localhost</code> должен осуществляться напрямую, даже если указан прокси-сервер. Полное описание допустимого синтаксиса см. в разделе «Свойства сети» <code>http.nonProxyHosts</code> для соответствующего параметра.
|-
|<code>proxy-authentication-schemes</code>
|АктивныйШлюз версии 1.271+. Список схем аутентификации через прокси-сервер (необязательный). Это приоритетный список схем аутентификации через прокси-сервер, которые АктивныйШлюз должен использовать при аутентификации с прокси-сервером. Начиная с первой схемы в списке, АктивныйШлюз попытается выполнить аутентификацию и, в случае неудачи, перейдёт к следующей схеме в списке. Если это свойство не определено, АктивныйШлюз попытается выполнить аутентификацию, используя все доступные схемы. Поддерживаемые значения: <code>NTLM</code>, <code>BASIC</code>.
|}

== Сценарии подключения через прокси-сервер ==
Это возможные сценарии для вашей конфигурации прокси. Доступ к тестируемому ресурсу через прокси поддерживается только для браузерных мониторов и '''HTTP'''-мониторов.

=== Подключитесь к кластеру Ключ-АСТРОМ ===
<pre>
[http.client]
proxy-server=<proxy>
proxy-port=8080
proxy-user=username
proxy-password=password

[synthetic]
proxy-off=true
</pre>

=== Подключитесь одновременно к кластеру Ключ-АСТРОМ и к тестируемому ресурсу ===
<pre>
[http.client]
proxy-server=<proxy>
proxy-port=8080
proxy-user=username
proxy-password=password
</pre>

=== Подключитесь к кластеру Ключ-АСТРОМ и протестированным ресурсам через различные прокси-серверы ===
Подключитесь к кластеру Ключ-АСТРОМ:<pre>
[http.client]
proxy-server=<proxy>
proxy-port=8080
proxy-user=username
proxy-password=password
</pre>Подключитесь к проверяемому ресурсу:<pre>
[synthetic]
proxy-server=<прокси между AG и проверяемым ресурсом>
proxy-port=9090
proxy-user=username_two
proxy-password=password_two
</pre>

=== Подключитесь к проверяемому ресурсу и/или Amazon S3 ===
Для работы АктивногоШлюза с поддержкой синтетического анализа требуется доступ к сервису '''Amazon S3''' для загрузки и просмотра снимков экрана браузера в закрытых помещениях.<pre>
[synthetic]
proxy-server=<прокси между AG и проверяемым ресурсом>
proxy-port=8080
proxy-user=username
proxy-password=password
</pre>Для получения дополнительной информации см. файлы автоматической настройки прокси-сервера ('''PAC''').

=== Настройте синтетический мониторинг с прямым подключением к другим ресурсам ===
<pre>
[synthetic]
proxy-server=<прокси между AG и проверяемым ресурсом>
proxy-port=8080
proxy-user=username
proxy-password=password
proxy-non-proxy-hosts=my.corp.org|*.gdansk.astromkey.com
</pre>

== Файлы автоматической настройки прокси-сервера (PAC) ==
Для настройки сложных параметров прокси-сервера для мониторинга браузера в приватном режиме можно использовать файлы автоматической настройки прокси ('''PAC''').

=== Что такое PAC-файл? ===
Файл автоматической настройки прокси ('''PAC''') — это функция '''JavaScript''', которая определяет, будут ли запросы веб-браузера ('''HTTP''', '''HTTPS''' и '''FTP''') направляться непосредственно к месту назначения или перенаправляться на веб-прокси-сервер (подробнее см. файл автоматической настройки прокси ('''PAC''') на '''developer.mozilla.org''').

=== Предоставьте PAC-файл мониторам вашего браузера ===

# Перейдите в раздел '''Синтетический мониторинг'''.
# (Необязательно) Чтобы отфильтровать таблицу по мониторам браузеров, выберите '''Браузер''' в разделе '''Параметры фильтра''' слева.
# Из списка мониторов браузера выберите тот монитор, для которого вы хотите предоставить '''PAC'''-файл. После этого справа отобразится панель предварительного просмотра.
# В правом верхнем углу панели предварительного просмотра выберите '''Редактировать'''.
# С этого момента вы будете перенаправлены на предыдущую страницу Ключ-АСТРОМ, где сможете указать '''URL'''-адрес '''PAC'''-файла.
# Переключитесь в режим сценария.
#* Для создания clickpatch выберите '''Записанный clickpatch''' > '''Скрипт'''.
#* Для мониторинга по одному '''URL'''-адресу выберите '''Скрипт монитора'''.
# Добавьте следующее в объект <code>configuration</code> '''JSON'''-файла:
<pre>
"proxy": {
"pacUrl": "https://www.example.com/test.pac"
}
</pre>

# <code>pacUrl</code> указывает на ваш размещённый '''PAC'''-файл.

=== Совместимость конфигурации файла PAC ===

* Конфигурация '''PAC'''-файла применяется только к частным синтетическим локациям, а не к общедоступным.
* Конфигурация '''PAC'''-файла применяется только к настроенному вами монитору — для каждого отдельного монитора '''PAC'''-файл должен быть настроен в его скрипте; нет глобальной настройки для всех мониторов, позволяющей использовать '''PAC'''-файл для прокси-сервисов.
* Если вы настраиваете прокси-файл '''PAC''' для одного скрипта синтетического мониторинга, он применяется только к этому монитору.
* Если указан '''PAC'''-файл, он переопределяет настройки прокси-сервера, заданные на уровне АктивногоШлюза для связи с тестируемым ресурсом. В частности, он переопределяет свойства в соответствующем разделе <code>[synthetic]</code>.
* Файл '''PAC''' должен передаваться по протоколу '''HTTP'''/'''S'''.

== Настройка прокси-сервера для режима FIPS ==
При установке синтетической локации в режиме '''FIPS''' трафик монитора браузера должен маршрутизироваться через локальный перехватывающий прокси-сервер, чтобы весь трафик, покидающий хост, шифровался с помощью криптографической библиотеки, сертифицированной по стандарту '''FIPS''':

В этом примере мы используем прокси-сервер '''Squid''', подключённый к встроенной библиотеке '''OpenSSL''', но вы можете использовать другое прокси-программное обеспечение, если его криптографическая библиотека сертифицирована по стандарту '''FIPS'''.

Установите прокси-сервер на том же хосте, что и синтетический движок:

=== Red Hat ===
<pre>
sudo dnf install squid
</pre>

=== Ubuntu Pro ===
<pre>
sudo apt install squid-openssl
</pre>Предоставьте сертификат центра сертификации для повторной подписи перехваченных запросов:

=== Red Hat ===
<pre>
sudo mkdir /etc/squid/ssl_cert
sudo mv ~/prepared_ca_cert.pem /etc/squid/ssl_cert/squid.pem
sudo chown --recursive squid:squid /etc/squid/ssl_cert
sudo chmod 700 /etc/squid/ssl_cert
sudo chmod 600 /etc/squid/ssl_cert/squid.pem
</pre>

=== Ubuntu Pro ===
<pre>
sudo mkdir /etc/squid/ssl_cert
sudo mv ~/prepared_ca_cert.pem /etc/squid/ssl_cert/squid.pem
sudo chown --recursive proxy:proxy /etc/squid/ssl_cert
sudo chmod 700 /etc/squid/ssl_cert
sudo chmod 600 /etc/squid/ssl_cert/squid.pem
</pre>Если включена функция '''SELinux''', может потребоваться корректировка меток файлов. Подробности см. в документации '''Red Hat''' для '''Red Hat Enterprise Linux 8''' или '''Red Hat Enterprise Linux 9'''.

Создать временный кэш сертификатов:

=== Red Hat ===
<pre>
sudo /usr/lib64/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 4MB
sudo chown --recursive squid:squid /var/spool/squid/ssl_db
</pre>

=== Ubuntu Pro ===
<pre>
sudo /usr/lib/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 4MB
sudo chown --recursive proxy:proxy /var/spool/squid/ssl_db
</pre>Настройте прокси-сервер для перехвата '''SSL'''-сообщений (по умолчанию <code>/etc/squid/squid.conf</code>):<pre>
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl_cert/squid.pem

acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
cache deny all
</pre>Для вступления изменений в силу перезапустите прокси-сервер:<pre>
sudo systemctl enable squid
sudo systemctl restart squid
</pre>Убедитесь, что прокси-сервер работает корректно:<pre>
curl --proxy localhost:3128 https://example.com
</pre>(Необязательно) Если вы выбрали другой порт прокси, вам необходимо настроить синтетическую конфигурацию (по умолчанию <code>/var/lib/astromkey/synthetic/config/user.properties</code>):<pre>
com.vuc.fips.proxy.port=3128
</pre>

== Настройка прокси-сервера для режима FIPS с использованием корпоративного прокси ==
Если в вашей организации требуется использование корпоративного прокси-сервера, вам необходимо настроить второй локальный экземпляр '''Squid''' из-за ограничений '''Squid''':

Если вы используете другое прокси-программное обеспечение, это может быть к вам неактуально.

# Настройте прокси-сервер для '''FIPS''', как описано в предыдущем разделе.
# Требуется определённая версия '''Squid 5+''', поэтому версии '''Red Hat 8''' и '''Ubuntu 20''' не поддерживаются.
# На том же хосте создайте второе определение службы '''Squid''':

=== Red Hat ===
<pre>
/usr/lib/systemd/system/squid2.service

[Unit]
Description: Squid with upstream proxy.
After=network.target network-online.target nss-lookup.target

[Service]
Type=notify
LimitNOFILE=16384
PIDFile=/run/squid2.pid
ExecStart=/usr/sbin/squid --foreground -n squid2 -f "/etc/squid/squid2.conf"
ExecReload=/usr/bin/kill -HUP $MAINPID
KillMode=mixed
NotifyAccess=all

[Install]
WantedBy=multi-user.target
</pre>

=== Ubuntu Pro ===
<pre>
/lib/systemd/system/squid2.service

[Unit]
Description: Squid with upstream proxy.
After=network.target network-online.target nss-lookup.target

[Service]
Type=notify
PIDFile=/run/squid2.pid
Group=proxy
RuntimeDirectory=squid2
RuntimeDirectoryMode=0775
ExecStart=/usr/sbin/squid --foreground -sYC -n squid2 -f "/etc/squid/squid2.conf"
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
NotifyAccess=all

[Install]
WantedBy=multi-user.target
</pre>Создайте вторую конфигурацию прокси-сервера (<code>/etc/squid/squid2.conf</code>) и укажите хост, порт и аутентификацию вашего корпоративного прокси-сервера:<pre>
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost
http_access deny all
http_port 3129

access_log daemon:/var/log/squid/access2.log squid
cache_log /var/log/squid/cache2.log
pid_filename /run/squid2.pid

cache_peer upstream-proxy.example.com parent 443 0 default no-digest proxy-only login=proxyuser:proxypass tls tls-min-version=1.2 tls-options=NO_SSLv3
never_direct allow all
visible_hostname squid2
cache deny all
</pre>Обновите конфигурацию первого прокси-сервера (<code>/etc/squid/squid.conf</code>), чтобы использовать второй прокси-сервер в качестве родительского, добавив следующие строки:<pre>
cache_peer localhost parent 3129 0 default no-digest proxy-only
never_direct allow all
visible_hostname squid1
</pre>Перезапустите обе службы '''Squid''':<pre>
sudo systemctl daemon-reload
sudo systemctl enable squid2
sudo systemctl start squid2
sudo systemctl restart squid
</pre>Убедитесь, что цепочка прокси-серверов работает корректно:<pre>
curl --proxy localhost:3128 https://example.com
</pre>

== Вопросы распределения ресурсов ==

* Каждому сервису '''Squid''' требуется дополнительно 500 МиБ оперативной памяти, что необходимо учитывать при выборе размера экземпляра для конкретной рабочей нагрузки.
* Запросы, проходящие через несколько прокси-серверов, будут выполняться дольше, поэтому показатели производительности будут хуже, чем у запросов от экземпляра, не соответствующего стандарту '''FIPS'''.

Прокси для частных локаций - История изменений