Начните бесплатный 3-дневный пробный период
Зарегистрируйтесь и попробуйте все премиум-функции бесплатно.
*Только для новых пользователей. Один пробный период на пользователя.
Настройка сервера AnyTLS: TLS, пользователи и сеансы
Marcus Reid
11 октября 2026 г.· 11 мин чтения
Настройка сервера AnyTLS создаёт TLS-службу с парольной аутентификацией; клиент проверяет сертификат до передачи прикладного трафика. Здесь используются sing-box 1.14.3 и два разрешённых хоста Ubuntu 24.04 LTS amd64, отдельный серверный unit и клиентский прокси на loopback. Инструкция основана на официальной документации; полного сквозного авторского испытания не было.［1］
Ключевые выводы
- Сертификат и пользовательский пароль решают разные задачи безопасности.
- Для исходной проверки оставьте стандартные padding и поведение простаивающих сеансов.
- После изменения данных проверяйте новые соединения: редактирование файла не доказывает отзыв доступа.
- Восстанавливайте только принадлежащие упражнению службу, правила, копии сертификатов и клиентские настройки.
Когда нужна настройка сервера AnyTLS?
Вы должны управлять всем жизненным циклом собственного узла: выпуском сертификата, закрытым ключом, пользователями, журналами, обновлениями и завершением работы. Начните с распределения обязанностей самостоятельного размещения. Если нужен обычный публичный выход, сначала проверьте, избавит ли управляемый VPN от этой работы.
Описание протокола Trojan даёт контекст для другого TLS-подхода, но не разрешает импортировать профиль Trojan. Объяснение охвата VPN отличает прокси одного приложения от маршрутизации устройства. Здесь рассматривается одинаковое ядро на двух сторонах, без GUI, панелей, сочетаний REALITY и неподтверждённой матрицы совместимости.
Зарезервируйте TCP 24444 на отдельном сервере и loopback 1080 на клиенте. Получите действующую цепочку сертификатов и соответствующий ключ собственного домена через существующий поддерживаемый процесс CA. Назначенный серверу локальный адрес может отличаться от внешнего отображения. Используйте только NAT, которым разрешено управлять.
До установки приватно сохраните версии пакетов, автозапуск служб, APT-источники, относящиеся к задаче правила firewall, адреса и настройки резолвера. Проверьте новое независимое SSH-соединение или консоль провайдера. Все имена и пути ниже должны быть свободны. Если ими владеет действующая установка, остановитесь и согласуйте изменения с владельцем.
Шаг 1: установите стабильное ядро и отдельные данные доступа
Установите Ubuntu-пакеты curl, ca-certificates, openssl, затем добавьте официальный стабильный APT-источник на обеих машинах. Выберите из списка точную пакетную версию с ядром 1.14.3. Заполнитель намеренно не является устанавливаемой версией. Если требуемого выпуска нет, остановитесь, не заменяя его beta.［5］
sudo apt-get update
sudo apt-get install curl ca-certificates openssl
sudo install -d -m 755 /etc/apt/keyrings
sudo curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc
sudo chmod 644 /etc/apt/keyrings/sagernet.asc
sudo tee /etc/apt/sources.list.d/sagernet.sources >/dev/null <<'REPO'
Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc
REPO
sudo apt-get update
apt-cache madison sing-box
sudo apt-get install sing-box='APT_VERSION_FOR_1.14.3' curl ca-certificates openssl
sing-box version
Проверьте версию обоих исполняемых файлов. Сохраните восстанавливаемый пакет или официальный артефакт и изучайте сведения о выпусках и безопасности перед обновлением. Проверьте стандартную службу пакета; упражнение не запускает и не использует чужой рабочий unit.
На сервере создайте изолированную учётную запись, скопируйте уже выданную цепочку и закрытый ключ. Замените /PRIVATE/SOURCE/ реальным защищённым источником. Клиенту закрытый ключ не нужен.［4］
sudo useradd --system --user-group --no-create-home --shell /usr/sbin/nologin sbanytls
sudo install -d -o root -g sbanytls -m 750 /etc/sing-box-anytls
sudo install -o root -g sbanytls -m 640 /PRIVATE/SOURCE/fullchain.pem /etc/sing-box-anytls/fullchain.pem
sudo install -o root -g sbanytls -m 640 /PRIVATE/SOURCE/privkey.pem /etc/sing-box-anytls/privkey.pem
Создайте отдельный пароль в приватном терминале через openssl rand -base64 32, безопасно сохраните и передайте по разрешённому защищённому каналу. Вставляйте его в закрытый редактор, не в аргументы shell. Не распространяйте профили, снимки экрана или журналы с многократно используемыми данными доступа. users.name — метка пользователя, пароль — секрет аутентификации.［2］
Шаг 2: настройте AnyTLS в sing-box и службу
Создайте /etc/sing-box-anytls/config.json приватным редактором с необходимыми правами. Подставьте назначенный хосту IPv4 вместо SERVER_LOCAL_IPV4, одинаковый пароль — с обеих сторон. Владелец файла root:sbanytls, права 640.
{
"log": {
"level": "info"
},
"dns": {
"servers": [
{
"type": "local",
"tag": "system-dns"
}
]
},
"inbounds": [
{
"type": "anytls",
"tag": "anytls-in",
"listen": "SERVER_LOCAL_IPV4",
"listen_port": 24444,
"users": [
{
"name": "reader-test",
"password": "REPLACE_WITH_PRIVATE_PASSWORD"
}
],
"tls": {
"enabled": true,
"certificate_path": "/etc/sing-box-anytls/fullchain.pem",
"key_path": "/etc/sing-box-anytls/privkey.pem"
}
}
],
"outbounds": [
{
"type": "direct",
"tag": "direct"
}
],
"route": {
"final": "direct",
"default_domain_resolver": "system-dns"
}
}
Не указывайте padding_scheme: используется стандартная схема реализации. Настройка padding вне этой задачи и не доказывает невидимость или надёжность в определённой сети. Локальный DNS-сервер (type: local) и default_domain_resolver явно задают серверное разрешение имён назначения, не меняя системный резолвер клиента.［2］［6］
Сохраните отдельный unit в /etc/systemd/system/sing-box-anytls.service, владелец root, права 644. Он не требует низкого привилегированного порта и доступа к домашнему каталогу пользователя.
[Unit]
Description=Isolated sing-box anytls reader exercise
After=network-online.target
Wants=network-online.target
[Service]
User=sbanytls
Group=sbanytls
ExecStart=/usr/bin/sing-box run -c /etc/sing-box-anytls/config.json
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
Restart=on-failure
RestartSec=3
[Install]
WantedBy=multi-user.target
sudo -u sbanytls /usr/bin/sing-box check -c /etc/sing-box-anytls/config.json
sudo systemctl daemon-reload
sudo systemctl start sing-box-anytls.service
sudo systemctl status sing-box-anytls.service --no-pager
sudo ss -lntp
Успешная проверка или состояние active не подтверждают TLS, принятие пароля или пересылку. Просмотрите ограниченный журнал: sudo journalctl -u sing-box-anytls.service -n 30 --no-pager. Перед передачей диагностики удалите адреса и секреты. При ошибке чтения исправляйте владельца и права, а не расширяйте доступ к ключу.
Шаг 3: ограничьте TCP-доступ и подключите loopback-клиент
Сохраните существующее управление firewall. Только если UFW уже активен и владеет политикой, разрешите TCP от видимого публичного адреса тестового клиента к локальному адресу сервера, порт 24444, комментарий anytls-test. При необходимости добавьте столь же узкое правило провайдера. Запишите точные изменения, сохраните управление и не сбрасывайте общий firewall.
Для этого случая замените оба адреса перед командой:
sudo ufw allow proto tcp from CLIENT_PUBLIC_IP to SERVER_LOCAL_IPV4 port 24444 comment 'anytls-test'
Приватно создайте anytls-client.json. Укажите доступный числовой адрес вместо SERVER_PUBLIC_IPV4, настоящее имя сертификата вместо anytls.example.com. Клиент подключается к выбранному IP, проверяя доменное имя сертификата. Сохраните insecure: false.［4］
{
"log": {
"level": "info"
},
"inbounds": [
{
"type": "mixed",
"tag": "local-in",
"listen": "127.0.0.1",
"listen_port": 1080
}
],
"outbounds": [
{
"type": "anytls",
"tag": "anytls-out",
"server": "SERVER_PUBLIC_IPV4",
"server_port": 24444,
"password": "REPLACE_WITH_PRIVATE_PASSWORD",
"tls": {
"enabled": true,
"server_name": "anytls.example.com",
"insecure": false
}
}
],
"route": {
"final": "anytls-out"
}
}
Параметры простаивающих сеансов опущены. Документация outbound задаёт стандартные интервал проверки и тайм-аут простоя по 30 секунд, минимальное число простаивающих сеансов — ноль. Пять в иллюстрации структуры не является значением по умолчанию. Тайм-аут обрабатывается периодической проверкой, а не задаёт точный момент отключения приложения.［3］
chmod 600 anytls-client.json
sing-box check -c anytls-client.json
sing-box run -c anytls-client.json
Оставьте процесс на переднем плане. Mixed-слушатель принимает явно настроенные HTTP- или SOCKS-клиенты только на loopback, а не перехватывает устройство целиком. Существующие средства сетевого контроля и другие прокси-приложения оставьте неизменными.
Шаг 4: проверьте сертификат TLS для AnyTLS и отказы
Из второго терминала отправьте ограниченный запрос через SOCKS с удалённым разрешением имени:
curl --noproxy "" --proxy socks5h://127.0.0.1:1080 --connect-timeout 5 --max-time 20 https://example.com/
Завершённый запрос подтверждает только проверенный путь приложения. Для браузера настройте отдельный профиль на loopback HTTP-прокси и проверьте адрес, видимый его запросу. Затем восстановите исходный прокси профиля. Эти результаты не подтверждают остальные приложения, DNS, IPv6 или UDP.
Подготовьте приватные копии конфигурации. Остановите только собственный клиент через Ctrl-C, запустите выбранный файл новым процессом и отправьте новый запрос. Иначе аутентифицированное соединение пула может скрыть неверный пароль или имя.
| Проверка читателя | Ожидаемое наблюдение | Значение или восстановление |
|---|---|---|
| Верный пароль и имя сертификата | Новый запрос завершается | Запишите запрос и время приватно, не делая вывод о пропускной способности |
| Изменён только пароль | Новое соединение не аутентифицируется | Проверьте эффективный файл и отсутствие старого слушателя |
| Изменено только имя на посторонний домен | TLS-проверка завершается отказом | Проверьте цепочку и имена; не отключайте проверку |
| Остановлен только этот серверный unit | Новый запрос не проходит | При видимом успехе найдите фактически обслуживающий процесс |
| После простоя клиент отправляет новый запрос | При исправной службе создаётся сеанс | Очистка простаивающего пула сама по себе не является аварией |
| Удалён пользователь, файл проверен, unit перезапущен | Удалённые данные не работают в новом соединении | Перезапуск также прерывает старые соединения этого unit |
| Перезапуск с разрешённым сохранённым или новым пользователем | Новый запрос снова проходит | Верните безопасный файл при отказе, не возвращайте утёкшие данные |
Таблица задаёт проверки, не измеренные результаты. После простоя дольше одного интервала сравните новый запрос и ограниченные журналы обеих сторон. Одна временная отметка не устанавливает точный срок жизни. Длительный активный запрос приложения наблюдайте отдельно: это не простаивающий сеанс пула.［3］
Редактирование файла не гарантирует отзыв пользователя на лету. В отдельном unit намеренно нет ExecReload. Проверяйте конфигурацию и используйте systemctl restart как известную точку прерывания; не объявляйте произвольную команду reload немедленным отзывом сеансов.
Шаг 5: продлите сертификат, отзовите доступ и восстановитесь
Продлите цепочку и ключ существующим процессом, установите соответствующую пару с прежними ограниченными правами. Проверьте файл от имени sbanytls, перезапустите только этот unit и новым соединением подтвердите ожидаемые идентичность и срок действия. Документация TLS описывает перечитывание файлов, но здесь нужна явная проверка после перезапуска, а не одна замена файла.［4］
При компрометации замените пароль и перезапустите unit, прервав его старые соединения. Проверьте новые данные и отказ удалённым. Только затем рассматривайте sudo systemctl enable sing-box-anytls.service, с последующей разрешённой перезагрузкой в окно обслуживания и новым запросом.
Для завершения остановите и отключите unit, остановите свой клиент, удалите только записанные разрешения упражнения у firewall и провайдера. Восстановите браузерный прокси. Сохраните нужную приватную диагностику, удалите unit, копии сертификата и конфигурации, выполните sudo systemctl daemon-reload. Проверьте слушатели, исходное управление и DNS. Удаляйте пакет или APT-источник только если исходная запись подтверждает, что их добавило упражнение и других зависимостей нет. Если восстановление не подтверждено, прекратите изменения и используйте независимый канал управления.
Проверьте установленный файл сертификата: sudo openssl x509 -in /etc/sing-box-anytls/fullchain.pem -noout -subject -issuer -dates. Команда показывает локальные идентичность и срок действия. Дополните её новым запросом клиента с проверкой TLS: чтение файла само по себе не доказывает сертификат, предоставляемый удалённым процессом.
После удаления файлов упражнения удаляйте созданную им учётную запись sbanytls только после проверки, что от её UID или группы больше не зависят процессы, службы и файлы. Используйте sudo userdel sbanytls без принудительного режима и удаления домашнего каталога. Если отдельная группа сохранилась и у неё нет других участников или зависимостей, удалите её через sudo groupdel sbanytls.［7］［8］
Существовавшие ранее идентичности сохраняйте; при неясном владении остановитесь. Удалите принадлежащие упражнению anytls-client.json и копии отрицательных проверок, когда они больше не нужны. Необходимые резервные копии храните приватно и не возвращайте отозванные данные доступа.
Итоги
- Подтвердите TLS-идентичность перед разбором пароля и прикладных ошибок.
- Различайте очистку простоя, новую аутентификацию и прерывание старых сеансов.
- Узко отменяйте собственные изменения и проверяйте исходное состояние службы и клиента.
Часто задаваемые вопросы (FAQ)
Почему не отключить проверку сертификата для диагностики?
Это убирает ту самую проверку идентичности сервера, которую вы пытаетесь установить. Исправляйте имя, цепочку доверия, время или сертификат, сохраняя верификацию.［4］
Можно повторно использовать профиль Trojan?
Нет. Нужны соответствующие поля AnyTLS этой реализации; общее использование TLS не делает протоколы взаимозаменяемыми.
Удаление пользователя немедленно прерывает старый трафик?
Редактирование файла само по себе этого не доказывает. Здесь отдельная служба перезапускается, а удалённые данные проверяются новым соединением.
Простаивающий сеанс означает неисправное соединение?
Нет. Неиспользуемый сеанс пула может очищаться штатно. Сначала проверьте, способен ли следующий запрос установить исправный сеанс.［3］
Нужно копировать минимум пять простаивающих сеансов?
Для этого исходного варианта нет. Стандартное значение — ноль; оставляйте параметры опущенными до обоснованной отдельной настройки.［3］
Успех браузера проверяет весь трафик?
Нет. Проверяется конкретный браузерный путь; остальные приложения, DNS, IPv6 и UDP требуют собственных поддерживаемых настроек и проверок.
Что делать при отказе нового сертификата?
Остановите упражнение либо верните ещё действующую соответствующую пару и безопасный файл. Проверьте новые TLS- и прикладные запросы; не возвращайте скомпрометированный ключ.
Отказ от ответственности: Администрируйте только разрешённые хосты и сети, соблюдая закон и политику. Ожидаемые наблюдения — критерии читательской проверки, а не авторский протокол испытаний или гарантия доступности сети.
Источники:
- sing-box 1.14.3 release — https://github.com/SagerNet/sing-box/releases/tag/v1.14.3
- sing-box AnyTLS inbound — https://sing-box.sagernet.org/configuration/inbound/anytls/
- sing-box AnyTLS outbound — https://sing-box.sagernet.org/configuration/outbound/anytls/
- sing-box TLS configuration — https://sing-box.sagernet.org/configuration/shared/tls/
- sing-box package installation and service management — https://sing-box.sagernet.org/installation/package-manager/
- sing-box local DNS server and route — https://sing-box.sagernet.org/configuration/dns/server/local/
- Ubuntu Noble userdel manual — https://manpages.ubuntu.com/manpages/noble/man8/userdel.8.html
- Ubuntu Noble groupdel manual — https://manpages.ubuntu.com/manpages/noble/man8/groupdel.8.html
Sources checked 11 октября 2026 г.
Рекомендуемые статьи:
