Внутри туннеля

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

Выберите блок, чтобы прочитать, что в нём происходит.

трафик пользователейнастройки и статистика по взаимному TLS

Две половины

Туннель — это две половины на узлах двух видов, и каждая настраивается отдельно:

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

Какая сторона слушает, а какая подключается, — отдельный выбор, режим. В режиме Обратный (по умолчанию) ретранслятор слушает, а каждый исходный узел подключается к нему сам, поэтому исходному узлу не нужен открытый порт и он может стоять за NAT. В режиме Прямой ретранслятор подключается к каждому исходному узлу. В любом случае трафик идёт в одном направлении: пользователи, ретранслятор, исходный узел, интернет.

Ни одна половина не трогает пользователей, инбаунды и правила маршрутов узла. У туннеля свой порт и свои учётные данные; учётная запись для него не создаётся, и инбаунд не используется.

Учётные данные выводятся, а не хранятся

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

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

Связь между узлами по умолчанию защищена REALITY или TLS с сертификатом, который панель выпускает на собственное имя туннеля и который закрепляет другая сторона. И то и другое дополняется при сохранении; заполнять ничего не нужно.

Профили: несколько способов попасть в один туннель

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

• Заблокированный протокол стоит пропускной способности, а не туннеля. Если порт или протокол одного профиля заблокирован, его связи обрываются, а остальные продолжают нести всё.
• Вес задают связи. Каждый исходный узел держит несколько связей (по умолчанию четыре) на профиль. Профиль с шестью связями берёт втрое больше трафика, чем профиль с двумя.
• У каждой связи своё окно перегрузки, поэтому один потерянный пакет тормозит только потоки этой связи.

При двух и более профилях Балансировка выбирает, как используется пул:

Режим	Что несёт новое соединение
Распределение	каждый подключённый профиль; новое соединение берёт связь с наименьшим числом открытых потоков
Приоритет	первый подключённый профиль в списке; следующий используется, только когда у него нет связей

Пользователь закреплён за одним исходным узлом

Для каждого нового соединения ретранслятор выбирает в таком порядке:

1. Исходный узел — по имени пользователя. Один и тот же пользователь каждый раз попадает на один и тот же исходный узел, пока тот подключён. Поэтому его выходной адрес не меняется между соединениями, и сайты не разлогинивают его и не просят пройти CAPTCHA.
2. Профиль — по режиму балансировки.
3. Связь — наименее загруженную.

Ни один режим балансировки не меняет того, до какого исходного узла доходит пользователь. Потеря профиля стоит пропускной способности; она никогда не переводит пользователя на другой выход. Когда теряется целый исходный узел, на другой переходят только пользователи, которые были на нём.

Несколько адресов: горячее резервирование

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

Изменения доходят до узлов на лету

Создание, изменение, отключение или удаление туннеля не перезапускает ядро ни одного из узлов.

• Состав меняется на лету: добавление или удаление исходного узла, смена учётных данных, перевыпуск сертификата партнёра. Поднятые связи остаются; связи удалённого исходного узла обрываются, и он больше не допускается.
• Форма перестраивает половину этого туннеля: его порты, защиту, транспорт, балансировку или окна. Затрагивается только этот туннель; все остальные элементы на узле продолжают работать.
• Итоговый аутбаунд ретранслятора меняется в рамках обновления маршрутизации на лету.

Как вообще работают изменения на лету и перестройки, описано в Изменения без перезапусков.

Трафик и учёт

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

Состояние

Состояние туннеля нельзя прочитать из его настроек, поэтому панель спрашивает узлы.

• Исправное состояние показано как Соединений: n — у ретранслятора есть n поднятых связей.
• Нет соединений означает, что ретранслятор отвечает, но к нему не подключён ни один исходный узел.
• Ретранслятор недоступен означает, что панель не может дойти до ретранслятора.

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

Когда конфигурация верна, но ничего не идёт

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

Один туннель на ретранслятор

Несколько ретрансляторов, ведущих к одним и тем же исходным узлам, — это по одному туннелю на ретранслятор. Тогда учётные данные, взятые с одного ретранслятора, ничего не открывают на другом, а добавление ретранслятора — это новый туннель, а не правка тех, что уже несут трафик. Дублировать копирует туннель для другого ретранслятора с собственными новыми ключами.

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

• Туннели: создание и работа с туннелями.
• Путь пакета: где туннель находится на пути соединения.
• Трафик, квоты и лимиты: как трафик учитывается и ограничивается.