Быстрый старт сервера

Это руководство настраивает развёртывание по умолчанию: ретранслятор занимает публичный порт 443, сам завершает TLS 1.3 и получает сертификат от Let’s Encrypt встроенным клиентом ACME. Нет ни порта 80, ни certbot, ни прокси перед ним. Для FreeBSD см. FreeBSD.

Требования

Хост Linux с systemd и публичным адресом IPv4 или IPv6.
DNS-имя для ретранслятора, например chat.example.com.
Публичный TCP-порт 443, который ведёт прямо на этот хост. Простой проброс порта подходит. TLS должен завершаться на ретрансляторе: обратный прокси или CDN, завершающие TLS перед ним, ломают выпуск сертификата и каждое подключение клиентов.

1. Направьте DNS на хост

Создайте запись A, а если у хоста есть IPv6 — ещё и AAAA:

chat.example.com.  300  IN  A     203.0.113.10
chat.example.com.  300  IN  AAAA  2001:db8::10

Прежде чем продолжить, убедитесь, что имя разрешается:

dig +short chat.example.com

2. Установите исполняемый файл

curl -fsSL https://assets.r-chat.net/install.sh | sudo sh

Скрипт скачивает выпущенный исполняемый файл для этого хоста, проверяет его контрольную сумму SHA-256 и устанавливает его в /usr/local/bin/rchat-server. Он также создаёт пользователя rchat, каталоги /var/lib/rchat (режим 0700) и /etc/rchat и устанавливает юнит systemd. Он никогда не перезаписывает существующие конфигурацию, ключ или юнит. На странице Установка описаны его параметры, ручная проверка загрузки и сборка из исходного кода.

3. Напишите конфигурацию

Сгенерируйте случайный путь WebSocket. До ретранслятора доходят только upgrade-запросы на этот точный путь, а на все остальные запросы отвечает сайт-приманка:

echo "/$(openssl rand -base64 24 | tr '+/' '-_')"

Создайте /etc/rchat/server.toml:

[server]
bind_addr = "0.0.0.0:443"
websocket_path = "/paste-the-random-path-here"
relay_identity_path = "/var/lib/rchat/relay_identity.key"

[server.acme]
enabled   = true
domains   = ["chat.example.com"]
contacts  = ["mailto:[email protected]"]
cache_dir = "/var/lib/rchat/acme"
staging   = true

sudo install -m 0640 -g rchat server.toml /etc/rchat/server.toml

Параметр websocket_path обязателен. Шаблон в репозитории содержит /CHANGE-ME-to-a-long-random-path, и сервер отказывается запускаться, пока путь содержит CHANGE-ME. Каждый ключ должен быть написан правильно: неизвестный ключ останавливает сервер.

staging = true сначала получает недоверенный тестовый сертификат, чтобы ошибка в DNS или брандмауэре не израсходовала производственные лимиты Let’s Encrypt. Вы отключите его на шаге 7.

Сообщения для получателей не в сети по умолчанию хранятся в памяти 72 часа, и на диск ничего не записывается. Чтобы это изменить, см. Офлайн-очередь.

4. Создайте идентичность ретранслятора

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

sudo -u rchat /usr/local/bin/rchat-server --config /etc/rchat/server.toml --init-relay-identity

Команда записывает /var/lib/rchat/relay_identity.key и выводит пин ретранслятора (rk:1:…). Ретранслятор, запущенный с файлом конфигурации, без этого ключа не стартует, а --init-relay-identity никогда не перезаписывает существующий ключ. Делайте его резервную копию, как для ключа TLS. О публикации пина и ротации ключа см. Идентичность ретранслятора.

5. Запустите службу

install.sh установил юнит systemd как /etc/systemd/system/rchat-server.service. Он запускает ретранслятор от непривилегированного пользователя rchat, привязывает порт 443 через CAP_NET_BIND_SERVICE и держит /var/lib/rchat в режиме 0700 (см. Запуск как службы). Запустите его:

sudo systemctl daemon-reload
sudo systemctl enable --now rchat-server

Откройте порт 443/tcp в брандмауэре, если он ещё не открыт.

6. Следите за первым выпуском сертификата

journalctl -u rchat-server -f

Вы должны увидеть в таком порядке:

WARN ACME: no certificate cached yet. TLS handshakes will FAIL until Let's Encrypt issues one ...
INFO WebSocket server listening on 0.0.0.0:443 (TLS 1.3)
INFO ACME: certificate issued and deployed; TLS is ready

Пока не появится последняя строка, рукопожатия TLS не проходят. Временного сертификата нет. Если выпуск не удался, ретранслятор продолжает работать и повторяет попытки; см. TLS и сертификаты.

7. Переключитесь на производственный режим

Когда тестовый сертификат выпущен, установите staging = false в /etc/rchat/server.toml и перезапустите:

sudo systemctl restart rchat-server

Проверьте результат:

openssl s_client -connect chat.example.com:443 -servername chat.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

В издателе больше не должно быть STAGING. Продление автоматическое и не требует перезапуска.

8. Подключите приложение

В приложении rChat укажите URL сервера: ваш хост плюс путь WebSocket:

wss://chat.example.com/paste-the-random-path-here

Подключитесь один раз, чтобы проверить развёртывание. Если приложение пишет «This server couldn’t prove its identity», значит, что-то перед ретранслятором завершает TLS.

Дайте пользователям и пин ретранслятора, чтобы они могли ввести его в настройках подключения, а не доверять первому подключению:

sudo -u rchat /usr/local/bin/rchat-server --config /etc/rchat/server.toml --print-relay-pin

Как пригласить людей на ваш ретранслятор

Приглашение — это одна ссылка, показанная в виде QR-кода, которая настраивает rChat на ваш ретранслятор: в ней есть адрес ретранслятора (с секретным путём WebSocket) и пин его идентичности. Выведите его от имени служебного пользователя:

sudo -u rchat /usr/local/bin/rchat-server --config /etc/rchat/server.toml --print-invite
# FreeBSD:
su -m rchat -c '/usr/local/bin/rchat-server --config /usr/local/etc/rchat/server.toml --print-invite'

Команда выводит ссылку (rchat://relay?u=…&pin=…) и рисует QR-код в терминале. Имя хоста берётся из host в [server.decoy], иначе из первого домена [server.acme]; если нет ни того, ни другого, команда останавливается и просит задать host. Порт в ссылку не входит, если клиенты подключаются к 443. Задайте public_port в [server] (или передайте --public-port), если клиенты подключаются к другому порту, чем тот, на котором слушает ретранслятор, например за NAT, правилом pf rdr или в jail; без этого ретранслятор считает порт равным 443 за фронтендом с протоколом PROXY и своему порту привязки в остальных случаях.

В приложении люди нажимают Scan relay invite (или Paste invite, если у них ссылка) на экране подключения или в разделе «Настройки → Подключение». Приложение показывает имя хоста ретранслятора и спрашивает подтверждение, прежде чем что-либо сохранить. Затем оно сразу закрепляет идентичность ретранслятора, поэтому ретранслятор, который отвечает с другой идентичностью, отклоняется даже при первом подключении. Любой, кто уже подключён, может снова поделиться приглашением в разделе «Настройки → Подключение → Invite someone to this relay».

Любой, у кого есть это приглашение, может подключиться к вашему ретранслятору. Читать сообщения он не может. Делитесь приглашением с теми, кого хотите видеть на ретрансляторе, и не публикуйте его на открытых страницах и в журналах: ретранслятор никогда его не записывает, install.sh выводит только команду, а provision.sh выводит приглашение, только когда запущен в терминале (иначе выводит команду).

Дальнейшие шаги

Идентичность ретранслятора: публикация пина, резервные копии и ротация.
TLS и сертификаты: как работает ACME, статические сертификаты и устранение неполадок.
Руководство по настройке и полный справочник.
Ограничения ресурсов и метрики
Что ретранслятор записывает и хранит
Модель безопасности