Cloudflare Tunnel как альтернатива открытию портов

Объяснение работы Cloudflare Tunnel без открытия портов

При классическом открытии портов внешний клиент подключается напрямую к публичному IP-адресу маршрутизатора или сервера. Затем маршрутизатор перенаправляет входящий трафик к службе во внутренней сети. Один Cloudflare Tunnel изменяет порядок установки соединения: коннектор cloudflared работает в доступной внутренней сети и самостоятельно устанавливает исходящие соединения с Cloudflare.

Если пользователь, например, заходит на портал администратора, Cloudflare принимает запрос на его доменное имя и перенаправляет его через уже существующее туннельное соединение на коннектор. Коннектор доставляет запрос к настроенному целевому сервису, например http://localhost:8080. Поэтому для устройства Origin не требуется ни IP-адрес, доступный напрямую из Интернета, ни разрешение на входящий трафик в брандмауэре для этой службы.

Это не означает, что сетевые правила больше не действуют. Хост с cloudflared Cloudflare должен иметь возможность выходить в внешнюю сеть. Cloudflare указывает для этого порт 7844 по протоколу TCP или UDP; при этом используются протоколы HTTP/2 и QUIC соответственно. Исходящий трафик должен быть разрешён в локальном брандмауэре, на маршрутизаторе и, при необходимости, через корпоративный прокси-сервер. Это и есть практическое ограничение, лежащее в основе формулировки „без открытия портов“.

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

Туннель не является средством защиты доступа

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

Для привилегированной панели администратора следует создать Политика доступа допускать только четко определенных пользователей или группы. Помимо критериев Include, Require и Exclude доступны такие действия, как Allow, Block, Bypass и Service Auth. Многофакторную аутентификацию (MFA) можно принудительно включить через подключенного поставщика идентификации или в качестве дополнительного фактора. Единое правило для всех учетных записей домена электронной почты, как правило, является слишком широким для интерфейсов с высоким уровнем привилегий.

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

Кроме того, необходимо проверить, проверяет ли приложение токены доступа или использует ли оно предусмотренную для этого опцию туннелирования для проверки токенов. Это привязывает приложение к предшествующей проверке идентичности и снижает риски, связанные с непреднамеренным альтернативным путем доступа к исходному серверу. Целесообразно использовать многоуровневую архитектуру: ограниченный доступ, проверка идентичности с помощью многофакторной аутентификации (MFA), минимальные права доступа для приложения и внутренне доступный целевой сервис, не подверженный общему доступу.

Классификация протоколов HTTP, SSH, RDP и TCP

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

Для SSH с использованием привычного локального терминала можно на стороне клиента cloudflared установить соединение совместно с Access. Кроме того, Cloudflare описывает SSH с рендерингом в браузере как отдельный способ доступа. Оба варианта различаются по рабочему процессу на стороне клиента, локальной конфигурации SSH и способу управления; поэтому их нельзя безоговорочно заменять друг на друга. Заявления о более сложных моделях инфраструктуры или сертификатов следует включать в план только после отдельной проверки актуальной и соответствующей документации.

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

Tunnel не является полноценной заменой для всех видов сетевого соединения. Протоколы, инициируемые сервером, такие как VoIP или SIP, не поддерживаются; кроме того, длительные сеансы TCP, чувствительные к прерываниям, требуют проверки на совместимость. Кроме того, при использовании SSH, RDP и TCP сервер «Origin» видит не исходный IP-адрес клиента, а IP-адрес коннектора. В случае HTTP приложение может CF-Connecting-IP анализировать. Списки разрешенных адресов на основе IP и журналы для криминалистической экспертизы должны учитывать этот предел.

Безопасное сопоставление нескольких служб

Локальный файл Ingress сопоставляет каждое опубликованное имя хоста ровно одному внутреннему назначению. Для панели администратора и SSH целесообразно использовать отдельные имена: благодаря этому права доступа, журналы и последующие изменения остаются четко разграниченными. Cloudflared обрабатывает правила сверху вниз; первое подходящее правило определяет цель.

В приведенном ниже примере представлен шаблон конфигурации для туннеля, управляемого локально. В нём намеренно используется example.invalid и не содержит ни учетных данных, ни реального домена. Веб-сервис остается на localhost:8080 доступно; SSH-соединение перенаправляется на локальный SSH-сервер.

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

Последнее правило заключается в том, что Правило «catch-all». Она необходима для локальных файлов Ingress и обеспечивает здесь с помощью http_status:404 чтобы неизвестное имя хоста случайно не попало в первую или какую-либо другую внутреннюю службу. Широкая стандартная переадресация представляла бы ненужный риск, особенно в случае административных целей.

Этот файл определяет исключительно путь от туннеля до Origin. Он не настраивает записи DNS и не обеспечивает защиту имен с помощью Cloudflare Access. Поэтому перед созданием рабочего маршрута необходимо отдельно настроить имя хоста и политику доступа. Кроме того, локально целевые порты должны быть доступны только там, где они действительно нужны для работы cloudflared.

Перед запуском можно проверить порядок, не изменяя настроек. Первая команда проверяет конфигурацию Ingress; вторая показывает, какое правило будет применено к указанному адресу.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Целенаправленный выбор SSH-доступов

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

Для небольшой команды, которая регулярно использует привычные локальные инструменты, часто подходит решение «client-side cloudflared»: порт SSH остается внутренним, а Access перед установкой соединения добавляет дополнительный уровень аутентификации. Однако это не то же самое, что централизованное управление всеми правами доступа по SSH.

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

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

Для опубликованных сервисов, не использующих протокол HTTP, на стороне клиента может потребоваться установка cloudflared; кроме того, SSH обеспечивает доступ через браузер. Поэтому RDP и другие TCP-сервисы не следует поспешно планировать по образцу SSH, а необходимо учитывать их конкретные требования к клиентам и операционной среде.

Туннель, VPN, бастион или открытие портов

Этот выбор касается не только того, открыт ли порт, но и желаемого объема доступа. Cloudflare Tunnel подходит, прежде всего, для небольшого числа четко определенных сервисов. Тем же, кому требуется доступ ко многим внутренним системам и сегментам сети, обычно нужна модель частного сетевого доступа, а не набор отдельных публикаций.

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

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

Использование VPN по-прежнему целесообразно, если сотрудникам требуются несколько частных приложений, диапазонов адресов или внутренних зависимостей. Бастион-хост, напротив, концентрирует SSH-доступы в одной точке входа, которая сама по себе должна быть тщательно защищена и эксплуатироваться надлежащим образом. Обратный прокси, в свою очередь, представляет собой уровень для завершения соединений TLS и предоставления приложений; он сам по себе не решает вопрос о том, как получить доступ к частному источнику. Роли прокси, сервера приложений и диспетчера процессов можно также реализовать в Сравнение NGINX Unit и PHP-FPM понимать.

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

Обеспечение безопасности туннелей во время эксплуатации

Активный туннель не представляет собой единичное, разовое соединение. Согласно документации Cloudflare, каждый туннель cloudflared состоит из четырёх долгосрочных исходящих соединений с как минимум двумя собственными дата-центрами. Поэтому в случае сбоя одного из путей соединения запросы могут проходить по другому существующему пути. Это снижает зависимость на участке между коннектором и Cloudflare, однако не обеспечивает высокую доступность самого внутреннего сервиса.

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

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

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

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

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

Своевременное выявление типичных ошибок в настройках

Перед запуском в эксплуатацию необходимо проверить работоспособность коннектора: хост должен иметь возможность установить соединение с Cloudflare через порт 7844 по протоколу TCP или UDP. Отсутствие открытого входящего порта в данном случае вполне ожидаемо, в то время как общая блокировка исходящего трафика брандмауэром — нет. Только после того, как cloudflared сможет установить исходящие соединения, имеет смысл проверить DNS, имена хостов и правила доступа на уровне приложений.

1. Проверить доступность в локальной сети: сервис, указанный в правиле Ingress, должен быть доступен с хоста cloudflared через указанную локальную или внутреннюю конечную точку.
2. Синхронизация DNS и Ingress: общедоступное имя хоста должно соответствовать предполагаемому маршруту туннеля; порядок правил должен обеспечивать, чтобы конкретное правило применялось раньше, чем более общие правила.
3. Проверка универсального правила: заключительное правило с http_status:404 предотвращает перенаправление не предусмотренных имен хостов на стандартный сервис.
4. Настройка Access перед запуском в производственную эксплуатацию: только после этого можно будет провести контролируемую проверку внешнего пути с использованием учетной записи с правами доступа и учетной записи без таких прав.

Распространенной ошибкой в области безопасности является слишком широкий маршрут: вместо того, чтобы открыть доступ только к панели администратора или определённому SSH-сервису, предоставляется доступ к более обширному участку сети. Не менее рискованными являются общие правила для доменов электронной почты, применяемые к интерфейсам с привилегированным доступом. Для доступа администраторов следует использовать небольшие, поддающиеся проверке группы, соответствующие критерии Require и многофакторную аутентификацию (MFA), чтобы точно отражать фактический круг лиц. Минимальное разрешение это также означает, что не следует без необходимости объединять отдельные имена хостов и целевые службы.

Настройка туннелей и прав доступа решает разные задачи. Правило входа (Ingress) определяет, куда будет проходить уже установленное соединение; Access решает, кто перед этим пройдет аутентификацию и авторизацию. Без соответствующего приложения Access опубликованное имя хоста HTTP может быть доступно из Интернета. Поэтому локальные учетные записи, правила sudo, настройки SSHD и укрепление безопасности приложения остаются отдельными пунктами проверки.

Для журналов и аудита важно ограничение по исходному IP-адресу: при использовании SSH, RDP и других методов доступа по протоколу TCP сервер не видит исходный IP-адрес клиента, а лишь контекст соединения. Использование списков разрешенных адресов на основе IP-адресов в целевой системе не обеспечивает надежного сопоставления с пользователями. HTTP-приложения могут анализировать заголовок CF-Connecting-IP, если их система ведения журналов и цепочка доверия специально учитывают этот факт.

Выбор подходящего решения для доступа

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

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

Тем, кому требуется большое количество внутренних сервисов, целые сегменты или широкая связь по оси «восток-запад», следует рассмотреть возможность использования частного доступа к сети, такого как VPN, или специальной модели подключения, предназначенной для этих целей. Один-единственный открытый туннель не может автоматически заменить все рабочие нагрузки VPN. Туннель не подходит для протоколов, инициируемых сервером, таких как VoIP или SIP; кроме того, длительные сеансы TCP, чувствительные к прерываниям, требуют проверки конкретного протокола и возможных последствий повторного подключения.

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

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