TUIC на Ubuntu 24.04: пошаговая установка

MAATRIX

TUIC — прокси-протокол, построенный поверх QUIC с нуля, а не адаптированный под него задним числом. Это даёт короткое TLS-рукопожатие, встроенную передачу UDP без отдельного туннеля и congestion control, который можно переключать прямо в конфиге. Разберём установку tuic-server на Ubuntu 24.04: сертификат, systemd-юнит, разбор полей config.json и настройку клиента.

Что такое TUIC v5 и чем он отличается от других протоколов на QUIC

TUIC (The Universal Internet Connection) написан на Rust поверх библиотеки quinn — той же реализации QUIC, что используют многие современные прокси-инструменты. Пятая версия протокола — это переработка второй-третьей: другая схема аутентификации, встроенный релей UDP как нативная часть QUIC-потока, а не отдельный костыль поверх него.

Ключевое отличие от связки VLESS+Reality или Hysteria в том, что TUIC изначально проектировался как QUIC-протокол, а не TLS-протокол, притворяющийся QUIC. У Reality акцент на маскировке под чужой TLS-хендшейк, у TUIC — на эффективности самого транспорта: 0-RTT переподключение, мультиплексирование потоков без head-of-line blocking на уровне UDP-датаграмм, встроенный выбор алгоритма congestion control. За различиями между семействами протоколов удобно следить по общему гиду по выбору протокола VPN — TUIC там стоит рассматривать в одной категории с Hysteria2, а не с классическими OpenVPN/WireGuard.

Минус у подхода тоже есть: трафик TUIC — это UDP на 443 порту с ALPN h3, похожий на HTTP/3, но не идентичный ему побайтово. В сетях, где фильтрация анализирует QUIC глубже простого ALPN-совпадения, это может быть заметнее, чем у протоколов, точнее копирующих поведение браузера. Честных бенчмарков «TUIC против X» без привязки к конкретной сети приводить не буду — разница сильно зависит от маршрута и качества UDP на участке.

Репозиторий проекта на GitHub периодически переходит между мейнтейнерами — оригинальный EAimTY/tuic какое-то время не получал обновлений, разработку подхватывали форки сообщества. Перед установкой стоит проверить на GitHub, какой репозиторий сейчас активен и какая версия последняя на вкладке Releases — команды ниже используют переменные под актуальный URL.

Подготовка сервера: домен и TLS-сертификат

TUIC работает только поверх TLS — сертификат обязателен, самоподписанный тоже подойдёт, но с оговорками. Понадобится сервер на Ubuntu 24.04 с публичным IP и, желательно, доменом, направленным на этот IP через A-запись.

Если домен есть, проще всего выпустить сертификат Let's Encrypt через certbot в standalone-режиме (порт 80 нужен временно, TUIC на нём не слушает):

apt update && apt install -y certbot
certbot certonly --standalone -d vpn.example.com --agree-tos -m you@example.com

Конфликта портов с TUIC не будет: certbot в standalone-режиме занимает TCP 80/443 только на время выпуска сертификата, а TUIC слушает UDP. Про сам выбор между certbot и acme.sh, если нужен более гибкий вариант с DNS-валидацией, — в отдельном сравнении certbot или acme.sh.

Сертификаты появятся в /etc/letsencrypt/live/vpn.example.com/fullchain.pem и privkey.pem. Настройте автопродление и хук на перезапуск tuic-server (юнит появится в следующем разделе):

echo '#!/bin/sh
systemctl restart tuic-server' > /etc/letsencrypt/renewal-hooks/deploy/tuic-restart.sh
chmod +x /etc/letsencrypt/renewal-hooks/deploy/tuic-restart.sh

Если домена нет и сервер идентифицируется только по IP, можно сгенерировать самоподписанный сертификат:

mkdir -p /etc/tuic
openssl req -x509 -nodes -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -keyout /etc/tuic/key.pem -out /etc/tuic/cert.pem \
  -subj "/CN=tuic" -days 3650

В этом случае на клиенте придётся явно отключить проверку сертификата ("insecure": true) — это работает, но чуть слабее с точки зрения защиты от MITM на пути. Для личного использования — приемлемый компромисс, для чувствительных сценариев лучше настоящий домен и Let's Encrypt.

Установка tuic-server и systemd-юнит

Готовых пакетов в apt нет, ставится бинарник с GitHub Releases. Определите архитектуру и скачайте актуальный релиз (замените ссылку на ту, что видите в Releases выбранного репозитория на момент установки):

mkdir -p /etc/tuic && cd /etc/tuic
wget -O tuic-server https://github.com/<актуальный-репозиторий>/releases/download/<версия>/tuic-server-x86_64-unknown-linux-gnu
chmod +x tuic-server
mv tuic-server /usr/local/bin/tuic-server

Создайте отдельного системного пользователя без домашнего каталога и без права на логин — процесс не должен работать от root:

useradd -r -s /usr/sbin/nologin tuic
chown -R tuic:tuic /etc/tuic

Юнит systemd /etc/systemd/system/tuic-server.service:

[Unit]
Description=TUIC v5 server
After=network.target

[Service]
Type=simple
User=tuic
Group=tuic
WorkingDirectory=/etc/tuic
ExecStart=/usr/local/bin/tuic-server -c /etc/tuic/server.json
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Пока не создан server.json, запуск смысла не имеет — конфиг соберём в следующем разделе, после чего включите и запустите сервис:

systemctl daemon-reload
systemctl enable --now tuic-server
systemctl status tuic-server

Конфигурация сервера: config.json и congestion control

Создайте /etc/tuic/server.json. UUID для пользователя проще всего сгенерировать через uuidgen, пароль — любая случайная строка:

uuidgen

{
  "server": "[::]:443",
  "users": {
    "8f14e45f-ceea-467e-9c05-b46bd8d6f2e1": "СложныйПароль123!"
  },
  "certificate": "/etc/letsencrypt/live/vpn.example.com/fullchain.pem",
  "private_key": "/etc/letsencrypt/live/vpn.example.com/privkey.pem",
  "congestion_control": "bbr",
  "alpn": ["h3"],
  "udp_relay_ipv6": true,
  "zero_rtt_handshake": false,
  "dual_stack": true,
  "auth_timeout": "3s",
  "task_negotiation_timeout": "3s",
  "max_idle_time": "10s",
  "max_external_packet_size": 1500,
  "send_window": 8388608,
  "receive_window": 8388608,
  "gc_interval": "3s",
  "gc_lifetime": "15s",
  "log_level": "warn"
}

Важный момент, который часто путают: congestion_control в этом файле — алгоритм для QUIC-соединения, реализованный в userspace библиотекой quinn (варианты — cubic, new_reno, bbr). Это не то же самое, что системный net.ipv4.tcp_congestion_control=bbr в sysctl — тот управляет congestion control для TCP-потоков ядра и на трафик TUIC, который целиком идёт по UDP, не влияет напрямую. Включать bbr нужно именно в конфиге, а не только на уровне ядра.

Кернельный BBR и увеличенные буферы сокетов всё же стоит включить отдельно — они помогают общей пропускной способности UDP на сервере, даже без прямого влияния на congestion control внутри самого QUIC-соединения TUIC:

cat >> /etc/sysctl.conf <<EOF
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl -p

zero_rtt_handshake оставьте выключенным, если не разбирались в компромиссах 0-RTT — при включении первый пакет данных может быть уязвим к replay-атаке в узком окне между переподключениями. send_window/receive_window по 8 МБ — разумный дефолт для большинства каналов; поднимать их стоит только на линках с большим произведением задержки на пропускную способность, и точную выгоду без измерений на конкретном канале не предскажешь.

Настройка клиента и файрвол

На сервере откройте UDP-порт, который слушает TUIC:

ufw allow 443/udp

Базовые принципы работы с UFW на Ubuntu 24.04, если файрвол ещё не настраивался, — в отдельной статье про установку UFW. Не забудьте также открыть порт в панели облачного провайдера, если у него есть отдельная security group — UFW внутри системы не заменяет её.

Клиентский client.json (используется вместе с tuic-client, тем же бинарником с Releases, только клиентской сборкой):

{
  "relay": {
    "server": "vpn.example.com:443",
    "uuid": "8f14e45f-ceea-467e-9c05-b46bd8d6f2e1",
    "password": "СложныйПароль123!",
    "congestion_control": "bbr",
    "udp_relay_mode": "native",
    "alpn": ["h3"],
    "zero_rtt_handshake": false,
    "disable_sni": false,
    "timeout": "8s",
    "heartbeat": "3s"
  },
  "local": {
    "server": "127.0.0.1:1080"
  },
  "log_level": "warn"
}

udp_relay_mode: native использует нативные QUIC-датаграммы для UDP-трафика — быстрее, но требует, чтобы сеть между клиентом и сервером не резала пакеты нестандартного размера. Если UDP внутри туннеля (игры, голосовые звонки) ведёт себя нестабильно, попробуйте режим quic — совместимее, но с чуть большим оверхедом. С самоподписанным сертификатом из предыдущего раздела добавьте в блок relay поле "insecure": true.

Для десктопа проще запускать tuic-client как фоновый процесс и поднимать на его SOCKS5-порту (127.0.0.1:1080) остальной трафик через системные настройки прокси или через приложение вроде sing-box/NekoRay, которые умеют TUIC как один из outbound-протоколов и избавляют от ручной правки JSON. Нативного клиента под мобильные платформы в App Store/Google Play нет — там тоже придётся идти через универсальные клиенты с поддержкой TUIC-outbound.

Проверка, диагностика и типичные ошибки

После запуска клиента проверьте, что SOCKS5-прокси поднялся:

curl -x socks5h://127.0.0.1:1080 https://ifconfig.me

Ответ должен вернуть IP сервера, а не локальный. Если curl зависает или обрывается, первым делом смотрите логи обеих сторон — на сервере через journalctl -u tuic-server -f, на клиенте — в stdout процесса.

Частые причины сбоя:

Если проблема шире конкретно TUIC и касается общей работы QUIC/HTTP-3 на сервере — сертификатов, ALPN, MTU для UDP-фрагментации — стоит свериться с отдельным разбором частых ошибок HTTP/3 и QUIC на сервере, многие причины пересекаются, поскольку оба используют один транспорт. Отдельно проверьте MTU: если пропадают только крупные передачи, а мелкие запросы работают, — это почти всегда PMTUD, а не проблема самого TUIC.

Частые вопросы