Core-нода

Содержание

Core-нода — сервер участника сети, расположенный за пределами регулируемого региона. Принимает трафик от входного слоя и направляет его в открытый интернет. Работает автономно: сам инициирует регистрацию в сети и не зависит от постоянного соединения с управляющим кластером.

Роль в архитектуре #

graph TD Entry["Входной слой"] Core["Core-нода\n(сервер участника)"] Mgmt["Управляющий кластер"] Internet["Интернет"] Entry -->|"mTLS\nVLESS + gRPC"| Core Core -->|"phone-home"| Mgmt Core --> Internet style Core fill:#1d4ed8,color:#fff,stroke:#1e40af,stroke-width:3px style Entry fill:#0891b2,color:#fff,stroke:#0e7490 style Mgmt fill:#7c3aed,color:#fff,stroke:#6d28d9 style Internet fill:#374151,color:#fff,stroke:#1f2937

Характеристики #

Параметр	Значение
Владелец	Участник сети
Расположение	Вне регулируемого региона
Жизненный цикл	Долгоживущая (на усмотрение участника)
Инфраструктура	Docker-контейнер
Открытые порты	443 (HTTPS для входного трафика)
Маскировка	gRPC API микросервисов

Модель управления: phone-home #

Core-нода сама инициирует подключение к управляющему кластеру — не наоборот. Управляющий кластер не имеет доступа к серверу участника и не отдаёт ему команды через SSH.

При запуске контейнер:

Устанавливает исходящее mTLS-соединение с управляющим кластером.
Регистрирует свой адрес и параметры.
Получает текущую конфигурацию (клиентские UUID, serviceName).
Начинает принимать трафик от Entry-подов.

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

Изоляция от других Core-нод #

Core-ноды не взаимодействуют между собой — никаких сетевых соединений, никакого доверия. Каждая Core-нода — изолированный участник. Компрометация одной Core-ноды не затрагивает остальные.

Компоненты контейнера #

Xray-core #

Принимает входящий трафик от Entry-подов по mTLS + VLESS + gRPC.
Outbound: прямой выход в интернет (freedom).
Аутентифицирует клиентов по UUID.

Nginx #

TLS-терминация с сертификатом от публичного CA.
Маршрутизация: gRPC-трафик (по serviceName ячейки) → Xray, всё остальное → сайт-прикрытие.
Fallback: при обращении без VLESS-заголовков — HTTP 200 OK с контентом сайта-прикрытия.

Сайт-прикрытие #

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

Phone-home агент #

Поддерживает постоянное mTLS-соединение с управляющим кластером.
Получает обновления конфигурации: новые UUID, ротацию serviceName.
Отправляет heartbeat — управляющий кластер знает, что нода жива.

Принадлежность к ячейке #

Каждая Core-нода принадлежит одной ячейке. Ячейка определяет SNI-домен, который Entry-поды указывают в TLS ClientHello при подключении к этой Core-ноде.

Внутри ячейки Core-ноды не взаимодействуют — общий SNI-домен это только параметр сертификата, а не признак доверия.

→ Подробнее: ячеистая топология

Сертификаты #

Сертификат	Источник	Назначение
TLS (публичный)	Let’s Encrypt	Защита входящего соединения, маскировка под легитимный HTTPS
mTLS (внутренний)	Управляющий кластер (CA)	Аутентификация Entry-подов, phone-home соединение

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

Требования к серверу #

Параметр	Минимум
CPU	1 vCPU
RAM	512 MB
Диск	10 GB SSD
ОС	Linux (Ubuntu 22.04 / Debian 12)
Обязательно	Docker
IPv4	Выделенный белый адрес
Локация	Вне регулируемого региона

Реагирование на инциденты #

Признаки компрометации Core-ноды: несанкционированный доступ к серверу участника или блокировка трафика DPI. В обоих случаях — нода выводится из оборота.

При компрометации Core-ноды:

Участник отключает ноду (или управляющий кластер фиксирует потерю heartbeat).
Управляющий кластер отзывает mTLS-сертификат ноды.
Entry-поды перестают направлять трафик на скомпрометированный адрес.
Клиенты этой Core-ноды получают временный резервный доступ через другую ячейку.
Участник поднимает новый сервер и проходит онбординг заново.