docs(deploy): описать включение TURN over TLS, обновление сертификата, порты

Раздел 8: как включить TURN_TLS_HOST, почему 443 недоступен coturn без
SNI-мультиплексора (порт уже занят nginx через Docker port-publish),
пошаговая проверка (openssl s_client, аллокации в логах). Раздел 5:
deploy-hook certbot теперь перекопирует сертификат в coturn-certs-init и
перезапускает coturn при продлении — без этого TLS-TURN тихо остановится
через ~60 дней со старым сертификатом.

docs/deploy/DEPLOYMENT.md

@@ -237,7 +237,22 @@ docker compose -f deploy/docker-compose.yml --env-file .env restart nginx
 ```bash
 cat > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh << 'EOF'
 #!/bin/bash
+# certbot renew копирует новый сертификат в /etc/letsencrypt/live/<домен>/,
+# но и nginx, и coturn держат СВОИ копии (docker-entrypoint-certs.sh и
+# coturn-certs-init в deploy/docker-compose.yml) — обе копируются только
+# при СТАРТЕ/пересоздании соответствующего контейнера. Reload недостаточен
+# ни для того, ни для другого — нужен restart.
 docker restart vidconf-nginx-1
+
+# TURN over TLS (см. docs/deploy/DEPLOYMENT.md §8) — только если включён
+# (TURN_TLS_HOST задан в .env). Без coturn-certs-init coturn продолжит
+# держать в памяти старый сертификат ещё ~60 дней, до следующего продления,
+# и TLS-хендшейк начнёт падать с ошибкой валидации сертификата у клиентов.
+cd /opt/vidconf || exit 1
+if grep -qE '^TURN_TLS_HOST=.+' .env; then
+    docker compose -f deploy/docker-compose.yml --env-file .env up -d coturn-certs-init
+    docker restart vidconf-coturn-1
+fi
 EOF
 chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh
 
@@ -277,7 +292,8 @@ docker compose -f deploy/docker-compose.yml --env-file .env --profile monitoring
 docker compose -f deploy/docker-compose.yml --env-file .env ps
 
 # 2. Наружу открыто только ожидаемое (80/443/7881 + udp 54000,
-#    плюс 3478 tcp+udp, если включили TURN — раздел 8)
+#    плюс 3478 tcp+udp и 49160:49200/udp, если включили TURN, плюс 5349/tcp,
+#    если включили TURN over TLS — раздел 8)
 ss -ltnp
 
 # 3. Redis требует пароль (НЕ должен пускать без него)
@@ -359,14 +375,89 @@ state: connected`, но собеседник не видит видео/не с
    Ноль при живом звонке из-за NAT означает, что до coturn не дошли —
    смотрите ufw и `TURN_EXTERNAL_IP`.
 
-**TURN over TLS (порт 5349 или 443) — не настроен.** Это самый надёжный
-фолбэк (проходит там, где режут UDP и нестандартные порты), но требует
-смонтировать в coturn TLS-сертификат: раскомментировать `cert`/`pkey` в
-`deploy/coturn/turnserver.conf.template`, добавить volume с
-`/etc/letsencrypt` (nginx его уже монтирует, coturn — нет), открыть порт и
-не забыть про перезапуск coturn при обновлении сертификата. Пока этого нет,
-`turns:` намеренно не анонсируется: анонс неработающего адреса заставил бы
-клиента ждать таймаута перед переходом к рабочему кандидату.
+### TURN over TLS (порт 5349)
+
+Самый надёжный фолбэк: в жёстких корпоративных сетях наружу часто разрешён
+только `443/tcp`, и TLS-соединение на нестандартный порт (5349) выглядит для
+firewall как обычный HTTPS. UDP/TCP на 3478 такие сети режут целиком.
+
+**443 вместо 5349 невозможен без доп. усложнений**: `443/tcp` на хосте уже
+занят nginx (Docker port-publish биндит хостовый сокет), а coturn слушает в
+`network_mode: host` — оба не могут забрать один и тот же порт без
+SNI-мультиплексора перед ними. Такой мультиплексор — отдельная, более
+сложная система; в этом проекте её нет, и заводить её только ради 443 не
+оправдано, пока 5349 проходит через те же firewall, что и 443.
+
+**Включение — один флаг, `TURN_TLS_HOST` в `.env`:**
+
+```bash
+# Домен сертификата (НЕ IP — см. предупреждение ниже), тот же, что в
+# NGINX_CERT_NAME:
+TURN_TLS_HOST=vidconf.ru
+```
+
+Пусто (dev-дефолт) — TLS выключен полностью и без следов: `render-templates.sh`
+вырезает cert/pkey из `turnserver.conf` и запись `protocol: tls` из
+`rtc.turn_servers` в `livekit.yaml` (маркеры `BEGIN-TLS-*`/`END-TLS-*` в
+`.template`-файлах). Непустое значение включает оба сразу — TLS без анонса
+клиентам (и наоборот) не бывает, ровно один переключатель на всё.
+
+⚠️ **`TURN_TLS_HOST` обязан быть ДОМЕНОМ, не IP** — в отличие от
+`TURN_EXTERNAL_IP`, который остаётся IP-адресом для udp/tcp-записей. Браузер
+проверяет TLS-сертификат TURN-сервера по имени хоста в `turns:`-URL, а
+Let's Encrypt выписывает сертификат на домен. С IP в этом поле TLS-хендшейк
+упадёт на проверке имени сертификата — внешне это будет выглядеть как ещё
+один вариант «coturn healthy, а relay не работает», только на новом порту.
+
+**Права на приватный ключ.** coturn (`nobody:nogroup` внутри контейнера, без
+root-фазы в entrypoint — не то что у nginx, где `docker-entrypoint-certs.sh`
+выполняется от root) физически не может прочитать
+`/etc/letsencrypt/live/<домен>/privkey.pem` (root, обычно `0600`). Решение —
+одноразовый init-контейнер `coturn-certs-init` (busybox, дефолтный root,
+образец — уже существующий `recordings-init`/`llm-models-init` в этом же
+compose-файле): копирует `fullchain.pem`/`privkey.pem` в свой volume
+`coturn-certs` под правами `644`. Это копия, не оригинал — права на ключ на
+хосте не меняются. coturn просто монтирует `coturn-certs:/etc/coturn/certs:ro`
+и ждёт (`depends_on: condition: service_completed_successfully`), пока init
+отработает.
+
+**Обновление сертификата.** certbot продлевает Let's Encrypt раз в ~60 дней
+и обновляет файлы в `/etc/letsencrypt`, но и nginx, и coturn держат свои
+копии, которые перечитываются только при (пере)старте контейнера — reload
+недостаточен ни для одного из них. Deploy-hook (см. шаг 5 выше,
+`/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh`) после `nginx`
+дополнительно пересоздаёт `coturn-certs-init` (перекопировать свежий
+сертификат в volume) и перезапускает `coturn`. Без этого шага TLS-TURN
+тихо остановится обслуживать новые TLS-хендшейки примерно через два
+месяца — coturn будет держать в памяти сертификат, у которого истёк срок
+действия, и клиенты начнут получать ошибку валидации сертификата при
+попытке TLS-хендшейка.
+
+⚠️ Перезапуск `coturn` (и hook, и ручной после включения TLS) может задеть
+активные звонки, идущие через relay, — как и с `livekit` (см. выше),
+выбирайте окно или закладывайтесь на автопродление certbot (раз в ~60 дней,
+непредсказуемое время суток).
+
+Порядок включения:
+
+1. `TURN_TLS_HOST=<домен>` в `.env`.
+2. `./deploy/render-templates.sh` (перерендерит `turnserver.conf` и
+   `livekit.yaml` с TLS-блоками).
+3. Открыть `5349/tcp` в ufw (IPv4 и IPv6).
+4. `docker compose … up -d --force-recreate coturn-certs-init coturn` —
+   пересоздать (не просто restart: новый volume/depends_on).
+5. Проверить, что TLS реально отвечает:
+   `openssl s_client -connect <домен>:5349 -servername <домен>` — должен
+   показать сертификат Let's Encrypt (`issuer=Let's Encrypt`), а не ошибку
+   соединения.
+6. `docker compose … up -d --force-recreate livekit` — подхватить новую
+   запись `rtc.turn_servers`. ⚠️ Разрывает активные конференции.
+7. Обновить deploy-hook certbot (см. шаг 5) и проверить
+   `certbot renew --dry-run`.
+8. Провести звонок, принудительно загнав клиента в relay-режим (ICE
+   transport policy `relay` в браузере), и убедиться, что аллокации в
+   `docker logs vidconf-coturn-1` растут именно через TLS-соединение, а
+   обычный TURN на 3478 продолжает работать для остальных клиентов.
 
 ---