TUIC на Debian 12: пошаговая установка

MAATRIX

Классический VPN поверх TCP на нестабильных мобильных сетях или под агрессивным DPI ведёт себя предсказуемо плохо: любая потеря пакета в туннеле вызывает двойную ретрансмиссию — сначала на уровне TCP-туннеля, потом на уровне TCP-приложения внутри него. TUIC решает эту проблему иначе: он строится поверх QUIC (тот же транспорт, что у HTTP/3), где TLS 1.3 встроен прямо в рукопожатие, задержка на подключение минимальна, а к обрывам сети протокол устойчивее, чем классика. Ниже — установка TUIC-сервера на Debian 12 с нуля: бинарник, сертификат, конфиг и клиент.

Что такое TUIC и когда он оправдан

TUIC (The Ultimate Internet Connection) — это не VPN в классическом смысле, а прокси-протокол поверх QUIC/UDP. Он ретранслирует TCP- и UDP-соединения, которые запрашивает клиент, примерно как SOCKS5, только на транспорте с встроенным TLS 1.3 и мультиплексированием: несколько логических потоков идут в одном UDP-соединении без head-of-line blocking, характерного для TCP-туннелей. Из практических плюсов — быстрое переподключение (0-RTT для повторных сессий) и то, что трафик QUIC маскируется под обычный HTTP/3, которым сейчас пользуется большая часть веба.

Важная честная оговорка: TUIC работает только по UDP. Если сеть или провайдер режут UDP целиком (так бывает в части корпоративных и мобильных сетей) — соединение просто не установится, автоматического отката на TCP, как у ocserv, здесь нет. Второй нюанс: сам TUIC не создаёт сетевой интерфейс и не заворачивает весь трафик системы по умолчанию — это протокол уровня приложения, клиент поднимает локальный SOCKS5-порт, и весь остальной трафик нужно направить в него отдельно (браузером, sing-box в режиме tun или другим клиентом с поддержкой TUIC). Если нужен именно классический "весь трафик через туннель" без дополнительной настройки — присмотритесь к WireGuard, он проще в этом сценарии.

Оригинальный репозиторий EAimTY/tuic, с которого начинался протокол, архивирован, но активно поддерживаемый форк продолжает развитие, и клиенты с поддержкой TUIC есть в популярных мультипротокольных приложениях (sing-box, NekoBox, hiddify и другие) под все основные платформы.

Подготовка сервера

Ресурсов TUIC требует немного: 1 vCPU и 1 ГБ RAM с запасом хватает на десятки одновременных клиентов, диск — минимальный. Обновите систему перед установкой:

apt update && apt upgrade -y
apt install -y curl wget uuid-runtime

Пакет uuid-runtime даёт утилиту uuidgen — она понадобится для генерации идентификаторов пользователей. Выберите порт для TUIC: по умолчанию в примерах используют 443/udp, что удобно маскирует трафик под HTTP/3-сайт, но если на сервере уже крутится веб-сервер с HTTP/3 (см. настройку HTTP/3 и QUIC на VPS), лучше взять свободный порт, например 8443. Проверить занятость порта:

ss -tulnp | grep 443

Если сервер арендован у облачного провайдера с отдельной панелью firewall (security groups) — откройте нужный UDP-порт и там: правило в ufw внутри системы саму панель провайдера не затрагивает.

Установка TUIC-сервера

Официальных пакетов TUIC в репозиториях Debian нет — сервер ставится готовым бинарником с GitHub Releases. Определите архитектуру сервера и скачайте актуальный релиз через GitHub API — это надёжнее, чем вручную вписывать номер версии, который быстро устаревает:

mkdir -p /etc/tuic
cd /tmp

ARCH=$(uname -m)   # обычно x86_64
curl -s https://api.github.com/repos/Itsusinn/tuic/releases/latest \
  | grep "browser_download_url.*tuic-server-${ARCH}-linux\"" \
  | cut -d '"' -f 4 \
  | xargs -n1 curl -L -o tuic-server

chmod +x tuic-server
mv tuic-server /usr/local/bin/tuic-server

Если в списке ассетов релиза имя файла отличается (проверьте на странице github.com/Itsusinn/tuic/releases — иногда добавляют суффикс -musl для статической сборки без зависимости от glibc), подставьте точное имя вручную в grep. Для тестового сервера без внешних зависимостей musl-сборка предпочтительнее — меньше шансов упереться в несовместимость версий libc.

Проверьте, что бинарник рабочий:

tuic-server --version

TLS-сертификат для TUIC

QUIC требует TLS 1.3 как часть самого транспорта — без сертификата сервер не запустится, это не опциональная надстройка, как в некоторых других протоколах. Два рабочих варианта.

Вариант 1 — самоподписанный сертификат. Быстрее всего для личного использования или теста:

mkdir -p /etc/tuic/ssl
cd /etc/tuic/ssl

openssl req -x509 -newkey rsa:2048 -keyout private.key -out fullchain.cer \
  -days 3650 -nodes -subj "/CN=tuic-server"

Клиенту при таком сертификате нужно будет либо явно доверять его отпечатку, либо отключать проверку сертификата (skip_cert_verify) — это приемлемо для личного сервера, но не для публичного сервиса с посторонними пользователями.

Вариант 2 — Let's Encrypt (нужен домен). Если на сервер указывает домен, честнее и удобнее выпустить настоящий сертификат:

apt install -y certbot
systemctl stop nginx 2>/dev/null   # освободить порт 80, если что-то на нём висит
certbot certonly --standalone -d your-domain.com

Сертификат и ключ окажутся в /etc/letsencrypt/live/your-domain.com/fullchain.pem и privkey.pem. Не забудьте про автопродление (certbot renew по таймеру уже настроен пакетом при установке) и про перезапуск tuic-server после каждого обновления сертификата — иначе сервис продолжит отдавать клиентам устаревший сертификат из памяти до рестарта.

Конфигурация сервера и клиента

TUIC понимает несколько форматов конфига (JSON, JSON5, TOML, YAML) — определяется по расширению файла. Классический и наиболее задокументированный вариант — JSON. Создайте /etc/tuic/server.json:

uuidgen
# сохраните вывод — это UUID пользователя
openssl rand -base64 16
# сохраните вывод — это пароль пользователя

{
    "server": "[::]:8443",
    "users": {
        "ВАШ-UUID-СЮДА": "ВАШ-ПАРОЛЬ-СЮДА"
    },
    "certificate": "/etc/tuic/ssl/fullchain.cer",
    "private_key": "/etc/tuic/ssl/private.key",
    "congestion_control": "bbr",
    "alpn": ["h3"],
    "udp_relay_mode": "native",
    "zero_rtt_handshake": false,
    "log_level": "info"
}

Пояснения по нетривиальным полям. congestion_control — это алгоритм управления перегрузкой самой QUIC-библиотеки (реализация в userspace), а не настройка ядра Linux: включать net.ipv4.tcp_congestion_control=bbr в sysctl отдельно не требуется, это разные вещи. udp_relay_mode: native — режим передачи UDP-пакетов клиента внутри туннеля, подходит для большинства сценариев; quic работает надёжнее на очень нестабильных линиях, но с чуть большими накладными расходами. zero_rtt_handshake ускоряет повторные подключения, но у 0-RTT данных в QUIC есть теоретический риск replay-атаки на неидемпотентные запросы — для личного использования это несущественно, но по умолчанию разумнее оставить false и включать осознанно.

Клиентский конфиг client.json (создаётся уже на устройстве, с которого вы подключаетесь):

{
    "relay": {
        "server": "ВАШ-IP-ИЛИ-ДОМЕН:8443",
        "uuid": "ВАШ-UUID-СЮДА",
        "password": "ВАШ-ПАРОЛЬ-СЮДА",
        "certificates": ["/etc/tuic/ssl/fullchain.cer"],
        "congestion_control": "bbr",
        "alpn": ["h3"],
        "udp_relay_mode": "native"
    },
    "local": {
        "server": "127.0.0.1:1080"
    },
    "log_level": "info"
}

Поле certificates со ссылкой на файл сертификата нужно только для самоподписанного варианта (или можно заменить на "skip_cert_verify": true, менее строго). Для Let's Encrypt-сертификата эти поля вообще не нужны — системный список доверенных CA его и так примет.

Firewall и запуск через systemd

В отличие от VPN на сетевом уровне (WireGuard, OpenVPN, IPsec), TUIC не требует ip_forward и правил NAT/MASQUERADE на сервере — он не маршрутизирует пакеты между интерфейсами, а ретранслирует запрошенные клиентом соединения от своего имени, как обычный прокси. Всё, что нужно на firewall, — открыть выбранный UDP-порт:

ufw allow 8443/udp
ufw status

Создайте юнит systemd /etc/systemd/system/tuic-server.service:

[Unit]
Description=TUIC Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/tuic-server -c /etc/tuic/server.json
Restart=on-failure
RestartSec=5
User=root

[Install]
WantedBy=multi-user.target

Запуск и проверка:

systemctl daemon-reload
systemctl enable --now tuic-server
systemctl status tuic-server
journalctl -u tuic-server -f

В логе при старте должно появиться сообщение о том, что сервер слушает указанный адрес и порт. Если сервис падает сразу после запуска — почти всегда дело в неверном пути к сертификату/ключу в конфиге или в синтаксической ошибке JSON (лишняя запятая — самая частая причина).

Подключение клиента и системный прокси

Клиентский бинарник tuic-client ставится тем же способом, что и серверный — скачиванием из Releases под нужную платформу (Linux, Windows, macOS) или через мультипротокольный клиент с поддержкой TUIC (sing-box, NekoBox и другие — их проще настроить на телефоне). Запуск консольного клиента на Linux/macOS:

./tuic-client -c client.json

После запуска клиент поднимает локальный SOCKS5-прокси на 127.0.0.1:1080 (адрес и порт заданы в секции local конфига). Дальше есть два пути: направить в этот SOCKS5 конкретное приложение или браузер (профиль прокси в настройках), либо для полноценной маршрутизации всего системного трафика поставить поверх sing-box с TUIC в качестве outbound и tun-интерфейсом в качестве inbound — это отдельная настройка, выходящая за рамки самого TUIC, но именно так чаще всего разворачивают TUIC как замену полноценному VPN.

Типичные проблемы при первом подключении:

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