← Cloudflare One / cloudflare-one / networks / resolvers-and-proxies

Конечные точки прокси

Конечные точки прокси позволяют применять политики Gateway без установки клиента на ваши устройства. Настроив Файл автоматической настройки прокси (PAC) на уровне браузера, вы можете направлять трафик через Gateway для фильтрации и применения политик. Cloudflare поддерживает настройку двух типов прокси-конечных точек: основанных на идентичности конечные точки авторизации и конечные точки прокси с исходным IP.

Когда использовать конечные точки прокси

Конечные точки прокси предназначены для сред, где развертывание Cloudflare One Client невозможно. Типичные сценарии использования включают:

Виртуальные рабочие столы (VDI): пользователи входят в виртуальную машину и используют браузер для выхода в интернет.
Конечные точки с ограничениями по соответствию требованиям: Среды, в которых установка ПО на конечную точку юридически или технически запрещена.
Миграция с устаревшего SWG: Организации, переходящие с устаревших Secure Web Gateway, использующих PAC-файлы.

Логирование

Трафик, отправленный через прокси-эндпоинты, создает Zero Trust Network Session Logs, которые доступны через Logpush и Log Explorer.

Что такое PAC-файл

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

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

PAC-файлы имеют несколько преимуществ:

Централизованное управление: Обновляйте правила маршрутизации в одном месте, не перенастраивая отдельные устройства
Гибкая маршрутизация: Направьте разные типы трафика через разные прокси или прямые подключения в зависимости от домена, диапазона IP-адресов или протокола
Load balancing: Распределяйте трафик между несколькими прокси-серверами с автоматическим аварийным переключением

Types of proxy endpoints

Cloudflare One предлагает два типа конечных точек прокси, у каждого свой метод авторизации.

После создания proxy endpoint изменить его тип нельзя. Если нужен другой метод авторизации, потребуется создать новый proxy endpoint.

Конечная точка авторизации

Конечные точки авторизации используют Cloudflare Access для предоставления авторизации Zero Trust. Пользователи должны пройти аутентификацию через поставщика идентификации и соответствовать политикам Access, прежде чем они смогут использовать прокси-конечную точку.

Используйте конечные точки авторизации, если:

Вам нужна аутентификация на уровне пользователя и политики на основе идентификации
Вы хотите связать конкретных пользователей с их проксируемым трафиком
Ваша организация требует входа через поставщиков идентификации (например, Okta, Microsoft Entra ID или Google Workspace)
Вам нужен детальный контроль над тем, кто может обращаться к прокси

Конечная точка исходного IP

Конечные точки исходного IP авторизуют трафик на основе IP-адреса источника. Использовать конечную точку прокси может только трафик с заранее настроенных IP-адресов.

Используйте конечные точки по исходному IP, если:

У вас есть фиксированный набор офисов или сетевых площадок
Вам нужна более простая настройка без аутентификации пользователей
Ваши устройства используют общий исходящий IP-адрес
Идентифицировать отдельных пользователей не обязательно

1. Создайте proxy endpoint

Конечная точка авторизации

Чтобы добавить конечная точка авторизации:

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси, затем перейдите в Конечные точки прокси.
В Конечные точки прокси, выберите Добавьте endpoint.
Выберите Добавьте endpoint авторизации.
Назовите endpoint.
Добавить Политики доступа чтобы управлять тем, кто может получить доступ к вашим приложениям. Вы можете выбрать существующие политики или создать новые.
Выберите, какие способы входа поддерживать. Чтобы разрешить все способы входа, включите Принимать все доступные провайдеры идентификации.
(Необязательно) Если настроен только один поставщик идентификации, включите Применить мгновенную аутентификацию чтобы пропустить выбор поставщика удостоверений, когда пользователи достигают конечной точки прокси.
Выберите Создание.

Конечная точка исходного IP

Чтобы добавить конечная точка исходного IP:

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси, затем перейдите в Конечные точки прокси.
В Конечные точки прокси, выберите Добавьте endpoint.
Выберите Добавьте endpoint исходного IP-адреса.
Назовите endpoint.
Добавьте исходные IP-адреса своих устройств в нотации CIDR. Например:
- IPv4: 192.0.2.0/8
- IPv6: 2001:0db8:0000:0000:0000:1234:5678:0000/32
Выберите Сохранить конечную точку.

Конечная точка авторизации

Чтобы создать endpoint авторизации:

Используйте Создайте Proxy Endpoint со следующим вызовом:

Создать конечную точку прокси

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/proxy_endpoints" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"kind": "identity",
		"name": "any_name"
	}'

Ответ возвращает результат, похожий на следующий:
Пример вывода
```
{
	"result": {
		"kind": "identity",
		"id": "d969d7bf-ec28-4291-9af0-86825f472c21",
		"name": "Identity Proxy Endpoint",
		"created_at": "2014-01-01T05:20:00.12345Z",
		"updated_at": "2014-01-01T05:20:00.12345Z",
		"subdomain": "3ele0ss56t"
	},
	"success": true,
	"errors": [],
	"messages": []
}
```
Обратите внимание на subdomain значение, возвращённое API. Вы будете использовать его для создания приложения Access.
Используйте Добавление приложения Access чтобы связать конечную точку прокси с политиками Access:
Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:
- Access: Apps and Policies Write
Добавьте приложение Access
```
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/apps" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"domain": "<SUBDOMAIN>.proxy.cloudflare-gateway.com",
		"name": "Proxy Endpoint App",
		"session_duration": "12h",
		"type": "proxy_endpoint",
		"policies": [
				{
						"id": "<ACCESS_POLICY_ID>"
				}
		]
	}'
```
Замените <SUBDOMAIN> с поддоменом из шага 2 и <ACCESS_POLICY_ID> с ID уже существующего Политика Access.

Конечная точка исходного IP

Чтобы создать конечную точку исходного IP-адреса:

Используйте Create A Proxy Endpoint со следующим вызовом:
Создать конечную точку прокси
```
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/proxy_endpoints" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "any_name",
		"ips": [
				"<PUBLIC_IP>",
				"<PUBLIC_IP2>",
				"<PUBLIC_IP3>"
		]
	}'
```
Замените <PUBLIC_IP> с исходным IP-адресом вашего устройства в нотации CIDR. Например:
- IPv4: 192.0.2.0/8
- IPv6: 2001:0db8:0000:0000:0000:1234:5678:0000/32
Примечание
Примечание
Gateway ограничивает длину префикса исходных сетей для конечных точек прокси значением /8 для сетей IPv4 и /32 для сетей IPv6.
Ответ возвращает результат, похожий на следующий:
Пример вывода
```
{
	"result": {
		"id": "d969d7bf-ec28-4291-9af0-86825f472c21",
		"name": "test",
		"created_at": "2022-03-02T10:57:18.094789Z",
		"updated_at": "2022-03-02T10:57:18.094789Z",
		"ips": ["90.90.241.229/8"],
		"subdomain": "3ele0ss56t"
	},
	"success": true,
	"errors": [],
	"messages": []
}
```
Обратите внимание на subdomain значение, возвращённое API. Домен вашего прокси-сервера Cloudflare имеет следующий вид:
```
<SUBDOMAIN>.proxy.cloudflare-gateway.com
```
В примере выше поддомен 3ele0ss56t а домен прокси-сервера: 3ele0ss56t.proxy.cloudflare-gateway.com.

2. Создайте PAC-файл

PAC-файл представляет собой текстовый файл на JavaScript, который определяет, какой трафик нужно перенаправлять на прокси-сервер. Вы можете создать PAC-файл на панели управления Cloudflare или написать собственный PAC-файл.

Создайте размещённый файл PAC

Когда вы создаете PAC-файл в Cloudflare One, Cloudflare размещает его в общедоступном Worker. Размещенные PAC-файлы автоматически распространяются по глобальной сети Cloudflare.

Чтобы создать размещённый PAC-файл:

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси.
Выберите Конечные точки прокси.
Создать конечную точку прокси или выберите существующий, затем выберите Изменить.
Выберите Добавление PAC-файлов.
Настройте свой файл PAC:

В Сведения о PAC-файле:
1. Введите Основная информация, включая имя и необязательное описание.
2. (Необязательно) Настройте URL slug чтобы создать запоминающийся URL-путь. Slug нельзя изменить после создания.
3. В Настройка PAC-файла, выберите Просмотр шаблонов конфигурации PAC-файла и выберите предварительно настроенный шаблон для доработки. Доступны шаблоны Okta и Azure. После выбора шаблона JavaScript PAC-файла заполнится выбранным шаблоном.
4. При необходимости измените код JavaScript в соответствии с требованиями вашей сети.
В Инструкции по настройке:
1. Выберите браузер.
2. Следуйте инструкциям в Cloudflare One, чтобы настроить устройства.
Выберите Создание.

URL-адрес вашего размещенного PAC-файла будет следующим:

https://pac.cloudflare-gateway.com/<account-id>/<slug>

Где:

<account-id> это ваш Cloudflare account ID
<slug> является настраиваемым путём, который вы указали (или автоматически сгенерированным значением, если он не настроен)

Ограничения размещенных PAC-файлов

PAC-файлы, размещенные на стороне Cloudflare, имеют следующие ограничения:

Максимальный размер файла: 256 КБ на PAC-файл
Максимальное количество файлов PAC на аккаунт: 50 (для тарифов, отличных от Enterprise) или 1,000 (для тарифов Enterprise)
Распространение обновления: Изменения PAC-файлов распространяются по глобальной сети в течение периода от нескольких секунд до нескольких минут

Поведение при кешировании

Размещенные PAC-файлы кэшируются по всему миру для повышения производительности и надежности:

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

Локальное размещение PAC-файлов

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

Ограничения конечной точки прокси

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

Тарифные планы, отличные от Enterprise: 50 конечных точек прокси
Планы Enterprise: 500 конечных точек прокси

3. Настройте свои устройства

3a. Установите сертификат Cloudflare

Вы должны установить сертификат Cloudflare на ваших устройствах. Endpoints авторизации используют сертификат для проверки TLS-трафика и чтения файла cookie авторизации. Endpoints исходного IP используют сертификат для применения HTTP-политик Gateway, например для блокировки определённых доменов или отображения страницы блокировки Gateway.

3b. Настройте браузер для использования PAC-файла

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

Подробные инструкции для конкретных ОС (включая Windows, macOS, Linux, iOS, Android, ChromeOS и корпоративное развёртывание) см. в Настройте PAC-файл на своём устройстве.

Браузеры на основе Chromium

Браузеры на основе Chromium (например, Google Chrome, Microsoft Edge и Brave) используют настройки прокси-сервера операционной системы. Настройте URL PAC-файла в своих настройки прокси операционной системы.

Mozilla Firefox

Firefox использует собственные настройки прокси и по умолчанию не наследует конфигурацию прокси операционной системы. Firefox необходимо настраивать отдельно. Пошаговые инструкции см. в Настройте Firefox отдельно.

Safari

4. Протестируйте свою политику HTTP

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

Теперь можно использовать селектор Proxy Endpoint в сеть и HTTP политики для фильтрации трафика, проксируемого через PAC-файлы.

5. (Необязательно) Настройте межсетевой экран

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

Чтобы получить домен конечной точки прокси:

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси > Конечные точки прокси.
Выберите proxy endpoint. Нажмите Изменить.
В Proxy Endpoint, скопируйте домен.

Используйте List proxy endpoints операцию, чтобы получить список ваших proxy endpoint и информацию о них. Например:

List proxy endpoints

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/proxy_endpoints" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

{
	"success": true,
	"result": {
		"id": "ed35569b41ce4d1facfe683550f54086",
		"created_at": "2014-01-01T05:20:00.12345Z",
		"ips": ["192.0.2.1/32"],
		"name": "DevOps team",
		"subdomain": "oli3n9zkz5.proxy.cloudflare-gateway.com",
		"updated_at": "2014-01-01T05:20:00.12345Z"
	}
}

Найдите конечную точку прокси, которую вы хотите использовать.
Скопируйте значение subdomain ключ.

Используя домен своей конечной точки прокси, вы можете получить IP-адреса, назначенные этой конечной точке:

Откройте терминал.
Запустите dig на A-записях вашего proxy endpoint, чтобы получить его IPv4-адреса. Например:
```
dig A example.cloudflare-gateway.com +short
```
```
162.159.36.5
162.159.36.20
```
Запустите dig на AAAA-записях вашего proxy endpoint, чтобы получить его IPv6-адреса. Например:
```
dig AAAA example.cloudflare-gateway.com +short
```
```
2606:4700:54::a29f:2407
2606:4700:5c::a29f:2e07
```

Откройте терминал PowerShell.

Запустите Resolve-DnsName на A-записях вашего proxy endpoint. IPv4-адреса вашего proxy endpoint появятся в разделе IPAddress. Например:

Resolve-DnsName -Name example.cloudflare-gateway.com -Type A

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
example.cloudflare-gateway.com                 A      300   Answer     162.159.36.5
example.cloudflare-gateway.com                 A      300   Answer     162.159.36.20

Запустите Resolve-DnsName на AAAA-записях вашего proxy endpoint. IPv6-адреса вашего proxy endpoint появятся в разделе IPAddress. Например:

Resolve-DnsName -Name example.cloudflare-gateway.com -Type AAAA

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
example.cloudflare-gateway.com                 AAAA   300   Answer     2606:4700:5c::a29f:2e07
example.cloudflare-gateway.com                 AAAA   300   Answer     2606:4700:54::a29f:2407

Чтобы ответы проходили через ваш межсетевой экран, добавьте входящее правило, разрешающее статический IPv4-адрес для прокси-эндпоинтов Cloudflare, 162.159.193.21.

Измените конечные точки прокси

Настройки proxy endpoint можно изменить после создания.

Измените конечную точку авторизации

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси > Конечные точки прокси.
Найдите конечную точку авторизации (обозначенную Авторизация в разделе Type).
Выберите три точки, затем выберите Настройте.
Выберите, что нужно изменить:
- Основная информация: Обновите имя и описание конечной точки.
- Политики доступа: Добавляйте, удаляйте или изменяйте политики Access, которые определяют, кто может использовать эту конечную точку.
- Login methods: Выберите, какой поставщики идентификации пользователи могут проходить аутентификацию.
Выберите Save.

Измените конечную точку исходного IP-адреса

В Cloudflare One ↗, перейдите в Сети > Резолверы и прокси > Конечные точки прокси.
Найдите конечную точку исходного IP-адреса (обозначенную Исходный IP в разделе Type).
Выберите три точки, затем выберите Настройте.
Обновите имя конечной точки или измените разрешённые исходные IP-адреса.
Выберите Save.

Журналы

Трафик конечной точки прокси регистрируется в следующих местах:

Журналы аутентификации: когда пользователи проходят аутентификацию через endpoint авторизации, события входа отображаются в вашем Журналы Access.
Журналы трафика: HTTP- и сетевой трафик, проксируемый через конечную точку, отображается в Журналы Gateway, с указанием конкретного proxy endpoint.

Billing

Каждый пользователь, который проходит аутентификацию через конечную точку прокси авторизации, занимает Место Gateway, так же, как для пользователя, подключённого через Cloudflare One Client.

Ограничения

Ограничения конечной точки авторизации

При использовании конечные точки авторизации, учитывайте следующие ограничения. Инструкции по настройке приложений с закреплением сертификата (certificate pinning) см. в Рекомендации по PAC-файлам.

Требуется проверка TLS

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

HTTP-трафик с открытым текстом

Конечные точки авторизации не поддерживают незашифрованный трафик HTTP, если этот трафик не настроен через Приложение Access или обойдены с помощью PAC-файла.

Трафик заголовка Referer

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

auth-proxy-non-identity@<your-team-name>.cloudflareaccess.com

Где <your-team-name> это ваш название команды.

Это происходит потому, что браузеры не помечают HTTP-подзапросы cookie-файлом идентификации, который используется для проверки аутентификации пользователя. Это стандартное для отрасли поведение прокси-ориентированных защищённых веб-шлюзов.

Чтобы отфильтровать этот трафик, у вас есть два варианта:

Настройте Политика HTTP чтобы заблокировать или разрешить весь трафик, соответствующий auth-proxy-non-identity@<your-team-name>.cloudflareaccess.com адрес электронной почты.
Чтобы ограничить трафик без привязки к удостоверению пользователя конкретными исходными IP-адресами, создайте политика Network который соответствует одновременно исходному IP-адресу и конечной точке прокси.

Safari и iOS не поддерживаются

Safari (на macOS) и все браузеры на iOS/iPadOS не поддерживают тип HTTPS-прокси, который требуется для конечных точек прокси Cloudflare. Это ограничение на уровне платформы, подтверждённое компанией Apple. На macOS вместо Safari используйте браузер на основе Chromium или Firefox. На iOS/iPadOS конечные точки прокси использовать нельзя.

Ограничения трафика

Каждый тип конечной точки прокси поддерживает перечисленные ниже функции:

Возможность	Конечная точка исходного IP	Конечная точка авторизации
Трафик HTTP/HTTPS	✅¹	✅²
TCP-трафик не по HTTP	✅	,
UDP traffic	,	,
HTTP3	,	,
Политики на основе идентификации	,	✅
аутентификация mTLS	,	,
Happy Eyeballs ↗	,	,
Автоматическое обновление HTTPS в браузере	, ³	, ³

Длительность сессии

Все соединения, проксируемые через Cloudflare Gateway, имеют максимальную гарантированную длительность 10 часов. Дополнительную информацию см. в Устранение неполадок.

Политики DNS и резолвера Gateway

Gateway DNS и резолвер политики всегда применяются к трафику, проксируемому через PAC-файлы, независимо от конфигурации устройства.

Сноски

Для конечные точки исходного IP, чтобы обращаться к источникам с обычным HTTP (не HTTPS), настройте их как локально размещённые приложения Access. Это позволяет пользователям обращаться к ресурсам HTTP, сохраняя при этом безопасность за счёт политик Access. ↩
Чтобы получить доступ к источникам с открытым HTTP (не HTTPS) через конечные точки авторизации, см. HTTP-трафик с открытым текстом. ↩
Конечные точки прокси не поддерживают HTTPS, если браузер автоматически повышает HTTP-запросы до HTTPS (например, при автоматическом повышении до HTTPS в Chrome). Если у вас возникают проблемы с подключением к сайтам, для которых выполняется такое автоматическое повышение, может потребоваться отключить автоматическое повышение до HTTPS в настройках браузера или настроить исключение для этого сайта. ↩ ↩²