Путь пакета
Эта страница прослеживает одно соединение через узел, с момента, когда оно доходит до узла, до момента, когда оно уходит в интернет. Она полезна, когда нужно понять, где действует настройка: какой уровень читает сертификат, где узнают пользователя и где находятся лимиты и счётчики.
Выберите блок на схеме, чтобы прочитать, что происходит на этом этапе. Разделы ниже говорят то же самое подробнее.
Выберите блок, чтобы прочитать, что в нём происходит.
Два отдельных пути
Узел несёт два вида трафика, которые никогда не смешиваются:
- Путь данных: соединения ваших пользователей, через этапы на этой странице.
- Путь управления: панель говорит с узлом через собственный порт, со взаимным TLS. Она отправляет конфигурацию, пользователей и лимиты и собирает счётчики. Ничто из отправленного панелью не проходит через соединение пользователя, а соединение пользователя никогда не доходит до панели.
Они встречаются только в трёх местах: в таблице пользователей, которых принимает каждый инбаунд, в таблице лимитов для каждого пользователя и в счётчиках трафика. Всё остальное, что держит узел, пришло от панели и живёт в памяти; см. Узел и его панель.
1. Слушатель
Соединение приходит на порт, который узел открыл для инбаунда. Есть три варианта:
| Вариант | Что он делает |
|---|---|
| Один инбаунд, один порт | Обычный случай. Порт принадлежит только этому инбаунду. |
| Ingress | Один порт, обычно 443, общий для нескольких инбаундов. Ingress читает имя и прикладной протокол в TLS-рукопожатии и передаёт соединение, внутри узла, инбаунду, который назван в правиле. |
| Набор портов (смена портов) | Для Hysteria и Hysteria2. Узел слушает каждый порт набора, до 512, и отвечает каждому клиенту с того порта, на который тот отправлял. |
Ingress передаёт соединение внутри того же процесса; он не пересылает его на другой порт. Поэтому сохраняется настоящий адрес пользователя, а с ним и все механизмы для каждого пользователя дальше: счётчики, лимит адресов и ограничение скорости видят пользователя, а не ingress. Правила проверяются по порядку, и срабатывает первое совпавшее. Подробности и два режима ingress описаны в Один порт для многих инбаундов.
Смену портов выполняет сам узел, без правил файрвола. Клиент, который меняет порт каждые несколько секунд, всё равно получает ответы с того порта, который использовал, потому что узел помнит, где каждого клиента видели последний раз.
2. TLS, REALITY и транспорт
Если инбаунд использует TLS, рукопожатие завершается здесь с сертификатом, который панель вставила в конфигурацию узла. Инбаунд REALITY завершает собственное рукопожатие с ключами, которые создала панель. Если перед ним ingress в режиме терминации, этот этап уже выполнил ingress и передаёт инбаунду открытый поток.
Затем снимается транспорт, если он есть у инбаунда: WebSocket, gRPC, HTTP, HTTPUpgrade, XHTTP, mKCP или QUIC. Остаётся собственный поток протокола. VLESS-инбаунд может нести и VLESS Encryption — слой между TLS и протоколом; см. VLESS Encryption.
3. Протокол: пользователь узнан
Протокол (VLESS, VMess, Trojan, Shadowsocks, Hysteria2, TUIC и остальные) читает учётные данные в потоке и ищет пользователя в наборе, который панель дала этому инбаунду. С этого момента соединение несёт имя пользователя.
- Неизвестные учётные данные отклоняются здесь, ещё до маршрутизации.
- Пользователей сопоставляют по учётным данным, а не по позиции. Когда учётную запись удаляют или её учётные данные меняются, узел сразу перестаёт принимать для неё новые потоки, в том числе потоки внутри соединения, которое уже несёт несколько (QUIC, мультиплексирование).
- Лимит устройств здесь не проверяется. Узел не видит устройство, только адрес. Лимит устройств действует, когда приложение получает подписку; см. Трафик, квоты и лимиты.
Эндпоинты сами узнают пользователя
Эндпоинты WireGuard, OpenVPN и OpenConnect пропускают этапы 2 и 3. Они одновременно и вход, и выход, и каждый узнаёт пользователя своим способом: пир WireGuard — по ключам, которые панель создала для этого пользователя, OpenVPN и OpenConnect — по логину пользователя. Затем трафик идёт прямо в маршрутизацию.
Трафик из туннеля
На исходном узле туннеля половина туннеля принимает потоки от ретранслятора и передаёт их прямо в маршрутизацию. Этот трафик не списывается с пользователей на исходном узле, а его адреса не учитываются в лимите адресов: ретранслятор уже учёл пользователя, а на исходном узле адрес источника принадлежит ретранслятору, а не пользователю. См. Внутри туннеля.
4. Сниффинг
Когда этого требуют правила маршрутизации, узел читает первые байты соединения, чтобы понять, что это: доменное имя в TLS- или HTTP-запросе или протокол, например BitTorrent. Тогда правила могут сравнивать настоящий домен, даже если приложение подключилось по адресу, и протоколы, которые пользователь не объявлял.
5. Маршрутизация
Маршрутизация шаблона узла решает, куда идёт соединение. Правила проверяются по порядку и сравнивают домен, адрес, набор правил, протокол, инбаунд, пользователя и другое. Первое совпавшее правило выбирает аутбаунд; если ничего не совпало, соединение берёт итоговый аутбаунд.
- Наборы правил приходят от панели. Панель скачивает каждый список, поддерживает его актуальным и отправляет узлу по управляющему каналу. Узел никогда не скачивает список сам, поэтому недоступность источника списка с узла ничего не меняет.
- Узел может дополнять маршрут шаблона. Собственная маршрутизация узла применяется после маршрутизации шаблона; так один ретранслятор отправляет в туннель только часть трафика.
- Проверка маршрута на узле показывает, с каким правилом совпал бы адрес и куда бы он пошёл, ничего не отправляя. См. Маршрутизация и DNS.
6. Лимиты и счётчики
Когда маршрутизация выбрала аутбаунд, соединение дважды оборачивается, прежде чем сдвинется хоть один байт:
- Лимиты пользователя. Лимит адресов решает, может ли подключиться ещё один адрес-источник этого пользователя. Адрес IPv4 считается сам по себе, адрес IPv6 — по своему /64, и адрес продолжает учитываться десять минут после того, как его видели в последний раз. Ограничение скорости — это бюджет на каждое направление, применяемый на этом узле. Как лимит адресов согласуется по всему парку узлов, описано в Трафик, квоты и лимиты.
- Счётчики. Байты считаются по инбаунду, аутбаунду и пользователю, а соединение попадает в список живых соединений узла.
Лимиты находятся ближе всего к соединению, поэтому ограничение скорости тормозит ровно те байты, о которых сообщают счётчики.
7. Аутбаунд
Аутбаунд отправляет соединение дальше:
| Аутбаунд | Куда идёт соединение |
|---|---|
| Direct | Прямо к цели, с адреса этого узла. |
| Прокси | Дальше через другой указанный вами сервер, например прокси другого провайдера. |
| Block | Отклоняется. Каждый отказ учитывается по блокирующему аутбаунду и по узлу. |
| Туннель | На исходный узел, который отправляет его в интернет. |
| Эндпоинт | Наружу через интерфейс WireGuard или подобный. |
Отказы учитываются, только когда они проходят через аутбаунд типа block, поэтому готовые пресеты, например блокировка торрентов, направляют трафик в блокирующий аутбаунд. Счёт доходит до панели с каждым heartbeat, и панель может создать оповещение, когда его частота становится высокой; см. Мониторинг и метрики.
8. Обратно к пользователю
Ответы возвращаются тем же путём, через те же уровни в обратном порядке: аутбаунд, счётчики, протокол, транспорт и TLS. Те же счётчики видят оба направления.
Куда идут счётчики
Узел держит счётчики в памяти, а панель их собирает:
- Каждые 30 секунд панель собирает счётчики каждого узла. Узел обнуляет каждый счётчик, когда сообщает его, поэтому каждый байт сообщается один раз.
- Каждые 10 секунд панель объединяет адреса, которые видел каждый узел, и отправляет обратно таблицу того, кто откуда может подключаться.
- По запросу панель спрашивает у узла его живые соединения, когда вы открываете их у пользователя или узла.
Что происходит с этими числами дальше, описано в Трафик, квоты и лимиты. Как конфигурация, определившая каждый этап выше, доходит до узла, описано в Изменения без перезапусков.