← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / do-more-with-tunnels / local-management

Файл конфигурации

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

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

При отсутствии файла конфигурации cloudflared будет проксировать исходящий трафик через порт 8080.

Структура файлов для частных сетей

Если вы открытие доступа к приватной сети конечным пользователям, использующим Cloudflare One Client, необходимо добавить warp-routing ключ и установите его в true:

tunnel: <Tunnel-UUID>
credentials-file: /path/<Tunnel-UUID>.json
warp-routing:
  enabled: true

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

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  - hostname: gitlab.widgetcorp.tech
    service: http://localhost:80
  - hostname: gitlab-ssh.widgetcorp.tech
    service: ssh://localhost:22
  - service: http_status:404

Файлы конфигурации, содержащие правила ingress, должны обязательно включать в конце завершающее правило (catch-all rule). В этом примере cloudflared ответит 404 код статуса, если запрос не соответствует ни одному из предыдущих имён хостов.

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

Последнее входящее правило должно быть catch-all-правилом, соответствующим всему трафику.

Ниже приведен пример файла конфигурации, задающего несколько правил:

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  # Rules map traffic from a hostname to a local service:
  - hostname: example.com
    service: https://localhost:8000
  # Rules can match the request's path to a regular expression:
  - hostname: static.example.com
    path: \.(jpg|png|css|js)$
    service: https://localhost:8001
  # Rules can match the request's hostname to a wildcard character:
  - hostname: "*.example.com"
    service: https://localhost:8002
  # An example of a catch-all rule:
  - service: https://localhost:8003

С помощью подстановочных знаков можно сопоставлять трафик с несколькими субдоменами. Например, если задать hostname ключ в *.example.com, оба alpha.example.com и beta.example.com будет направлять трафик к вашему источнику. cloudflared не поддерживает подстановочные знаки в середине имени хоста, например test.*.example.com.

Вы также можете ввести регулярные выражения для path ключ. Например, если hostname это static.example.com и path это \.(jpg|png|css|js)$, к соответствующим URL-адресам могут относиться https://static.example.com/data.js, http://static.example.com/images/photo.jpg, и так далее. Cloudflare разбирает регулярное выражение пути с помощью Перейти syntax пакет ↗.

Помимо HTTP, cloudflared поддерживает такие протоколы, как SSH, RDP, произвольные TCP-сервисы и Unix-сокеты. Вы также можете направлять трафик на встроенный hello_world тестовый сервер или отвечать на трафик статусом HTTP. Полный список поддерживаемых типов служб см. в Протоколы для опубликованных приложений.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json

ingress:
  # Example of a request over TCP:
  - hostname: example.com
    service: tcp://localhost:8000
  # Example of an HTTP request over a Unix socket:
  - hostname: staging.example.com
    service: unix:/home/production/echo.sock
  # Example of a request mapping to the Hello World test server:
  - hostname: test.example.com
    service: hello_world
  # Example of a rule responding to traffic with an HTTP status:
  - service: http_status:404

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

В следующем примере конфигурация верхнего уровня connectTimeout: 30s задаёт тайм-аут подключения в 30 секунд для всех служб в этом экземпляре cloudflared. Входящее правило для service: localhost:8002 затем настраивает исключение для конфигурации верхнего уровня, задав connectTimeout для этой службы по адресу 10s. 30-секундный тайм-аут подключения по-прежнему применяется ко всем остальным службам.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
originRequest: # Top-level configuration
  connectTimeout: 30s

ingress:
  # The localhost:8000 service inherits all root-level configuration.
  # In other words, it will use a connectTimeout of 30 seconds.
  - hostname: example.com
    service: localhost:8000
  - hostname: example2.com
    service: localhost:8001
  # The localhost:8002 service overrides some root-level config.
  - service: localhost:8002
    originRequest:
      connectTimeout: 10s
      disableChunkedEncoding: true
  # Some built-in services such as `http_status` do not use any configuration.
  # The service below will simply respond with HTTP 404.
  - service: http_status:404

Чтобы проверить входящие правила в конфигурационном файле, выполните:

cloudflared tunnel ingress validate

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

Чтобы убедиться, что cloudflared будет проксировать нужный трафик к нужной локальной службе, используйте cloudflared tunnel ingress rule. Это проверяет URL по каждому правилу, от первого до последнего, и показывает первое совпавшее правило. Например:

cloudflared tunnel ingress rule https://foo.example.com

Using rules from /usr/local/etc/cloudflared/config.yml
Matched rule #3
	hostname: *.example.com
	service: https://localhost:8000

При внесении изменений в конфигурационный файл туннеля рекомендуем использовать cloudflared реплики и распространите новую конфигурацию с минимальным временем простоя.

1. Есть cloudflared экземпляр, работающий с исходной версией файла конфигурации.
2. Запустите cloudflared реплику, работающую с обновленной версией файла конфигурации.
3. Подождите, пока реплика полностью не запустится и не станет пригодной для использования.
4. Остановите первый экземпляр cloudflared.

Ваш cloudflared теперь будет работать с обновлённой версией вашего файла конфигурации.