Обратный прокси-сервер – это компьютер, установленный в пределах пограничной сети (т.н. демилитаризованной зоны [DMZ] или промежуточной подсети), который обрабатывает запросы из Интернета и перенаправляет их на компьютеры внутренней сети. Перенаправляя запросы, обратный прокси-сервер маскирует идентичность компьютеров, находящихся за брандмауэром организации, защищая таким образом внутренние компьютеры от прямых атак со стороны пользователей интернета. На обратном прокси-сервере можно реализовать дополнительные функции безопасности, позволяющие еще больше защитить внутреннюю сеть от пользователей извне.
Если вы используете обратный прокси-сервер с функцией проверки работоспособности, рекомендуем вам использовать точку доступа проверки работоспособности Portal for ArcGIS, чтобы определить, может ли портал получать запросы. Это используется для быстрого определения наличия на сайте аппаратного или программного сбоя. Дополнительные сведения см. в разделе Проверка работоспособности в ArcGIS REST API.
Внимание:
Специфические настройки, описанные в этом разделе, должны быть применены перед интеграцией любого сайта ArcGIS Server с вашим порталом ArcGIS Enterprise. Добавление псевдонима DNS или обратного прокси-сервера после интеграции сайта ArcGIS Server с порталом не поддерживается. Если необходимо изменить имя хоста в URL организации, свяжитесь с Esri Professional Services или другими консалтинговыми компаниями для получения указаний.
Отмена интеграции сайта ArcGIS Server приведет к ряду существенных изменений, отменить это действие будет затруднительно. Для дополнительной информации см. Администрирование интегрированного сервера.
Добавление Portal for ArcGIS к обратному прокси-серверу
Перед добавлением Portal for ArcGIS к обратному прокси-серверу организации, необходимо выполнить следующие шаги:
- Настройте HTTPS (HTTP и HTTPS или только HTTPS) на обратном прокси-сервере. Portal for ArcGIS по умолчанию выполняет коммуникацию по HTTPS. Обратитесь к документации к прокси-серверу, чтобы узнать о настройке HTTPS.
Примечание:
Portal for ArcGIS не поддерживает протокол SSL-разгрузки через обратный прокси-сервер / балансировщик нагрузки. Поэтому если ваша конфигурация использует обратный прокси-сервер, он должен направить трафик либо к ArcGIS Web Adaptor, либо напрямую к Portal for ArcGIS через HTTPS.
- Настройте ArcGIS Web Adaptor для работы с порталом, если ваш портал будет использовать Встроенную аутентификацию Windows. Для этого Portal for ArcGIS необходимо использовать ArcGIS Web Adaptor, это позволит обратному прокси-серверу правильно работать с порталом. Подробные инструкции см. в разделе Настройка ArcGIS Web Adaptor.
Убедитесь, что прокси-сервер поддерживает кодирование gzip и настроен на поддержку заголовка Accept-Encoding. Этот заголовок поддерживает сжатие ответов HTTP 1.1 с помощью gzip. Например, если заголовок разрешен, запрос загрузки в Map Viewer возвратит в браузер сжатый ответ, имеющий объем, равный 1,4 МБ. Если же заголовок не разрешен или игнорируется, запрос возвратит в браузер несжатый ответ, имеющий объем, равный 6,8 МБ. Если скорость вашей сети невелика, Map Viewer может долго загружаться, если ответы не сжимаются. Esri настоятельно рекомендует разрешить использование этого заголовка во время настройки обратного прокси-сервера.
Добавление ArcGIS Web Adaptor в директивы прокси-сервера
После настройки ArcGIS Web Adaptor на работу с Portal for ArcGIS, ArcGIS Web Adaptor можно использовать с обратным прокси-сервером вашей организации, добавив эти компоненты непосредственно в директивы прокси. Например, если вы используете Apache в качестве обратного прокси-сервера, вам потребуется добавить ArcGIS Web Adaptor в директивы ProxyPass в файл конфигурации веб-сервера Apache httpd.conf:
ProxyPass /webadaptorname https://webadaptorhost.domain.com/webadaptorname
ProxyPassReverse /webadaptorname https://webadaptorhost.domain.com/webadaptornameДирективы ProxyPass должны соответствовать имени ArcGIS Web Adaptor (/webadaptorname в примере выше).
Подготовка обратного прокси-сервера
Перед развертыванием обратного прокси-сервера для использования с порталом, Esri рекомендует настроить заголовки обратного прокси-сервера для обеспечения связи.
В конфигурации загрузки обратного прокси-сервера задайте заголовок X-Forwarded-Host, соответствующий имени хоста обратного прокси. Portal for ArcGIS ожидает этот параметр в заголовке, посланном обратным прокси-сервером, и возвращает запросы, соответствующие URL-адресу обратного прокси-сервера. Если вы не используете ArcGIS Web Adaptor с порталом, установите заголовок Host в соответствии с именем хоста компьютера, на котором установлен Portal for ArcGIS.
Подсказка:
Вы можете использовать точку доступа machines в ArcGIS Portal Administrator Directory для просмотра имени хоста компьютера, где работает Portal for ArcGIS.
Например, запрос к конечной точке Portal for ArcGIS REST (https://reverseproxy.domain.com/arcgis/sharing/rest) будет возвращен клиенту как тот же URL. Если это свойство не задано, Portal for ArcGIS может возвратить URL внутреннего компьютера, на который был направлен запрос (например, https://portal.domain.com/arcgis/sharing/rest вместо https://reverseproxy.domain.com/arcgis/sharing/rest). Это проблематично, т.к. клиенты не смогут получить доступ к этому URL-адресу (обычно выглядит как ошибка 404 в браузере). Также, клиент получит доступ к некоторым сведениям о внутреннем компьютере.
Вместе с заголовком X-Forwarded-Host, обратный прокси-сервер должен иметь возможность отправлять перенаправления (коды HTTP 301 или 302). Также следует обновить его заголовок Location, чтобы гарантировать, что полное доменное имя (FQDN) и контекст ответа соответствуют значению WebContextURL портала.
Задание свойства WebContextURL
Свойство портала WebContextURL помогает создать корректные адреса URL для всех ресурсов, которые отправляются конечному пользователю.
Примечание:
Если вы не используете ArcGIS Web Adaptor в своем развертывании, убедитесь, что имя контекста обратного прокси-сервера переходит только на один уровень URL глубже. Например, у вас может быть адрес URL обратного прокси-сервера, такой как https://proxy.domain.com/enterprise, но у вас не может быть адреса URL обратного прокси-сервера типа https://proxy.domain.com/myorg/enterprise.
- Откройте веб-браузер и войдите в ArcGIS Portal Directory в качестве участника с ролью администратора по умолчанию в вашей организации портала. Адрес URL имеет формат https://portal.domain.com:7443/arcgis/portaladmin.
- Щелкните Система > Свойства > Обновить свойства.
- В диалоговом окне Обновить свойства системы вставьте следующий JSON, заменив собственный URL-адрес обратного прокси или псевдоним DNS тем, который видят пользователи за пределами брандмауэра вашей организации.
{ "WebContextURL": "https://reverseproxy.domain.com/enterprise" }Примечание:
Portal for ArcGIS поддерживает только один DNS.
Примечание:
Вы не можете использовать порт, отличный от стандартного (то есть порт, не являющийся 443) при настройке свойства WebContextURL.
- Щелкните Обновить свойства.
Повторное выполнение административных задач
Теперь, когда настройка обратного прокси сервера с вашим порталом завершена, вы будете входить на свой портал через URL-адрес обратного прокси-сервера, а не по URL-адресу ArcGIS Web Adaptor. Все, что вам будет доступно на веб-сайте портала или в ArcGIS Portal Directory, вы будете получать через URL обратного прокси-сервера.
Следующие административные задачи необходимо повторить, используя URL обратного прокси-сервера:
Если ранее вы добавили защищенные сервисы как элементы вашего портала, то исходные элементы необходимо удалить и добавить снова. Это необходимо сделать, потому что исходные элементы используют URL-адрес ArcGIS Web Adaptor, а не URL обратного прокси-сервера. Инструкции см. в разделе Подключение к защищенным сервисам.
После настройки обратного прокси-сервера на работу с порталом, может потребоваться дополнительная настройка. Например, если операции или запросы в развертывании не работают с возвратом ошибки, указывающей на превышение времени ожидания, возможно значение времени ожидания на прокси-сервере слишком мало. Для исправления этой ошибки, увеличьте время ожидания, что позволит выполняться длительным запросам, например, интегрированного сервера.