CDN для противодействия РКН

Goal:

иметь возможность менять ip для конечных пользователей, таким образом обходя ограничения РКН. Сейчас CloudFlare замедляется, временно нам помог переезд на Fastly, но после его блокировки опять прийдется что-то искать. Хочется иметь способ быть независимым от облачных провайдеров и самим иметь свой CDN.

Схема подключения пользователя:

Для конечного пользователя наружу смотрит два компонента - DNS, из которого человек получает список IP адресов для подключения и Edge сервер — источник контента.

Список компонент и связи:

Основные компоненты:

• dev: контур для создания контейнеров и управления конфигурациями, gitops на минималках
• core: набор компонент для управления доступностью, реализующий DNS Failover стратегию на основании данных мониторинга
• origin: источник контента, aws или что-то иное
• DNS Management: управление NS серверами, обязательно нужно API для интерактивного обновления, и желательно простая реализация Failover
• edge: множество серверов, выступающий в роли реверс прокси для раздачи контента

Концепция решения:

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

Для заведения рабочих узлов необходимо максимально простую инструкцию, чтобы ее могли выполнять не технические специалисты, к примеру docker compose.

Что будет если в ротации будет недоступный IP

Если пользователю в списке IP адресов будет предоставлен недоступный ip, то браузер выполнит замену на следующий из списка. Гугл говорит что задержка будет около 30 секунд, но это лучше еще проверить.

Контексты безопасности

В данной схеме edge не является доверенным контуром (в отличие от dev и core). Это означает что edge не должен содержать доступов на запись ни в какую базу данных, должен содержать минимальное количество секретов и в целом быть подготовлен, к факту того что его захватит противник (грубо говоря изымет РКН или еще какая-то хтоническая дичь и получит доступ к содержимому). Соответственно в edge контуре должно быть минимум доступов (а те что есть должны быть только на чтение). Кроме того оптимально чтобы все кеши и т.п. были в in-memory разделах, чтобы при перезагрузке машины все данных в них терялись.

Соответственно статистику и иные данные с машин лучше собирать через Pull от них в мониторинг.

Компоненты

GIT

Нам необходимо хранить версии конфигураций, их версии и понимать что когда менялось.

CI

В предлагаемой схеме конфигурации добавляются на edge сервера в виде контейнеров с прожженными конфигами внутри. Поэтому нам нужен CI, способный создавать и публиковать образы. Это может быть bamboo, может быть github, все равно в целом что это будет.

Container Registry

Реестр контейнеров. Мы обычно используем harbour, но можно использовать в целом что угодно. Вплоть до S3 compatible R2 example.

Reverse Proxy

Собственно реверс прокси, который и раздает контент конечным пользователям. Можно использовать любой (nginx, traefik, caddy etc.), но есть несколько специфических требований:

• возможность использовать пред сохраненный конфиг
• возможность использовать внешнее хранилище ssl сертификатов
• возможность отдавать статистику в машино читаемом формате (prom export etc)
• возможность использовать локальный кеш для статики
• возможность дописать дополнительные заголовки к origin (x-real-ip etc.)

Reverse Proxy должен иметь права на чтение к Certificate Storage

Предположительно оптимально для этой задачи использовать Caddy.

Local Cache

Большая часть запросов идет к одним и тем же статическим ресурсам, которых на самом деле не так много. Поэтому оптимально сделать LRU кеш со статикой, чтобы каждый раз не ходить к oridgin за html\css\js, таким образом существенно увеличить скорость ответа и сохранить емкость канала. Оптимально чтобы это был in-memory cache, возможно пожать память zram для большей емкости (если в этом будет смысл).

Configuration puller

Небольшой сайдкар, который бы следил за доступностью новой версии контейнера и обновлял его. К примеру watchtower. В целом этот элемент может быть перенесен в core с edge контура, но предполагаю что это усложнит поддержку.

Origin

Собственно сервер источник данных, он в целом не должен беспокоится о том, как с него раздается контент. Это может быть AWS или вообще что угодно.

Certificate Manager

В современном вебе все должно быть https, но если каждый сервер будет получать отдельный ssl сертификат, то мы очень быстро упремся в лимиты. Поэтому управление сертификатами должно вестись централизованно, и осуществляется используя DNS верификацию (к примеру используя ACME v2 от LetsEncrypt или аналоги). Certificate Manager должен иметь права на запись в Certificate Storage.

DNS managment

Собственно это NS сервера и api для их управления. В этом месте кроется большой просто для улучшений (можно отдавать для разных гео разные ip, можно делать умную балансировку трафика между ип т.п.).

Для старта можно использовать CloudFlare, потому что у него есть удобное апи. Так же стоит посмотреть на реализацию DNS LB со стороны CF, она поддерживает helthchecks и может сама быстро отключать умершие узлы.

Доступ на запись в DNS менеджмент домен иметь Certificate Manager (для создания DNS записей верификации) и мониторинг (для удаления заблокированных хостов, или для добавления новых)

DB instance в Core

Собственно база данных подключенных хостов, информация о том какие из них должны быть подключены к каким доменам, информация о том, какой канал доступен каждому хосту и т.п. Фактически это база для конфигурирования поведения, из которой мы сообщаем какие хосты мы обслуживаем. Можно обойтись без интерфейса используя PostgreSQL + Metabase. В метабейсе есть Actions, которые можно использовать для построения простого табличного UI

Monitoring

Самая сложная часть нашей системы. Фактически это микс blacbox exporter и скриптов навешанных на алерты. К примеру, если у нас отработал скрипт, сообщающий о том, что какой-то из ip перестал открываться с российского прокси, то нам необходимо запустить процесс исключения этого ip и доступных на уровне DNS. После этого нам нужно проверить сколько IP осталось в активных зонах, и какая у них емкость. Если емкости недостаточно - добавить резервные IP. Так же нам нужно собирать статистику с узлов касательно количества трафика и rps. Если мониторинг покажет что у нас заканчиваются ресурсы, то нам необходимо снова таки добавить ресурсов. Описание сценариев работы мониторинга выходит за пределы этого документа. Основная сложность этого модуля в том, что правила будут все время меняться и актуализироваться, поэтому возможно имеет смысл добавить какой-то легковесный скриптинг или n8n сюда.

Слабые места:

Основной минус данного подхода в том, что мы должны контролировать какие IP для каких доменов мы используем, т.к. какой-нибудь умный РКН может мониторить наш домен и автоматически вносить новые IP в блек листы. Таким образом мы можем постепенно лишится всех IP.

Вторая проблема это балансировка нагрузки. Если на один узел прийдет слишком много трафика, он может не справится с нагрузкой. DNS балансировка равномерно размазывает запросы между всеми адресами (возможно частично поправимо с использованием CF LB).

Инструменты:

• watchtower для автоматического обновления узлов
• diun нотифки в телегу о новых версиях (просто прикольно)

К прочтению

Статья про применение Caddy с общим хранилищем сертификатов.