Cloudflare для сайтов и игровых серверов: что он проксирует

Прокси Cloudflare - оранжевое облако рядом с DNS-записью - передаёт HTTP и HTTPS на определённом списке портов и больше ничего. Поставьте его перед сайтом, и вы получите кэширование, бесплатный сертификат, веб-файрвол и скрытый адрес origin. Направьте его на сервер Minecraft, сервер Ark или что-либо ещё, что говорит на собственном протоколе на собственном порту, и соединение просто не установится: HTTP-запроса, который Cloudflare мог бы прочитать, там нет. Эта одна фраза снимает примерно восемьдесят процентов вопросов о Cloudflare, а остальное в этой статье - детали: какие порты, какие настройки, какие ошибки и что оранжевое облако не защищает никогда, как его ни настраивай.

Что на самом деле меняет оранжевое облако#

Cloudflare - ваш авторитетный DNS-хостинг, и у каждой записи есть переключатель. Серое облако - «только DNS» - означает, что Cloudflare отвечает на запрос вашим настоящим адресом и отходит в сторону. Оранжевое означает, что он отвечает одним из своих anycast-адресов, а трафик на этот адрес обрабатывает ближайший дата-центр Cloudflare, который затем сам устанавливает соединение с вашим сервером.

Всё остальное следует из этой подмены:

• dig www.example.com возвращает адрес Cloudflare вроде 104.21.x.x или 172.67.x.x, но не ваш.
• Поле TTL заблокировано на Auto, потому что им управляет Cloudflare.
• Ваш origin видит соединения только из диапазонов Cloudflare, поэтому адрес посетителя нужно брать из заголовка.
• Всё, что проверяет или переписывает запрос - кэширование, файрвол, редиректы, сжатие, - возможно только для проксируемых записей.

Зона почти всегда получается смешанной: www и apex оранжевые, play и mail серые. Это не компромисс, а правильная конфигурация. Если различие между A, CNAME и SRV вам в новинку, типы записей разобраны в статье DNS-записи простыми словами.

Какие порты он проксирует и всё остальное#

Проксируемая запись принимает соединения только на портах, которые поддерживает Cloudflare. Всё прочее отклоняется или уходит в таймаут, и потому вопрос «я включил оранжевое облако, и мой сайт на порту 3000 перестал работать» задают каждую неделю.

Обратите внимание, чего здесь нет: 25 (SMTP), 3306, 5432, 22, 25565, 27015 и всех UDP-портов на свете. Прокси - это обратный HTTP-прокси. Он завершает TLS, разбирает запрос, применяет правила и пересылает дальше. Протокол, который он не может разобрать, он не может и проксировать.

У Cloudflare есть продукт для чистого TCP - Spectrum, - но это платное дополнение: произвольные TCP-приложения на тарифах Business и Enterprise, а поддержка Minecraft доступна чуть ниже по линейке. Цены и границы тарифов меняются, поэтому проверьте актуальную страницу тарифов, прежде чем строить вокруг этого планы, и честно сопоставьте цену с тем, чтобы просто взять приличный хостинг.

Игровые серверы и оранжевое облако#

Ради этого раздела сюда и приходят, так что вот всё как есть.

Игровой трафик не может идти через бесплатный прокси Cloudflare. Большинство игр используют UDP, который HTTP-прокси не несёт вообще. Игры на TCP - например, Minecraft Java на 25565 - используют порт, которого нет в списке поддерживаемых. Включение оранжевого облака для игровой записи даёт один из двух результатов: клиент не может подключиться либо подключается к веб-узлу Cloudflare и получает HTTP-ошибку вместо рукопожатия, которого ждал.

Запись игрового сервера остаётся серой. Это нормально, и именно этого ждёт любой хостер:

Type   Name    Content          ProxyA      play    203.0.113.10     DNS onlySRV    _minecraft._tcp.play     DNS only

SRV-записи проксировать нельзя вообще - Cloudflare не даст вам такого переключателя, - а если имя хоста, на которое указывает SRV-запись, само стоит за оранжевым облаком, поиск разрешается в Cloudflare и соединение обрывается. И SRV-запись, и запись A, на которую она указывает, должны быть «только DNS». Формат разобран в статье SRV-записи для Minecraft, а обычный случай с записью A - в статье как привязать домен к игровому серверу.

Отсюда два следствия, и второе неприятное.

Во-первых, Cloudflare не скрывает адрес игрового сервера. Запись с серым облаком его публикует, и по-другому нельзя: клиенту нужно достучаться до вашей машины напрямую. Любой, кто умеет читать DNS, прочтёт этот адрес, в том числе тот, кто планирует атаку.

Во-вторых, оранжевое облако на вашем сайте ничем не защищает игровой сервер, живущий на том же адресе. Если ваши веб-записи проксируются, а игровая нет, вы не скрыли вообще ничего: запись A для play выдаёт тот же IP, на котором стоит сайт. Это самый частый способ утечки адреса origin.

По-настоящему игровой сервер защищает фильтрация выше по течению, в сети, где работает ваш хостер. На RE:NODE формулировка намеренно узкая: фильтрация выше по течению отбрасывает очевидные объёмные потоки, а также отражённый и искажённый трафик. Атаки, которые выглядят как настоящие игроки, не фильтруются, потому что в этот момент их не отличить от настоящих игроков, не зная игры. Хостер, обещающий отсутствие простоев при любой атаке, продаёт вам фразу, а не услугу: более подробно - в статье что мы делаем с атаками, а сами типы атак разобраны в статье DDoS-атаки на игровые серверы простыми словами.

Режимы SSL, сертификаты и циклы редиректов#

В разделе SSL/TLS есть настройка режима, определяющая, как Cloudflare общается с вашим origin, и неверный выбор вызывает два очень частых сбоя.

Flexible - это ловушка. Посетитель видит HTTPS, но соединение от Cloudflare до вашего сервера идёт по обычному HTTP через публичный интернет, так что замок сообщает посетителю неправду. К тому же он порождает классическую ошибку ERR_TOO_MANY_REDIRECTS: Cloudflare шлёт HTTP-запрос, ваш сервер перенаправляет HTTP на HTTPS, Cloudflare следует за этим редиректом обратно к себе, и так без конца. Если сайт зацикливается сразу после включения Cloudflare, причина в этом: переключитесь на Full (strict).

Full (strict) требует действительного сертификата на вашем origin. Либо того, что ваш хостер уже выпускает, либо бесплатного сертификата Cloudflare Origin CA, которому доверяет только Cloudflare и который можно выпустить на срок до пятнадцати лет. Работают оба; хостерский - меньше забот.

На управляемом хостинге подводным камнем становится продление сертификата. Проверка HTTP-01 должна достучаться до вашего origin на порту 80 по пути /.well-known/acme-challenge/, а правило файрвола, редирект или режим Flexible могут молча её остановить. На RE:NODE тарифы для приложений и сайтов включают слот прокси, который выпускает и продлевает сертификат автоматически в окне 21 день, а значит, продление, заблокированное чем-то, что вы настроили в Cloudflare, ломается не сегодня, а через два месяца, когда истекает действующий сертификат. Если вы ставите Cloudflare перед сертификатом, которым управляет хостер, сделайте запись серой на время, достаточное для продления, либо переключите хостера на DNS-проверку, если он это предлагает. Как работает проверка, описано в статье HTTPS и Let's Encrypt простыми словами.

Две настройки стоит включить, когда Full (strict) заработает: Always Use HTTPS, который делает редирект с HTTP на HTTPS на самом узле, так что ваш сервер никогда не видит обычного запроса, и Automatic HTTPS Rewrites, исправляющий ссылки со смешанным содержимым в вашем HTML.

Кэширование: что кэшируется по умолчанию, а что нет#

По умолчанию Cloudflare кэширует статические ресурсы по расширению файла - изображения, CSS, JavaScript, шрифты - и не кэширует HTML. Для сайта на WordPress или любого динамического приложения это означает, что дорогая часть каждого просмотра страницы всё равно доходит до вашего сервера. Людей это неизменно удивляет: они полагали, что оранжевое облако делает сайт быстрым.

Чтобы кэшировать HTML, вы создаёте Cache Rule, который выставляет «Eligible for cache» (замену прежнего «Cache Everything» из Page Rules), а затем должны разобраться со случаем залогиненного пользователя. Отдайте с узла кабинет одного посетителя всем остальным, и вы устроите утечку данных одной галочкой. Правила, которые делают это безопасным:

• Обходите кэш, когда присутствует cookie сессии: wordpress_logged_in_*, PHPSESSID, имя cookie вашего фреймворка.
• Полностью обходите кэш для админских путей и любого API, который возвращает данные по пользователю.
• Для начала ставьте короткий TTL на узле и увеличивайте его, когда убедитесь, что всё работает.

Более чистый подход - позволить управлять этим вашим собственным заголовкам. Cache-Control: public, max-age=31536000, immutable для файлов с хэшем в имени и Cache-Control: private, no-store для всего личного - это политика, которая работает на любом CDN, а не в панели одного поставщика. Набор заголовков разобран как следует в статье заголовки HTTP-кэширования простыми словами.

Две эксплуатационные заметки. Development Mode обходит кэш на три часа и выключается сам, что и нужно, пока вы правите тему. И очищайте кэш по URL, а не целиком: полная очистка на нагруженном сайте отправляет все запросы на ваш origin разом, то есть устраивает скачок нагрузки своими руками.

Настройки безопасности, которые стоит иметь, и две, которые всё ломают#

Действительно полезные, в порядке ценности для небольшого сайта:

• Управляемые правила WAF. Бесплатные тарифы получают часть из них, и они останавливают огромное количество автоматической ерунды ещё до того, как она дойдёт до PHP.
• Ограничение частоты запросов. Бесплатные тарифы включают одно правило. Потратьте его на точку входа для логина - именно туда бьёт подбор учётных данных.
• Блокировка по стране или ASN, если ваша аудитория действительно региональная. Грубо, но эффективно против конкретной проблемы.
• Блокировка по пути. Запросы к /wp-login.php, /xmlrpc.php и /.env отовсюду, кроме вашего собственного адреса, блокировать ничего не стоит, а это большая часть первого хода атакующего.

Две настройки, которые всё ломают и которые включают люди, не связывающие сбой с настройкой:

Bot Fight Mode бросает вызов всему, что решит, что это не браузер. Сюда входят вебхуки вашего платёжного провайдера, ваш deploy-хук GitHub, ваш монитор доступности, ваше мобильное приложение и ваши RSS-читалки. Симптом - 403, которого нет в ваших собственных логах, потому что ваш сервер никто ни о чём не спрашивал. Если у вас есть трафик между машинами, оставьте режим выключенным или исключите эти пути.

Under Attack mode показывает каждому посетителю пятисекундную промежуточную страницу, прежде чем его пропустить. Против потока запросов он работает и ломает каждый API-клиент и каждое рукопожатие WebSocket, пока включён. Это аварийный выключатель, а не конфигурация: выключайте, когда авария закончилась. Сами WebSocket проксируются без проблем на всех тарифах, убивает их именно проверка, а о другом поведении, связанном с таймаутом простоя, рассказано в статье WebSocket за обратным прокси.

Как увидеть настоящий адрес посетителя#

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

Настоящий адрес приходит в CF-Connecting-IP и дополнительно добавляется в X-Forwarded-For. В nginx восстановите его, чтобы логи, лимиты и код приложения видели правду:

# Повторите set_real_ip_from для каждого диапазона, опубликованного на cloudflare.com/ipsset_real_ip_from 173.245.48.0/20;set_real_ip_from 103.21.244.0/22;real_ip_header CF-Connecting-IP;

Никогда не доверяйте этому заголовку от источника, который не является Cloudflare. Это обычный заголовок запроса, так что любой, кто подключается к вашему origin напрямую, может выставить в нём что угодно, - и именно поэтому список set_real_ip_from важен. На управляемом хостинге nginx обычно править нельзя, но та же логика относится к заголовку, который даёт ваша платформа: на RE:NODE слот прокси передаёт исходный адрес клиента в X-Forwarded-For, а если в цепочке есть ещё и Cloudflare, этот заголовок становится списком, где самая левая запись - посетитель, а каждый следующий узел дописал предыдущий.

Вторая половина дела - файрвол, который принимает соединения на 80 и 443 только от Cloudflare, чтобы никто не мог обойти прокси, подключившись к вашему адресу напрямую. На собственном VDS это несколько правил ufw плюс Authenticated Origin Pulls. На общем хостинге на контейнерах это, как правило, не то, чем вы управляете, и это реальное ограничение, о котором лучше знать, а не предполагать.

Как читать страницы ошибок Cloudflare#

Ошибки Cloudflare серии пятьсот конкретны, и каждая указывает на свою половину системы. Эта таблица избавляет от многих догадок:

Различие, которое нужно усвоить, - между 521 и 522. Отклонённое соединение означает, что кто-то ответил «нет»: порт закрыт или отфильтрован с отказом. Таймаут означает, что не ответил вообще никто: на нагруженном сервере это значит, что очередь запросов заполнена, а на защищённом файрволом - что пакеты отбрасываются. Проверка собственных логов даёт ответ сразу: если записи о запросе нет, он не дошёл.

Про 524 нужно сказать отдельно, потому что на самом деле это не ошибка. Запрос, который длится дольше примерно 100 секунд, обрывается на узле, а на младших тарифах этот предел не настраивается. Работа, которая занимает минуты, вообще не должна выполняться внутри запроса - её нужно ставить в очередь и опрашивать. Как это вынести, описано в статье фоновые задачи на небольшом сервере.

Чего Cloudflare для вас не сделает#

Короткий честный список, потому что маркетинг о нём не сообщает.

• Он не хостит вашу почту. MX-записи должны быть «только DNS», и если ваш почтовый сервер делит адрес с веб-сервером, эта MX-запись публикует ваш origin. Email Routing от Cloudflare пересылает почту, но не является почтовым ящиком. RE:NODE почту тоже не хостит.
• Он не скрывает адрес, который уже утёк. Его могут выдать старая история DNS, поддомен с серым облаком, запись в журнале прозрачности сертификатов или приложение, делающее исходящие запросы. Единственное настоящее лекарство - сменить адрес origin после включения прокси.
• Он не делает медленное приложение быстрым. Некэшированный HTML всё равно приходит с вашего сервера, с его скоростью. Если запрос к базе идёт 800 мс, он идёт 800 мс и с оранжевым облаком перед ним.
• Он не покрывает не-HTTP-сервисы. Базы данных, SSH, игровые порты и почта обходят его полностью, и каждый из них - прямая дорога к вашей машине, с которой должен разбираться ваш файрвол.
• Он не принимает неограниченные загрузки. Тарифы Free и Pro ограничивают тело запроса 100 МБ. Большие файлы нужно грузить куда-то ещё или через имя хоста с серым облаком.
• Он не заменяет бэкапы, обновления и файрвол. Он фильтрует трафик до того, как тот придёт; всё, что после, по-прежнему на вас.

Если использовать его по назначению - как HTTP-узел перед сайтом, - он превосходен, бесплатен и настраивается за двадцать минут. Если использовать его как щит для игрового сервера, это недоразумение, которое стоит вам вечера.

FAQ#

Можно ли использовать прокси Cloudflare для сервера Minecraft?

На бесплатном тарифе нет. Minecraft Java использует TCP 25565, которого нет среди проксируемых портов, а прокси понимает только HTTP. Оставьте запись «только DNS» или посмотрите на Spectrum - платное дополнение с поддержкой Minecraft.

Скрывает ли оранжевое облако IP-адрес моего игрового сервера?

Нет. Запись, которой пользуется игровой клиент, должна быть «только DNS», то есть по определению публикует ваш настоящий адрес. Если ваш сайт проксируется, но делит этот адрес, игровая запись выдаёт его для обоих.

Почему сайт стал уходить в цикл редиректов после включения Cloudflare?

Режим SSL - Flexible: Cloudflare обращается к вашему origin по обычному HTTP, origin перенаправляет на HTTPS, а Cloudflare следует за редиректом обратно к себе. Переключитесь на Full (strict) с действительным сертификатом на origin.

Поддерживаются ли WebSocket?

Да, на любом тарифе, включать ничего не нужно. Простаивающие соединения закрываются примерно через 100 секунд, поэтому отправляйте heartbeat каждые 30 и не допускайте проверок ботов на пути WebSocket.

Почему мой сервер видит IP Cloudflare, а не посетителя?

Потому что соединение устанавливает Cloudflare, а не посетитель. Читайте CF-Connecting-IP или настройте свой прокси восстанавливать настоящий адрес из него, и доверяйте этому заголовку, только когда соединение пришло из опубликованного диапазона Cloudflare.

Заменяет ли Cloudflare то, что мой хостер делает против атак?

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