Ротация gRPC-путей

Содержание

На каждом участке сети gRPC-путь (serviceName) периодически меняется. Постоянный путь — это паттерн, который можно выделить статистическим анализом. Ротация делает трафик неотличимым от активности множества разных сервисов на одном хосте.

Зачем нужна ротация #

VLESS поверх gRPC практически неотличим от легитимного HTTPS: TLS 1.3, валидный сертификат, HTTP/2. Сигнатурный анализ здесь бессилен.

Однако постоянное соединение по одному и тому же gRPC-пути между двумя хостами — это паттерн. Реальные gRPC-микросервисы обращаются к множеству разных эндпоинтов в разное время. Статический путь, неизменный неделями, может быть выделен из общего потока.

Решение: менять serviceName с заданной периодичностью.

Два участка — два механизма #

Участок	Управляет ротацией	Затрагивает клиента
Client → Entry	Управляющий кластер	Нет (subscription обновляет автоматически)
Entry → Core	Управляющий кластер	Нет (Entry получает из etcd)

Ротация на участке Client → Entry #

Что ротируется #

serviceName на Entry-ноде — путь, по которому клиент подключается к Xray внутри Entry-пода.

https://<DOMAIN>/api.v2.rpc.<serviceName>  →  Xray
https://<DOMAIN>/*                          →  сайт-прикрытие

Механизм #

Управляющий кластер генерирует новый serviceName для Entry-ноды ячейки.
Обновляет конфигурацию Nginx и Xray на Entry-подах через K8s (rolling update).
Записывает новый serviceName в etcd.
При следующем обращении клиента к subscription URL — микросервис возвращает ссылку с новым serviceName.
Клиент автоматически обновляет профиль.

Клиент не вовлечён в процесс — всё происходит прозрачно.

Расписание #

Параметр	Значение
Интервал	Каждые 2 часа
Случайное смещение	0–30 минут

Ротация на участке Entry → Core #

Что ротируется #

serviceName на Core-ноде — путь, по которому Entry-под подключается к Xray на Core-ноде.

Механизм #

Управляющий кластер генерирует новый serviceName для Core-ноды.
Обновляет запись в etcd: Core-нода X → новый serviceName.
Доставляет новую конфигурацию Core-ноде через phone-home канал.
Core-нода обновляет конфигурацию Nginx и Xray (без перезапуска, hot reload).
Entry-поды при следующем запросе в etcd получают актуальный serviceName.

Расписание #

Параметр	Значение
Интервал	Каждый час
Случайное смещение	0–30 минут

Формат serviceName #

api.v2.rpc.<16 hex-символов>

Имитирует реальные gRPC-эндпоинты API микросервисов.

Обработка ошибок #

На обоих участках ротация безопасна: при ошибке обновления конфигурации старый serviceName остаётся рабочим. Новый применяется только после успешной валидации.

Если Entry-под не успел получить новый serviceName из etcd — при следующем запросе он получит актуальную версию. Расхождение конфигураций длится не более нескольких секунд.

Сводная таблица #

Компонент	Хранится	Когда меняется
`serviceName` Client → Entry	etcd, конфиг Nginx/Xray Entry	Каждые 2 часа ± 30 мин
`serviceName` Entry → Core	etcd, конфиг Nginx/Xray Core	Каждый час ± 30 мин
Клиентский UUID	etcd, конфиг Xray	При компрометации устройства
Subscription URL	Только на устройстве	При компрометации устройства