← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / use-cases / ssh

Подключение с использованием собственных ключей SSH

Чтобы управлять собственными SSH-ключами, можно использовать Cloudflare Tunnel для создания защищенного исходящего соединения с сервера в глобальную сеть Cloudflare. Для этого потребуется запустить cloudflared демон на сервере (или любой другой хост-машине в частной сети). Пользователи с ключами SSH, которым доверяет сервер SSH, могут получить доступ к серверу, установив Cloudflare One Client на своём устройстве и регистрации в вашей организации Zero Trust. Пользователи могут подключаться по SSH напрямую к приватному имени хоста сервера (например, ssh.internal.local). Вы контролируете доступ к серверу с помощью политик Gateway на сетевом уровне вместо политик Access на уровне приложений.

Предварительные требования

A Организация Cloudflare Zero Trust
Cloudflare One Client установлено на устройствах пользователей.
Устройства зарегистрировано в вашей организации Zero Trust

1. Создайте тестовый SSH-сервер

В этом примере показано, как настроить сервер SSH на виртуальной машине (ВМ) Google Cloud Platform (GCP), но вы можете использовать любую машину, поддерживающую подключения по SSH. Если у вас уже настроен сервер SSH, можно перейти сразу к Шаг 2.

1.1 Создайте пару SSH-ключей

Прежде чем создавать экземпляр VM, вам потребуется создать пару ключей SSH.

Откройте терминал и введите следующую команду:
```
ssh-keygen -t rsa -f ~/.ssh/gcp_ssh -C <username in GCP>
```
Введите парольную фразу, когда будет предложено. Её нужно будет ввести дважды.

Two files will be generated: gcp_ssh который содержит закрытый ключ, а также gcp_ssh.pub содержит открытый ключ.
В командной строке введите:
```
cat ~/.ssh/gcp_ssh.pub
```
Скопируйте вывод. Он будет использован при создании экземпляра VM в GCP.

1.2 Создайте инстанс VM в GCP

После создания пары SSH-ключей вы можете создать экземпляр виртуальной машины (VM instance).

В вашем Google Cloud Console ↗, создать новый проект ↗.
Перейдите в Compute Engine > экземпляры ВМ.
Выберите Создать инстанс.
Назовите VM-инстанс, например ssh-server.
Прокрутите вниз до Дополнительные параметры > Безопасность > Управлять Access.
В разделе Добавить вручную созданные ключи SSH, выберите Добавить элемент и вставьте созданный вами публичный ключ.
Выберите Создание.
Когда экземпляр виртуальной машины запустится, откройте раскрывающийся список рядом с SSH и выберите Открыть в окне браузера.

2. Подключите сервер к Cloudflare

В этом разделе описано, как создать новый Cloudflare Tunnel для вашего SSH-сервера. Один и тот же туннель можно использовать повторно для всех сервисов приватной сети, доступных из cloudflared хост.

Войдите в панель управления Cloudflare и перейдите в Сеть > Tunnels.
Перейдите в Tunnels ↗
Выберите Создать туннель.
Введите имя туннеля. Рекомендуем выбрать имя, отражающее тип ресурсов, которые вы хотите подключить через этот туннель (например, enterprise-VPC-01).
Выберите Create Tunnel.
Выберите операционную систему, затем скопируйте команду установки и выполните её в терминале на вашем исходном сервере.
Дождитесь подключения туннеля. После установления соединения выберите Продолжение.

3. Используйте маршруты по имени хоста

Маршруты хоста позволяют подключаться по SSH напрямую к ssh.internal.local без управления статическими IP-маршрутами. Маршруты по имени хоста особенно полезны, если IP-адрес вашего SSH-сервера неизвестен или временный, например в случае динамической инфраструктуры, предоставляемой облачными провайдерами.

Как работает маршрутизация по имени хоста

Когда вы создаете маршрут с именем хоста в Cloudflare Tunnel:

Пользователи подключаются по SSH к вашему приватному имени хоста (например, ssh [email protected]).
Gateway разрешает имя хоста в исходный разрешённый IP-адрес.
Трафик проходит через туннель WARP к Cloudflare.
Политики Network Gateway оценивают соединение.
Cloudflared проксирует подключение к приватному IP вашего SSH-сервера.

Если у вас не настроен приватный DNS-резолвер или вы предпочитаете подключаться по SSH к IP-адресу, перейдите к Шаг 4.

3.1 Добавьте маршрут по имени хоста

Чтобы добавить маршрут по имени хоста в туннель:

Перейдите в Сеть > Tunnels и выберите свой туннель.
На Маршруты вкладке выберите Добавить маршрут, затем выберите Частное имя хоста.
Введите имя хоста вашего SSH-сервера (например, ssh.internal.local).
Ограничения формата имени хоста
- Ограничение символов: Должно быть короче 255 символов.
- Поддерживаемые подстановочные знаки: Один подстановочный знак (*) допускается, и она должна представлять собой полную DNS-метку. Пример: *.internal.local
- Неподдерживаемые подстановочные знаки: Следующие форматы подстановочных знаков не поддерживаются:
  - Частичные подстановочные знаки, такие как *-dev.internal.local или dev-*.internal.local.
  - Подстановочные знаки в середине, например foo*bar.internal.local или foo.*.internal.local.
  - Несколько подстановочных знаков в имени хоста, например *.*.internal.local.
- Усечение подстановочных знаков: Начальные подстановочные знаки (*) обрезаются, и неявная точка (.) принимается по умолчанию. Например, *.internal.local сохраняется как internal.local но будет соответствовать всем поддоменам на уровне wildcard (охватывает foo.internal.local но не foo.bar.internal.local).
- Удаление точек: Начальные и конечные точки (.) разрешены, но обрезаются.
Выберите Save.

3.2 Настройте разрешение DNS

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

Сценарий A: использование системного резолвера (по умолчанию)

По умолчанию cloudflared использует приватный DNS-резолвер, настроенный на своей хост-машине (например, в /etc/resolv.conf в Linux). Если машина, на которой запущен cloudflared уже может разрешать ssh.internal.local к его частному IP-адресу с помощью локального системного резолвера, дальнейшая настройка не требуется. Можно сразу перейти к Шаг 3.3.

Проверить локальное разрешение DNS

Чтобы проверить, cloudflared может успешно разрешать ssh.internal.local, выполните следующую команду из cloudflared хост:

nslookup ssh.internal.local

Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	ssh.internal.local
Address: 10.2.0.3

Вывод должен содержать приватный IP-адрес сервера (это Внутренний IP ВМ GCP). Если имя хоста не удаётся разрешить:

Убедитесь, что ваш частный DNS-резолвер содержит запись, указывающую на ssh.internal.local к частному IP-адресу сервера.
В GCP вам может потребоваться Добавьте приватную зону в Cloud DNS ↗ чтобы internal.local разрешается с помощью вашего частного DNS-резолвера.

Сценарий B: использование определённого частного DNS-сервера (расширенный)

Если вам нужно cloudflared чтобы использовать определённый внутренний DNS-сервер, отличный от резолвера узла по умолчанию, необходимо явно подключить этот DNS-сервер к Cloudflare через Маршрут IP/CIDR. Вам также потребуется настроить Политика Resolver в Gateway для маршрутизации запросов на этот конкретный приватный DNS-сервер.

Чтобы создать маршрут IP/CIDR для DNS-сервера:
1. Перейдите в Сеть > Маршруты.
  Перейдите в Маршруты ↗
2. Выберите Добавление маршрута CIDR.
3. Введите приватный IP-адрес вашего внутреннего DNS-резолвера.
4. Выберите Cloudflare Tunnel, который подключается к сети, где находится этот DNS-сервер.
5. Выберите Создание.
Чтобы создать политику Resolver:
1. Перейдите в Политики трафика > Резолвера политики.
2. Выберите Создать политику.
3. Создайте выражение, которое соответствует приватному имени хоста:
  Селектор Оператор Значение
  Host in ssh.internal.local
4. В разделе Настройте пользовательские DNS-резолверы, введите приватный IP-адрес вашего внутреннего DNS-сервера.
5. В раскрывающемся меню выберите - Private параметр маршрутизации и виртуальная сеть назначенная туннелю, который вы выбрали на предыдущем шаге.
6. Выберите Создать политику.

Селектор	Оператор	Значение
Host	in	`ssh.internal.local`

3.3 Настройте Cloudflare One Clients

Чтобы подключаться к частным именам хостов, клиенты Cloudflare One должны быть настроены на перенаправление следующего трафика в Cloudflare:

Начальные полученные IP-адреса:
- IPv4: 172.64.128.0/20
- IPv6: 2606:4700:0cf1:4000::/64
Это диапазон по умолчанию. Вы можете настроить пользовательский начальный диапазон разрешённых IP-адресов для IPv4, если он конфликтует с вашей существующей сетью.
DNS-запросы для вашего частного имени хоста

3.3.1 Настройте Split Tunnels

В своём WARP профиль устройства, настройте Split Tunnels так, чтобы Исходные разрешённые IP-адреса направляются через туннель WARP. Конфигурация зависит от вашего Режим Split Tunnels:

Режим Exclude: Удалите 100.64.0.0/10 из списка Split Tunnels. Мы рекомендуем повторное добавление диапазонов IP-адресов которые явно не используются для сервисов Cloudflare One. Это снижает риск конфликтов с существующими конфигурациями частной сети, которые могут использовать адресное пространство CGNAT.
Режим Include: Добавьте записи Split Tunnel для следующих IP-адресов:
- IPv4: 172.64.128.0/20
- IPv6: 2606:4700:0cf1:4000::/64
Это диапазон по умолчанию. Вы можете настроить пользовательский начальный диапазон разрешённых IP-адресов для IPv4, если он конфликтует с вашей существующей сетью.

3.3.2 Настройте Local Domain Fallback

В Local Domain Fallback, удалите домен верхнего уровня для своего приватного имени хоста. Это настраивает WARP на отправку DNS-запроса в Cloudflare Gateway для разрешения.

Например, если имя хоста SSH ssh.internal.local, удалите internal.local из Local Domain Fallback.

4. (Необязательно) Используйте IP-маршруты

4.1 Добавьте IP-маршрут

Чтобы подключиться к SSH-серверу по его IP-адресу (вместо имя хоста), добавить маршрут CIDR которая содержит частный IP-адрес сервера.

4.2 Настройте Cloudflare One Client

По умолчанию WARP исключает трафик, направленный на Пространство адресов RFC 1918 ↗, то есть IP-адреса, обычно используемые в частных сетях и недоступные из интернета. Чтобы Cloudflare One Client мог отправлять трафик в вашу частную сеть, необходимо настроить Split Tunnels чтобы трафик к IP-адресу/CIDR вашей частной сети направлялся через Cloudflare One Client.

Сначала проверьте, ваш Режим Split Tunnels имеет значение Exclude или Включить режим.
Измените маршруты Split Tunnel в зависимости от режима:
Если вы используете Exclude режим:
a. Удалите маршрут содержащий диапазон IP/CIDR вашей частной сети. Например, если в вашей сети используется диапазон AWS по умолчанию 172.31.0.0/16, удалите 172.16.0.0/12.
b. Повторно добавить диапазоны IP/CIDR которые явно не используются вашей частной сетью. Для приведенного выше примера AWS вы бы добавили новые записи для 172.16.0.0/13, 172.24.0.0/14, 172.28.0.0/15, а также 172.30.0.0/16. Это гарантирует, что только трафик к 172.31.0.0/16 маршруты через Cloudflare One Client.
Чтобы определить, какие IP-адреса нужно добавить повторно, можно воспользоваться следующим калькулятором:
Базовый CIDRВычтенные CIDR
Инструкции для калькулятора

В Базовый CIDR, введите диапазон RFC 1918, который вы удалили из Split Tunnels.

В Вычтенные CIDR, введите диапазон IP/CIDR, используемый вашей приватной сетью.

Повторно добавьте результаты калькулятора в список режима Exclude для Split Tunnel.
Сужая диапазон частных IP-адресов, включенный в Cloudflare One Client, вы снижаете риск нарушить работу пользовательского доступ к локальным ресурсам.
Если вы используете Включить режим:
1. Добавьте необходимые Домены Zero Trust или IP-адреса в список включений Split Tunnel.
2. Добавьте маршрут чтобы включить диапазон IP/CIDR вашей частной сети.

5. (Необязательно) Создайте сетевые политики Gateway

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

Перейдите в Политики трафика > Настройки трафика.
В Прокси и проверка, включите Разрешить Secure Web Gateway проксировать трафик.
Выберите TCP.
Выберите UDP (требуется для проксирования трафика к внутренним DNS-резолверам).
(Рекомендуется) Чтобы проксировать трафик для диагностических инструментов, таких как ping и traceroute, выберите ICMP. Вам также может понадобиться обновить вашу систему чтобы разрешить трафик ICMP через cloudflared.

Добавьте следующее разрешение в свой cloudflare_api_token ↗:
- Zero Trust Write

Включите прокси TCP и/или UDP с помощью cloudflare_zero_trust_device_settings ↗ ресурс:

resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
	account_id            = var.cloudflare_account_id
  gateway_proxy_enabled = true
	gateway_udp_proxy_enabled = true
}

Теперь Cloudflare проксирует трафик с зарегистрированных устройств, за исключением трафика, исключенного в вашем настройки Split Tunnel. Подробнее о том, как Gateway перенаправляет трафик, см. в Gateway proxy.

Примеры политик

Следующий пример состоит из двух политик: первая разрешает определённым пользователям доступ к вашему SSH-серверу, а вторая блокирует весь остальной трафик.

Политика 1: Allow для авторизованных пользователей

Перейдите в Политики трафика > Политики Firewall > Сеть.
Выберите Создать политику.
Назовите политику (например, Allow SSH to internal server).
Создайте выражение для сопоставления имени хоста SSH и авторизованных пользователей:

Селектор Оператор Значение

SNI in ssh.internal.local

User Email in [email protected], [email protected]
В Действие, выберите Allow.
Выберите Создать политику.

Селектор	Оператор	Значение
SNI	in	`ssh.internal.local`
User Email	in	`[email protected]`, `[email protected]`

Политика 2: универсальная блокировка

Чтобы запретить пользователям Cloudflare One Client доступ ко всей вашей частной сети, рекомендуем создать catch-all-политика блокировки Gateway для вашего частного IP-пространства. После этого вы можете добавить политики Allow с более высоким приоритетом (в Access или Gateway), которые предоставляют пользователям доступ к конкретным приложениям или IP-адресам.

Дополнительная защита с помощью политик DNS

Для дополнительного уровня защиты создайте политику Gateway DNS для контроля разрешения DNS-имён:

Перейдите в Политики трафика > Политики межсетевого экрана > DNS.
Выберите Создать политику.
Назовите политику (например, Allow SSH hostname resolution).
Создайте выражение:

Селектор Оператор Значение

Host in ssh.internal.local

User Email in [email protected], [email protected]
В Действие, выберите Allow.
Выберите Создать политику.

Селектор	Оператор	Значение
Host	in	`ssh.internal.local`
User Email	in	`[email protected]`, `[email protected]`

6. Подключитесь как пользователь

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

ssh -i ~/.ssh/gcp_ssh <username>@ssh.internal.local

Cloudflare One Client должен быть подключён к вашей организации Zero Trust. Пользователи смогут подключиться, если они соответствуют созданным вами сетевым политикам Gateway.

Устранение неполадок

Если подключиться не удается, проверьте следующее:

Подтвердить разрешение DNS: На устройстве убедитесь, что вам удаётся успешно разрешить частное имя хоста:
```
nslookup ssh.internal.local
```
```
Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	ssh.internal.local
Address: 172.64.128.48
```
Запрос должен разрешаться с использованием DNS-прокси WARP и верните Gateway исходный разрешённый IP-адрес. Если запрос не разрешается или возвращает другой IP-адрес, проверьте свои Local Domain Fallback конфигурация и Политики резолвера Gateway.
Проверить журналы Gateway: Проверьте свои Журналы Network Gateway и проверьте, блокируется ли подключение какой-либо политикой.
Проверить статус туннеля: Убедитесь, что ваш туннель исправен и подключён, проверив статус туннеля.
Протестировать подключение к изначально разрешённому IP: Когда вы подключаетесь к серверу SSH по его частному имени хоста, устройство должно устанавливать соединение с исходный разрешённый IP-адрес:
```
ssh -v <username>@ssh.internal.local
```
```
...
Authenticated to ssh.internal.local ([172.64.128.48]:22) using "publickey".
...
```
Найдите строку, показывающую подключение к IP-адресу из диапазона вашего аккаунта диапазон исходных разрешённых IP-адресов. Если запрос завершается ошибкой, убедитесь, что изначально определённый IP маршрутизируется через туннель WARP. Вы также можете проверить журналы туннеля чтобы убедиться, что запросы маршрутизируются к частному IP-адресу сервера.