Изменения без перезапусков

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

Правило

Каждое изменение доходит до узла только как это изменение:

1. На лету, когда узел может применить его к тому, что работает. Ничего не обрывается.
2. Перестройка одного элемента, когда на лету нельзя. Заменяется только этот инбаунд, аутбаунд или эндпоинт.
3. Перезапуск ядра узла — только когда ничто другое не может применить изменение.

И изменение никогда не оставляет узел в худшем состоянии, чем было: о части, которая не удалась, сообщается, а остальное всё равно применяется.

Хеши: как узнать, что запускает узел

Узел сообщает опись того, что он запускает, с хешем для каждого элемента:

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

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

Что применяется на лету

Изменение	Как оно доходит до узла
Пользователи инбаунда: добавлены, удалены, включены, отключены, продлены, новые учётные данные	Весь набор пользователей инбаунда заменяется на месте. Открытые соединения других пользователей не затрагиваются. Набор, равный тому, что уже есть у инбаунда, ничего не меняет.
Состав туннеля: добавлен или удалён исходный узел, заменены учётные данные	Работающей половине сообщают её новых партнёров. Поднятые связи остаются; связи удалённого исходного узла обрываются.
Правила маршрутизации, наборы правил, итоговый аутбаунд, DNS, уровень журнала, синхронизация времени, доверенные сертификаты	Применяются вместе одним обновлением основы. Если шаг отклонён посередине, уже сделанные шаги откатываются.
Новый инбаунд, аутбаунд или эндпоинт	Добавляется рядом с работающими.
Удалённый элемент	Удаляется. Узел отказывается удалять то, что ещё нужно работающей конфигурации, например итоговый аутбаунд; панель сначала добавляет замену, а затем повторяет удаление.

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

Что перестраивается

Некоторые изменения нельзя применить к работающему элементу, и тогда этот один элемент строится заново:

• Изменённый инбаунд: его порт, TLS, сертификат, транспорт или параметры протокола.
• Пользователи нескольких протоколов, чей список пользователей нельзя изменить на месте: SOCKS, HTTP, mixed, Naive, Mieru, ShadowTLS и WireGuard при изменении пользователя перестраивают свой единственный элемент.
• Форма туннеля: его порты, TLS, транспорт или балансировка.

Перестройка обходится дешевле, чем кажется:

• Перестроенный TCP-инбаунд сохраняет открытые соединения.
• Перестроенный QUIC-инбаунд (Hysteria2, TUIC) сообщает об этом клиентам, и они сразу переподключаются, а не ждут таймаута.
• Клиенты WireGuard возвращаются примерно через 20 секунд.

Когда узел перезапускается

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

Полную конфигурацию получает и узел, у которого ничего не запущено: только что запущенный или снова включённый.

Плохой элемент не останавливает узел

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

• Элемент, который не удалось построить, пропускается с предупреждением. Всё остальное работает. Предупреждение видно на узле в панели, пока следующее изменение не применит элемент.
• Неудачный запуск откатывается к конфигурации, которая работала, и узел продолжает её обслуживать.
• Неудачное изменение на лету одного элемента попадает в предупреждения узла. Остальные элементы того же изменения всё равно применяются.

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

Самовосстановление

Изменение может не дойти: узел ненадолго был недоступен, шаг был отклонён или два изменения пересеклись. Панель не считает, что изменение дошло:

1. Любое одиночное изменение при неудаче переходит к полному сравнению. Если добавление одного пользователя не удалось, панель сравнивает весь узел с тем, что он должен запускать, и отправляет каждую разницу.
2. Полное сравнение при неудаче переходит к полной отправке, когда у узла ничего не запущено или он не может принять основу на лету.
3. Heartbeat каждые 15 секунд заново отправляет конфигурацию узлу, который не обслуживает то, что получил. Пока узел продолжает отказывать, интервал растёт от 30 секунд до 10 минут.
4. Проверка расхождений каждые 10 минут сравнивает основу каждого узла (маршрутизацию, DNS и наборы правил) с тем, какой она должна быть, и исправляет любую разницу.

Синхронизировать в меню узла запускает то же сравнение вручную.

Наборы правил на узле

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

Новая версия списка приходит как новый файл под новым именем, и узел переключается на него в рамках обновления основы. Файл, который узел читает, никогда не меняется у него под руками. Старые копии удаляются, когда на них больше ничто не ссылается. Список, которого у узла нет, пропускается вместе с правилами, которые на него ссылаются, вместо того чтобы ломать узел.

Что никогда не отправляется

• Элементы, которые обслуживали бы кого угодно или никого. Инбаунд без пользователей пропускается там, где пустой список пользователей сделал бы открытый прокси (SOCKS, HTTP, mixed) или сервер с одним общим ключом (Shadowsocks, Snell), и то же относится к серверу OpenVPN или OpenConnect без пользователей. Он отправляется, как только у него появляется пользователь.
• Пользователь без учётных данных, которые нужны его протоколу. Этот пользователь пропускается в этом инбаунде с предупреждением на узле, а все остальные пользователи обслуживаются.

Связанные страницы

• Узел и его панель: сессии, heartbeat и что делает узел без своей панели.
• Внутри туннеля: как состав туннеля меняется на лету.
• Узлы: список узлов, их предупреждения и действие Синхронизировать.