← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-wan / zero-trust

Cloudflare Gateway

Cloudflare Gateway, наш комплексный Secure Web Gateway, позволяет настраивать политики для проверки DNS, сетевого, HTTP и исходящего трафика.

Вы можете применять политики Gateway для категорий Network и HTTP вместе с Cloudflare Network Firewall политики (для фильтрации трафика на уровнях L3/L4) к трафику, направленному в интернет, или к частному трафику, поступающему в сеть Cloudflare через Cloudflare WAN (ранее Magic WAN). Кроме того, вы можете настроить Gateway так, чтобы разрешать DNS-запросы от Cloudflare WAN.

Чтобы проверять трафик HTTPS, необходимо установить корневой сертификат Cloudflare на каждом клиентском устройстве. Сертификат нужен для того, чтобы Cloudflare мог расшифровывать TLS.

Вы можете использовать Cloudflare One Client к автоматически устанавливать сертификат Cloudflare на поддерживаемых устройствах. Если ваше устройство или приложение не поддерживает установку сертификата через Cloudflare One Client, вы можете вручную установить сертификат.

Если вы не можете или не хотите устанавливать сертификат, вы можете создать Do Not Inspect политики, чтобы исключить несовместимый трафик Cloudflare WAN из проверки или полностью отключить расшифровку TLS.

Поскольку Gateway не может отличить трафик Cloudflare WAN, необходимо использовать Проверки Cloudflare One Client или IP-адреса, связанные с Cloudflare WAN, для сопоставления трафика с политиками Gateway.

Например, если ваша организация подключает устройства к Cloudflare WAN через Cloudflare One Client, вы можете исключить устройства, на которых Cloudflare One Client не запущен, с помощью Проверки версии ОС:

Если ваша организация подключает пользователей к Cloudflare WAN с помощью on-ramp, отличный от Cloudflare One Client, вы можете исключить устройства из проверки, используя IP-адреса ваших туннелей IPsec:

Вы можете настроить DNS-резолвер для ваших сетей Cloudflare WAN на общие IP-адреса DNS-резолвера Gateway. IP-адреса DNS-резолвера Gateway: 172.64.36.1 и 172.64.36.2.

Когда вы разрешаете DNS-запросы от Cloudflare WAN через Gateway, Gateway записывает эти запросы вместе с приватным исходным IP-адресом. Этот приватный исходный IP-адрес можно использовать для создания политики Resolver для запросов, предназначенных для внутренние DNS-записи.

На следующей схеме показано, как DNS-запросы от Cloudflare WAN и Cloudflare Mesh проходят через Gateway к вашему внутреннему DNS:

flowchart LR
accTitle: DNS query flow
accDescr: Shows how DNS queries from Cloudflare WAN and Cloudflare Mesh flow through Gateway to internal DNS.
subgraph subGraph0["Data center"]
  direction TB
      InternalDNS(["Internal DNS"])
      ResolverPolicies["Resolver policies"]
      CloudflareGatewayDNSResolver["Gateway DNS resolver"]
end
  ResolverPolicies -- Retain and use</br>Source Internal IP --> InternalDNS
  CloudflareGatewayDNSResolver -- <br> --> ResolverPolicies
  WarpConnector["Cloudflare Mesh"] -- DHCP/DNS resolver --> IPSecTunnel["IPsec tunnel"]
  CloudflareWAN[Cloudflare WAN] -- DHCP/DNS resolver --> IPSecTunnel
  IPSecTunnel -- Shared IP endpoints --> CloudflareGatewayDNSResolver
  ResolverPolicies@{ shape: proc}
  WarpConnector@{ shape: in-out}
  CloudflareWAN@{ shape: in-out}

По умолчанию следующий трафик, направляемый через туннели IPsec/GRE к публичным IP-адресам, проксируется и фильтруется через Cloudflare Gateway:

• Трафик TCP, UDP и ICMP с источником RFC 1918 ↗ IP-адреса или устройства.
• TCP- и UDP-трафик, исходящий от BYOIP или Арендованные IP-адреса и предназначенного для известного порта (0-1023).

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

Этот трафик будет выходить из Cloudflare согласно Политики Egress которые вы задаёте в Cloudflare Gateway. По умолчанию трафик будет выходить из общего диапазона публичных IP-адресов Cloudflare.

По умолчанию TCP-, UDP- и ICMP-трафик, направляемый через туннели IPsec/GRE к маршрутам за Cloudflare Tunnel будет проксироваться и фильтроваться через Cloudflare Gateway.

Обратитесь в свою команду по работе с аккаунтом, чтобы включить фильтрацию Gateway для трафика, направляемого по маршрутам за туннелями IPsec/GRE.

Если этот параметр включён, трафик TCP/UDP, соответствующий all Cloudflare Gateway будет проксировать и фильтровать трафик, соответствующий следующим критериям:

• IP-адреса источника и назначения: Оба должны входить в RFC1918 ↗ пространство, WARP, BYOIP, или Арендованные IP-адреса.
• Порт источника: Должен быть клиентским портом строго выше 1023.
• Порт назначения: Должен быть общеизвестным портом (менее 1024).

Чтобы переопределить критерии по умолчанию, можно указать более точные условия соответствия:

• Префикс исходного IP: Подмножество адресного пространства RFC1918, BYOIP, или Арендованные IP-адреса.
• Префикс IP-адреса назначения: Подмножество адресного пространства RFC1918, BYOIP, или Арендованные IP-адреса.
• Порт назначения: Любой порт от 0 к 65535.

Чтобы проверить, правильно ли Gateway работает с вашим подключением Cloudflare WAN, откройте браузер на хосте за вашим customer premise equipment и перейдите на https://ifconfig.me.

Если вы всё ещё тестируете Gateway и Cloudflare не является для вас маршрутом по умолчанию, настройте на маршрутизаторе маршрут на основе политики, чтобы трафик сначала направлялся в Cloudflare Gateway.

Убедитесь, что для теста есть запись в Журналы активности HTTP Gateway.

Проверьте следующие данные:

• IP-адрес назначения: Должен быть публичным IP-адресом ifconfig.me.
• Исходный IP: Должен быть приватным (WAN) адресом хоста с браузером.
• Исходящее подключение: Должен быть получен от IP-адреса Cloudflare WAN, а не от любого другого публичного IP-адреса, который Cloudflare может анонсировать от вашего имени.

Это применимо при использовании Magic Transit With Egress Option также.

Кроме того, протестируйте оба http://ifconfig.me (без TLS) и https://ifconfig.me (TLS), чтобы убедиться, что ваш Максимальный размер сегмента TCP (MSS Clamping) настроен правильно.

Если запрос HTTPS зависает или завершается ошибкой, а HTTP при этом работает, значение MSS может быть слишком высоким или не задано. Уменьшите это значение на оборудовании на стороне клиента (CPE) с учётом накладных расходов, вносимых вашим IKE и ESP ↗ настройки.