Обратный прокси сервер что это?

Что такое обратный прокси?

Я знаю, что такое прокси-сервер, но я не уверен, что такое обратный прокси-сервер. Мне кажется, что это, вероятно, похоже на балансировщик нагрузки. Это правильно?

6 ответов

Обратный прокси-сервер, также известный как «входящий» прокси-сервер, является сервером, который получает запросы из Интернета и пересылает (прокси) их на небольшой набор серверов, обычно расположенных во внутренней сети и не имеющих прямого доступа извне. Это «обратное», потому что традиционный («исходящий») прокси получает запросы от небольшого набора клиентов во внутренней сети и перенаправляет их в Интернет.

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

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

Обратный прокси-сервер может использоваться для обеспечения безопасности внутренних ресурсов. Двумя распространенными являются сервер Microsoft ISA и Apache с mod_proxy.

В качестве примера, если у вас есть сервер Microsoft Exchange во внутренней локальной сети, но вы хотите предоставить доступ к пользователям Интернета для Outlook Web Access (OWA), вы можете поместить ваш сервер в DMZ (НЕ РЕКОМЕНДУЕТСЯ) или открыть порты в брандмауэре во внутреннюю сеть. С обратным прокси-сервером вы должны поместить обратный прокси-сервер в свою DMZ, и все запросы OWA направлены на обратный прокси-сервер. Затем он принимает этот запрос и перенаправляет его на сервер Exchange, действуя как средний человек.

С Apache mod_proxy и именованными виртуальными узлами вы можете отменить прокси-сервер для нескольких сайтов с одним IP-адресом в зависимости от того, задействован ли SSL.

Таким образом, ваши серверы и данные защищены, сохраняя при этом безопасный доступ.

Обратные прокси также часто используются для кэширования дорогостоящих ресурсов; это позволяет вам генерировать заданную страницу один раз в минуту (например) вместо одного запроса. Для сайтов с высоким трафиком это может быть важным преимуществом, особенно для домашней страницы; многие сайты видят, что 70% их трафика переходят на главную страницу, а не дальше. Обратный прокси-сервер кэширования может прозрачно передавать статическую версию этой страницы конечному пользователю без необходимости переписывать приложение.

Прокси-сервер (по существу) является промежуточным для транзакции или запроса. Стандартное использование сети «прокси» — это промежуточный элемент, который защищает идентификатор /местоположение /etc. запроса создатель . «Обратный прокси» является промежуточным звеном, который защищает запрос target . «Прозрачный прокси» не защищает обе стороны.

Другие технологии (такие как балансировка нагрузки, фильтрация пакетов, кэширование и т. д.) могут быть объединены с прокси-технологией (как отмечалось другими) значительно повысить безопасность и производительность.

Обратный прокси так называется, потому что он действует как прокси для входящих запросов из-за пределов локальной сети. Обычный прокси (например, Squid или MS ISA) действует как прокси-сервер для исходящих запросов из локальной сети.

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

Чем различаются прямой и обратный прокси / The Difference Between a Reverse Proxy and a Forward Proxy

The Difference Between a Reverse Proxy and a Forward Proxy

Чем различаются прямой и обратный прокси

Proxies mediate all kinds of online connections. Various proxy types deal with different dimensions of those connections. Some indicate what devices act as proxy servers or how they handle privacy and data management. Other proxy types denote the relation of clients and the proxy server. This last type – the structural position of a proxy – is what makes a proxy either a reverse proxy or a forward proxy . And it’s not hard to know which is which when you know the difference.

Прокси выполняют роль посредника при всевозможных онлайн-соединениях. Прокси делятся на виды по разным критериям. Вид прокси зависит от типа устройства, которое действует как прокси-сервер, уровня анонимности клиента при использовании прокси, способа управления данными. В соответствии с еще одним критерием — расположением прокси в структуре сети — прокси делятся на обратные и прямые.

We run a reverse proxy network, so it’s only natural that we get asked what are the differences between a reverse proxy server and a forward proxy server. In reality, those two are so different that they cannot be easily compared. In any case, we will do our best to tell you what is a reverse proxy, as well as what is a forward proxy in this short article.

Отличить один от другого несложно, если знать их особенности. Наша статья поможет разобраться.

What is a forward proxy

A forward proxy is what most people call ‘a proxy’. You send a connection request to it, and the forward proxy retrieves data from the internet. It usually lets clients on an otherwise firewall-restricted network to access the internet.

Прямой прокси

Когда говорят о прокси, чаще всего имеют ввиду именно прямой прокси. Запрос от клиента направляется на прокси-сервер, который в ответ перенаправляет данные из Интернета. Так клиент может обойти ограничения межсетевого экрана.

With a forward proxy you send a connection request through it, and it retrieves data from the internet.

При использовании прямого прокси запрос от клиента направляется на прокси-сервер, который в ответ перенаправляет данные из Интернета.

What is a reverse proxy

Reverse proxies control access to a server on private networks. A reverse proxy can perform authentication tasks, as well as cache or decrypt data.

Обратный прокси

Обратный прокси контролирует доступ к серверу локальной сети. Такой прокси может выполнять аутентификацию, а также кэшировать или расшифровывать данные.

A reverse proxy can perform authentication tasks, as well as cache or decrypt data. In essence, a reverse proxy is a gateway to a server or group of servers.

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

Forward vs reverse proxies

As we’ve said, you cannot really compare the two. Though their names seem to deal with the same dimension, it only concerns the position of the proxy in the client-service connection. As intermediaries, they are in opposite sides of the connection.

Прямой vs обратный прокси

Сложно сравнить два этих вида прокси. Они выполняют роль посредника на противоположных сторонах связи.

A forward proxy is the intermediary that the client puts forward between itself and any server. The reverse proxy is at the other end – something the server puts forward between itself and any client.

Прямой прокси используется клиентом для доступа к серверу. Обратный прокси-сервер наоборот отделяет сервер внутренней сети от клиента.

По сути, прямой и обратный прокси-серверы выполняют разные задачи, но они оба:

Benefits of a forward proxy

A forward proxy is what most people simply call proxies. Proxies are great for avoiding country restrictions , like the great firewall of China. The client simply connects to blocked resources via the forward proxy.

Преимущества прямого прокси

Когда говорят о прокси, чаще всего имеют ввиду именно прямой прокси. Прокси помогают обходить государственные блокировки , такие как «Великий китайский файрвол». Клиент просто подключается к заблокированным ресурсам через прямой прокси-сервер.

Benefits of a reverse proxy

Reverse proxies are excellent at balancing server loads and serving cached site versions. As an intermediary point between a web server’s back-end and the client, the reverse proxy is a vital point for directing and managing incoming requests.

Преимущества обратного прокси

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

Владельцы серверов могут использовать обратный прокси чтобы скрыть часть серверов, доступ к которым разрешает обратный прокси. Для клиентов прокси будет выглядеть как конечный сервер. А кешированная версия сайта на обратном прокси-сервере повысит скорость вашего сайта.

Reverse proxy servers

Proxy servers like ours use a reverse proxy to give access the whole proxy pool. It is called a backconnect proxy server , because it gives you a single connection point to use for a rotating proxy pool. Backconnect proxy servers make proxy lists obsolete and unnecessary.

Read more about various types of proxies on our blog .

Обратные прокси-серверы

Прокси-сервер с обратным подключением ( backconnect proxy server) позволяет использовать одну точку подключения для пула вращающихся прокси. Благодаря таким прокси-серверам можно больше не использовать прокси-листы.

Подробнее о различных типах прокси читайте в нашем блоге.

Переводчик: ИТ-маркетинговый стажер-переводчик БП «Альянс ПРО» Бедретдинова Диана

Обратный прокси-сервер в Azure Service Fabric

Обратный прокси-сервер, встроенный в Azure Service Fabric, помогает микрослужбам, работающим в кластере Service Fabric, обнаруживать другие службы с конечными точками HTTP и взаимодействовать с этими службами.

Модель взаимодействия с микрослужбами

Микрослужбы в Service Fabric выполняются на подмножестве узлов в кластере и по различным причинам могут перемещаться между ними. Поэтому конечные точки для микрослужб могут динамически изменяться. Чтобы обнаружить другие службы в кластере и взаимодействовать с ними, микрослужбам требуется выполнить следующие действия:

1. Разрешение расположения службы через службу именования.
2. Подключение к службе.
3. Заключение описанных выше шагов в цикл, который реализует разрешение службы и политики повтора при сбое подключения.

Обмен данными с использованием обратного прокси-сервера

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

Обратный прокси-сервер предоставляет службам клиента одну или несколько конечных точек на локальном узле для отправки запросов к другим службам.

Поддерживаемые платформы

Обратный прокси-сервер в Service Fabric в настоящее время поддерживает следующие платформы:

• Кластер Windows: Windows 8 и более поздней версии или Windows Server 2012 и более поздней версии;
• Кластер Linux: сейчас обратный прокси-сервер для кластеров Linux недоступен.

Обращение к микрослужбам извне кластера

По умолчанию микрослужбы для внешнего взаимодействия используют модель участия: к любой службе нельзя получить доступ напрямую из внешних клиентов. Azure Load Balancer — это граница сети между микрослужбами и внешними клиентами, которая выполняет преобразование сетевых адресов и пересылает внешние запросы к внутренним конечным точкам «IP-адрес:порт». Чтобы внешние клиенты могли напрямую обращаться к конечной точке, нужно сначала настроить подсистему балансировки нагрузки для пересылки трафика каждого порта, используемого службой в кластере. Более того, большая часть микрослужб, особенно микрослужбы с отслеживанием состояния, не выполняется на всех узлах кластера. Микрослужбы могут перемещаться между узлами при отработке отказа. В таких случаях подсистема балансировки нагрузки не может эффективно определить расположение целевого узла реплик, к которым следует пересылать трафик.

Обращение к микрослужбам через обратный прокси-сервер извне кластера

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

Настройка порта обратного прокси-сервера в подсистеме балансировки нагрузки обеспечит адресацию извне кластера всех микрослужб в этом кластере, которые предоставляют конечную точку HTTP. Это означает, пользователь-злоумышленник может обнаружить внутренние микрослужбы. Это представляет серьезную уязвимость, например:

• Пользователь-злоумышленник может многократно выполнять атаку типа «отказ в обслуживании», вызывая внутреннюю службу, у которой нет достаточно защищенного направления атак.
• Пользователь-злоумышленник может доставлять неправильно сформированные пакеты во внутреннюю службу, вызывая непредвиденное поведение.
• Внутренняя служба может возвращать персональные или конфиденциальные сведения, не предназначенные для предоставления службам вне кластера, в результате чего пользователь-злоумышленник может завладеть подобной информацией.

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

Формат универсального кода ресурса (URI) для адресации служб через обратный прокси-сервер

Обратный прокси-сервер использует определенный формат универсального кода ресурса (URI), чтобы определять, в какую секцию службы следует перенаправить входящий запрос.

http(s). Обратный прокси-сервер можно настроить для приема трафика HTTP или HTTPS. После настройки обратного прокси-сервера для прослушивания по протоколу HTTPS ознакомьтесь со сведениями о переадресации HTTPS в статье Подключение к безопасной службе с помощью обратного прокси-сервера.

Cluster FQDN | internal IP. Для внешних клиентов обратный прокси-сервер можно настроить таким образом, чтобы он был доступен через домен кластера (например, mycluster.eastus.cloudapp.azure.com). По умолчанию обратный прокси-сервер выполняется на каждом узле. Для внутреннего трафика он может быть доступен на узле localhost или по IP-адресу любого внутреннего узла (например, 10.0.0.1).

Port. Порт, например 19081, указанный для обратного прокси-сервера.

ServiceInstanceName. Полное имя развернутого экземпляра службы, к которому вы пытаетесь получить доступ, без использования схемы fabric:/. Например, чтобы подключиться к службе fabric:/myapp/myservice/, используется имя myapp/myservice.

В имени экземпляра службы учитывается регистр. Использование символов разного регистра в имени экземпляра службы в URL-адресе приводит к сбою запросов с ошибкой «404 (не найдено)».

Suffix path. Фактический URL-адрес службы, к которой вы подключаетесь, например myapi/values/add/3.

PartitionKey. Для секционированной службы это вычисляемый ключ секции, к которой вы подключаетесь. Обратите внимание, что это не идентификатор GUID секции. Этот параметр не является обязательным для служб, использующих схему одноэлементного секционирования.

PartitionKind. Схема секционирования службы. Это может иметь значение «Int64Range» (Диапазон Int64) или «Named» (Именованная). Этот параметр не является обязательным для служб, использующих схему одноэлементного секционирования.

ListenerName. Конечные точки, представляемые службой, имеют следующий вид: <"Endpoints":<"Listener1":"Endpoint1","Listener2":"Endpoint2" . >> Если служба представляет несколько конечных точек, то данный параметр определяет, к которой из них следует перенаправить клиентский запрос. При наличии только одного прослушивателя потребность в данном параметре отсутствует.

TargetReplicaSelector. Данный параметр определяет, каким образом должна быть выбрана целевая реплика или экземпляр.

• Если целевая служба является службой с отслеживанием состояния, то параметр TargetReplicaSelector может иметь значение PrimaryReplica, RandomSecondaryReplica или RandomReplica. Если этот параметр не указан, по умолчанию используется значение PrimaryReplica.
• Если целевая служба является службой без отслеживания состояния, обратный прокси-сервер выбирает случайный экземпляр раздела службы, к которому направляется запрос.

Timeout. Время ожидания HTTP-запроса к службе, созданного обратным прокси-сервером от имени клиентского запроса. Значение по умолчанию — 120 секунд. Этот параметр является необязательным.

Пример использования

Для примера рассмотрим службу fabric:/MyApp/MyService, которая открывает прослушиватель HTTP по приведенному ниже URL-адресу.

Ниже приведены ресурсы для службы.

• /index.html
• /api/users/

Если служба использует схему одноэлементного секционирования, то параметры строки запроса PartitionKey и PartitionKind можно не указывать и к службе можно обратиться через шлюз следующим образом.

• Извне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService
• Изнутри: http://localhost:19081/MyApp/MyService .

Если служба использует схему секционирования Uniform Int64, для обращения к секции службы необходимо использовать параметры строки запроса PartitionKey и PartitionKind.

• Извне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range
• Изнутри: http://localhost:19081/MyApp/MyService?PartitionKey=3&PartitionKind=Int64Range .

Укажите путь к ресурсу после имени службы в URL-адресе, чтобы обратиться к предоставленным службой ресурсам.

• Извне: http://mycluster.eastus.cloudapp.azure.com:19081/MyApp/MyService/index.html?PartitionKey=3&PartitionKind=Int64Range
• Изнутри: http://localhost:19081/MyApp/MyService/api/users/6?PartitionKey=3&PartitionKind=Int64Range .

Затем шлюз перешлет эти запросы по URL-адресу службы.

• http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/index.html
• http://10.0.0.5:10592/3f0d39ad-924b-4233-b4a7-02617c6308a6-130834621071472715/api/users/6

Специальные действия для служб с общим доступом к портам

Обратный прокси-сервер Service Fabric пытается повторно разрешить адрес службы и повторить запрос, если служба недоступна. Как правило, недоступность службы означает, что экземпляр или реплика службы была перемещена на другой узел в ходе обычного жизненного цикла. В этом случае обратный прокси-сервер может получить ошибку сетевого подключения, указывающую, что конечная точка больше не открыта по первоначально разрешенному адресу.

Тем не менее реплики или экземпляры службы могут совместно использовать хост-процесс и даже порт при размещении на веб-сервере на основе http.sys, включая:

В этом случае вполне вероятно, что веб-сервер доступен в хост-процессе и отвечает на запросы, но разрешенный экземпляр или реплика службы больше не доступна на узле. В этом случае шлюз получит от веб-сервера ответ «HTTP 404». Таким образом, ответ «HTTP 404» может иметь два различных значения:

• Случай № 1. Адрес службы указан правильно, но запрошенный пользователем ресурс не существует.
• Случай № 2. Адрес службы указан неправильно, а запрошенный пользователем ресурс может существовать на другом узле.

В первом случае это обычная ошибка «HTTP 404», которая считается ошибкой пользователя. Однако во втором случае пользователь запросил ресурс, который существует. Обратному прокси-серверу не удалось найти его, так как была перемещена сама служба. Обратному прокси-серверу необходимо еще раз разрешить адрес и повторить запрос.

Таким образом, обратному прокси-серверу необходим способ, позволяющий различать эти два случая. Для этого требуется указание от сервера.

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

Чтобы указать обратному прокси-серверу, что это первый случай, служба должна вернуть следующий заголовок ответа HTTP:

Этот заголовок ответа HTTP указывает обычную ситуацию возникновения ошибки «HTTP 404», в которой запрошенный ресурс не существует, и обратный прокси-сервер не будет пытаться повторно разрешить адрес службы.

Специальные действия для служб, запущенных в контейнерах

Чтобы создать URL-адрес обратного прокси-сервера для запущенных в контейнерах служб, можно использовать переменную среды Fabric_NodeIPOrFQDN , как в следующем коде:

По умолчанию переменная Fabric_NodeIPOrFQDN для локального кластера имеет значение localhost. Запустите локальный кластер, указав параметр -UseMachineName , чтобы гарантировать, что контейнеры имеют доступ к обратному прокси-серверу, работающему на узле. Дополнительные сведения см. в разделе Настройка среды разработчика для отладки контейнеров.

В чем разница между прокси и обратным прокси? | Как использовать обратный прокси-сервер для управления доступом

Главное меню » Сервера » В чем разница между прокси и обратным прокси? | Как использовать обратный прокси-сервер для управления доступом

Что такое прокси сервер?

Прокси-сервер, иногда называемый прямым прокси-сервером, – это сервер, который направляет трафик между клиентом (-ами) и другой системой, обычно внешней по отношению к сети. Таким образом, он может регулировать трафик в соответствии с предустановленными политиками, преобразовывать и маскировать IP-адреса клиентов, применять протоколы безопасности и блокировать неизвестный трафик.

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

Что такое обратный прокси?

Обратный прокси-сервер – это разновидность прокси-сервера. В отличие от традиционного прокси-сервера, который используется для защиты клиентов, обратный прокси-сервер используется для защиты серверов. Обратный прокси-сервер – это сервер, который принимает запрос от клиента, перенаправляет запрос на другой из многих других серверов и возвращает результаты с сервера, который фактически обработал запрос, клиенту, как если бы прокси-сервер сам обработал запрос. Клиент напрямую связывается только с обратным прокси-сервером и не знает, что какой-то другой сервер действительно обработал его запрос.

Традиционный прямой прокси-сервер позволяет нескольким клиентам направлять трафик во внешнюю сеть. Например, у компании может быть прокси-сервер, который направляет и фильтрует трафик сотрудников в общедоступный Интернет. Обратный прокси-сервер, с другой стороны, направляет трафик от имени нескольких серверов.

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

Конфигурация обратного прокси

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

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

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

Пример использования: адаптация и отключение

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

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

Настройка обратного прокси для управления доступом

Хотя обратный прокси-сервер может значительно упростить процесс управления доступом к сети, его настройка и правильная настройка могут быть сложными. Для этого требуется подготовить хост с соответствующими спецификациями, настроить операционную систему и брандмауэр, решить, какое программное обеспечение прокси использовать (например, NGINX или HAProxy), перечислить и настроить нижестоящие серверы в файлах конфигурации прокси, настроить ведение журнала аудита и настроить брандмауэры на всех нижестоящих серверах.

Администратору потребуется оптимизировать программное обеспечение прокси-сервера, чтобы оно соответствовало требованиям к производительности и доступности. Например, при выходе из строя нижестоящего сервера администратор должен настроить прокси-сервер для быстрого перенаправления трафика, чтобы избежать простоев.

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

Создание обратного прокси вручную или покупка программного обеспечения

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

Помимо стандартных возможностей обратного прокси, программное обеспечение для управления доступом дает ряд уникальных преимуществ:

1. Гибкость с доступом пользователей. Абстрагируясь от сложности межсетевых экранов и контроля доступа, программное обеспечение для управления доступом может предоставлять концепции более высокого уровня, такие как группы пользователей. Эта функция позволяет администраторам легко назначать и удалять пользователей из различных предопределенных групп и позволяет программному обеспечению автоматически реализовывать политики доступа.
2. Разработан для повышения надежности. В распределенных системах серверы могут выходить из строя, и могут происходить перебои в работе сети. Программное обеспечение для управления доступом легко обнаруживает отказавшие серверы и перенаправляет трафик на работающие, чтобы избежать заметных простоев для пользователей.
3. Возможности балансировки нагрузки. Отдельные серверы могут столкнуться с проблемами при большом объеме трафика, что снижает производительность и увеличивает задержку запросов. Программное обеспечение для управления доступом может помочь управлять трафиком и балансировать нагрузку на всех серверах, обеспечивая его равномерное распределение.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Обратный прокси

Технология обратного прокси (реверс-прокси, reverse-proxy) позволяет проксировать веб-трафик в обратном направлении: из сети Интернет в локальную сеть, в отличие от наиболее часто используемого варианта — из локальной сети в Интернет.
Обратное проксирование применяется для публикации веб-ресурсов, размещенных в локальной сети, таким образом, чтобы они стали доступны потребителям из сети Интернет. Такой подход заменил портмаппинг (DNAT) и расширил возможности по публикации веб-ресурсов.

Для публикации веб-ресурсов в локальной сети (по портам 80 и 443) всегда используйте обратный прокси. Не используйте портмаппинг (DNAT) в файрволе.

Обратный прокси отличается от DNAT тем, что работает на более высоком уровне (прикладной протокол HTTP вместо сетевого протокола IP) и позволяет более гибко реализовать публикацию ресурсов. Основным параметром при публикации веб-ресурса является « входящий URL » . Из внешней сети по протоколу HTTP и данному URL будет произведено обращение на UTM. Обратный прокси позволяет « смаршрутизировать » (http-routing) такой запрос на HTTP-сервер в локальной сети. Таким образом, имея одну ресурсную A-запись для внешнего сетевого интерфейса UTM, можно опубликовать несколько ресурсов в локальной сети, распределив их по нескольким входящим URL. Если же с внешним IP-адресом UTM ассоциировано несколько A-записей, то маршрутизация становится еще более простой, а входящие URL — более удобными для посетителей ресурсов.

Также обратный прокси в составе UTM позволяет перенаправлять все HTTP-запросы на HTTPS-схему. Это нужно если, например, ваш сайт работает только по HTTPS (современная тенденция в веб-безопасности), но при этом вы не хотите терять посетителей, обратившихся к вашему сайту по HTTP-схеме.

Веб-интерфейс настройки модуля достаточно прост и состоит из двух частей:

Системное правило для публикации веб-почты

Описывает доступ к встроенному веб-клиенту почтового сервера на UTM (на основе Roundcube). Так называемая внешняя веб-почта. Теперь при настройке веб-почты в разделе «Сервер — Почтовый сервер» вам нужно также указать URL, с которого будет производиться роутинг на веб-сервер, обслуживающий почтовый веб-клиент в составе UTM.
В примере ниже это yourdomain.ru/mail. Учтите, что у вас должна быть настроена A-запись для внешнего IP-адреса UTM, которая позволяет резолвить адрес в указанный домен, чтобы была возможность обратиться к шлюзу по этому доменному имени.
/mail — это URL, выделенный для сервиса веб-почты. Ниже мы рассмотрим пример выделения URL /owa для публикации exchange-сервера в локальной сети при обращении на тот же домен yourdomain.ru.
Запись вида 0.0.0.0/URL нужна, чтобы веб-почта отвечала при обращении на любой внешний IP UTM. 0.0.0.0, в данном конкретном случае, можно читать как «любой внешний адрес UTM». Может быть удобно при динамическом внешнем IP, выдаваемом UTM провайдером, или при множестве настроенных внешних IP-адресов на внешних интерфейсах UTM.
Удалить системное правило для веб-почты нельзя.

Блок пользовательских правил

Вы можете создать неограниченное количество правил публикации внутренних веб-ресурсов в этом блоке.
Ниже на фрагменте экрана приведена типичная конфигурация: Публикация сайта в локальной сети по обращению к внешнему доменному имени (yourdomain.ru) и публикация веб-интерфейса управления почтовым сервером exchange по дополнительному URL (website.local).
Для сайта в примере дополнительно производится перенаправление всех обращений по схеме HTTP от посетителя на HTTPS.
В верхнее поле Сертификат следует загружать цепочку сертификатов для внешнего домена, доступного из Интернет. В нижнее, если локальный веб-сервер того требует, самоподписанный сертификат (цепочку сертификатов) для локального домена, доступного из внутренней сети. В большинстве случаев достаточно загрузить только внешнюю цепочку сертифкатов.

Публикация Outlook Web Access

Для версий Microsoft Exchange 2007, 2010 возможна публикации OWA с помощью включения специальной дополнительной настройки — «Outlook Web Access» при создании пользовательской записи обратного прокси-сервера.

При этом в Exchange должна быть настроена аутентификация пользователей через форму.

Публикация Outlook Web Access stream

Прямой способ публикации веб-ресурсов, практический аналогичный DNAT, но с возможностью использования сертификатов обратного прокси-сервера для публикации HTTPS-ресурсов.
Подходит для публикации Microsoft Exchange 2013 и других веб-приложений.

При создании пользовательских правил укажите в доп. настройках «Outlook Web Access stream. В полях «Запрос на адрес» и «Перенаправить на» укажите только домены https://youdomain/ без остальной части URL (она не используется при публикации этим способом).
При использовании данного метода возможна публикация только одного веб-ресурса. Все остальные правила обратного прокси-сервера одновременно с этим правилом работать не будут.

При публикации Outlook Web Access не включайте Web Application Firewall. Их совместная работа будет возможна в следующих версиях.

Если у вас имеется доверенный SSL сертификат для домена, по которому будет идти обращение извне на публикуемый ресурс, подготовьте его как связку сертификатов и поместите на UTM, загрузив в поле «Сертификат» под текстовым полем «Домен и путь». Сертификаты нужно загружать в формате PEM.

Доменные имена, указываемые в «Домен и путь», должны резолвиться во внешний IP сервера UTM.
Доменные имена, указываемые в «Назначение», должны резолвиться в IP-адреса публикуемых ресурсов самим сервером UTM.