--- date: 2026-03-05 type: reference tags: [claude-memory, niikn, matrix, mas, talk] --- # MAS НИИКН — ОТКАЧЕН 2026-03-05 ## Статус MAS: ОТКАЧЕН (snapshot rollback) - Proxmox snapshot `pre-mas-deploy` → восстановлен на VM 107 - msc4108_enabled: изменён на false в homeserver.yaml (без MAS вызывает краш Synapse) - NPM server_proxy.conf удалён с LXC 102 - Nextcloud OIDC: восстановлен client "Matrix Synapse" с redirect /_synapse/client/oidc/callback ## Nextcloud Talk (VM 108, 192.168.1.200) — РАБОТАЕТ - TURN: niikn.com:3479, secret: ebf6a8ce0fd1629c2da55356169feea7ab118a18368c2550 - STUN: stun.nextcloud.com:443 + niikn.com:3479 - Signaling: https://niikn.com/standalone-signaling/ - eturnal (TURN) внутри NC AIO Docker (172.18.0.4:3479) - Janus (WebRTC SFU) внутри того же контейнера ## Исправление: Janus nat_1_1_mapping для внешних звонков - **Проблема**: Janus рекламировал Docker-внутренние IP (172.18.0.4, fd74:...) как ICE кандидаты - Внешние клиенты (iPhone по сотовой) не могли установить WebRTC соединение — ICE failed - **Решение**: `nat_1_1_mapping = "85.235.181.190"` и `rtp_port_range = "20000-20100"` в janus.jcfg - eturnal: `relay_ipv4_addr: "85.235.181.190"` (вместо контейнерного IP) - Контейнер read-only rootfs → конфиг копируется в /tmp, Janus перезапускается с /tmp/janus.jcfg - **Убран `--full-trickle`** — с ним ICE-кандидаты терялись из-за race condition в сигнальном сервере - С full-trickle: кандидаты отправляются отдельно от SDP → "No MCU subscriber found" → потеряны - Без full-trickle (half-trickle): кандидаты включены в SDP → доставляются надёжно - **Автопатч**: `/opt/talk-janus-patch.sh` + systemd `talk-janus-patch.service` (enabled) - Скрипт: ждёт контейнер → iptables DNAT+MASQUERADE → патчит eturnal.yml → копирует/патчит janus.jcfg → перезапускает Janus без --full-trickle → убивает signaling (supervisord рестартит) ## Текущее состояние Talk (2026-03-05) — ТРЕБУЕТ ДОРАБОТКИ - Janus PID 9576: half-trickle, nat_1_1_mapping=85.235.181.190, /tmp/janus.jcfg - Signaling PID 12313: свежий, подключён к Janus на ws://127.0.0.1:8188 - Supervisord (PID 7) управляет eturnal, nats, signaling; Janus запущен вручную (supervisord сдался после 3 попыток) - iptables на VM 200: DNAT+FORWARD+MASQUERADE для UDP 20000:20100 и 49152:49252 → 172.18.0.4 ### Нерешённые проблемы 1. **DTLS alert/timeout** — subscriber/publisher получают hangup (DTLS alert), вызов переподключается - tcpdump подтвердил: RTP-пакеты доходят до контейнера, но DTLS handshake не завершается - Может быть связано с MTU на сотовой сети или фрагментацией DTLS 2. **"The user is not invited to this room"** — после перезапуска signaling старые токены клиентов невалидны - Решение: обоим участникам нужно перезагрузить страницу (F5) для получения свежего токена - Нужно проверить работает ли после перезагрузки страниц 3. **Supervisord не управляет нашим Janus** — при краше Janus не перезапустится автоматически - Supervisord запускает оригинальный Janus с --full-trickle и без nat_1_1_mapping - Наш Janus запущен через docker exec -d — без автоперезапуска - Нужно: либо модифицировать supervisord.conf (но rootfs read-only), либо обёртка-watchdog ### Что нужно сделать при возврате - [ ] Попросить пользователя перезагрузить страницы обоих клиентов и протестировать звонок - [ ] Если DTLS всё ещё падает — попробовать `dtls_mtu = 1200` в janus.jcfg - [ ] Решить проблему автоперезапуска Janus (watchdog или модификация /supervisord.conf в /tmp) - [ ] Проверить звонки LAN↔LAN, LAN↔сотовая, сотовая↔сотовая - [ ] Обновить /opt/talk-janus-patch.sh если нужно после тестов ## Исправление: Netbird VPN ломал внешний доступ к Talk - **Проблема**: Netbird VPN (wt0) перехватывал весь внешний трафик через таблицу маршрутизации `netbird` - Пакеты SYN приходили через ens18 (MikroTik), но SYN-ACK уходили через wt0 (Netbird) — асимметричный роутинг - **Диагностика**: tcpdump на bridge показал что контейнер отвечает SYN-ACK, но они не доходят до ens18 - `ip route get 194.26.100.165` → показывал `dev wt0 table netbird` вместо `dev ens18` - **Решение**: `ip rule add from 172.18.0.0/16 lookup main priority 104` - Постоянный скрипт: `/etc/networkd-dispatcher/routable.d/50-docker-routing.sh` - После исправления порт 3479 открыт из Канады, Индии, Нидерландов, Турции ## MikroTik NAT правила (192.168.1.1) — ДЕЙСТВУЮЩИЕ - Talk-TURN-TCP: dstnat 85.235.181.190:3479 → 192.168.1.200:3479 - Talk-TURN-UDP: dstnat 85.235.181.190:3479 → 192.168.1.200:3479 - Janus-RTP-UDP: dstnat 85.235.181.190:20000-20100 → 192.168.1.200 - TURN-relay-UDP: dstnat 85.235.181.190:49152-49252 → 192.168.1.200 - Hairpin Talk TURN TCP/UDP: srcnat masquerade 192.168.1.0/24 → 192.168.1.200:3479 - Matrix TURN TCP/UDP: dstnat 3478 → 192.168.1.133:3478 - Matrix Federation: dstnat 8448 → 192.168.1.133:8448 - Hairpin TURN dstnat/srcnat TCP/UDP: для 192.168.1.0/24 → 85.235.181.190:3478 → 192.168.1.133 ## VM 200 UFW — открытые порты - 22/tcp, 3479/tcp+udp, 49152:49252/udp, 20000:20100/udp — from Anywhere - 11000 — from 192.168.1.22 (NPM) - 80, 8080, 8443, 8000, 9443, 3389, 3390 — LAN only - Tailscale/Netbird (wt0) — all traffic ## Element X / Element Call (2026-03-05) - well-known `/.well-known/matrix/client` обновлён через NPM advanced_config (proxy host #18) - Добавлено: `"org.matrix.msc4143.rtc_foci": []` — mesh mode (P2P без SFU) - Для групповых звонков нужен LiveKit SFU (не развёрнут) - homeserver.yaml НЕ изменён (SSH к VM 107 заблокирован fail2ban) - Также: `msc4108_enabled: false` — QR-вход отключен (требует MAS) ## SSH доступ к VM 107 (2026-03-05) — ПРОБЛЕМА - fail2ban забанил IP 10.0.0.237 (jump host) и 192.168.1.200 (VM 200) - Порт 22 открыт (SSH banner отдаётся), но пароль отклоняется - QEMU guest agent не установлен — Proxmox API exec не работает - sshpass не установлен на Proxmox хосте (192.168.1.201) - **Решение**: нужно разбанить IP через Proxmox console (noVNC/SPICE) или ждать expiry ## Данные MAS (для возможного повторного развёртывания) - DB: mas/MASniikn2026 - Matrix secret: 60pMasWfQd8XUyxix932yIxsweyCG89x - Полный конфиг: /root/mas-config.yaml - syn2mas: 97 пользователей, 2 с паролями, 2 с OAuth