# ru1 — `85.198.109.86` (RU entry node)

VPN entry-нода в РФ. Точка входа в топологии **RU↔DE**: умный роутинг (RU-трафик → напрямую, зарубежный → туннель AWG до de1). Полный runbook — `~/README.md` на сервере.
Секреты (WEB-proxy secret в `/etc/tproxy-server/profiles.json` и `/etc/mtproxy/mtproxy.env`, `token.key`, ключи WG) — только на сервере, не здесь.

**Провайдер:** VDSina · РФ
**ОС:** Ubuntu 24.04.3 LTS · kernel 6.8.0-78
**Ресурсы:** 1 vCPU / 1.9 GB RAM / 50 GB (swap 2 GB) — маленькая нода
**hostname:** `v2911854.hosted-by-vdsina.ru`

## Доступ
- `ssh mik@85.198.109.86` (пользователь `mik`, вход по ключу), **passwordless sudo**.
- Ключи в `~mik/.ssh/authorized_keys` (по комментарию, сверено 2026-09-23): `mikpokrovskij@gmail.com`, `iluha_proxy`, `iluha_rabobot@ruzzy.dev`, `openclaw@ruzzy`, `claude-bot@ruzzy.dev` (добавлен 2026-09-23, SHA256:mNK/9jiwypqVHj8oOnKUcr1mqt39z4cVrWWsxxbKP+o; бэкап прежнего файла — `authorized_keys.bak-20260923`).
  ⚠️ У `mik` passwordless sudo, поэтому любой из этих ключей даёт root. Отдельного пользователя под ботов нет.

## Интерфейсы
- `ens3` — публичный `85.198.109.86/24` (RU интернет, default route via 85.198.109.1)
- `tun0` — OpenVPN #1 (умный роутинг) `192.168.255.1/24`
- `tun1` — OpenVPN #2 (RU-выход) `192.168.254.1/24`
- `wg0` — AmneziaWG туннель `10.8.1.4/32` → **с 2026-06-21 endpoint переключён на `fr1` (161.97.93.252:36360)** (был de1). Ключи/PSK те же, менялся только Endpoint в `/etc/amnezia/amneziawg/wg0.conf`. Откат: вернуть IP на `213.136.74.247`.
- `wg1` — WireGuard для клиентов `10.8.2.1/24`

## Сервисы и порты
| Сервис | Порт | Описание |
|---|---|---|
| OpenVPN #1 | 1194/udp (`tun0`) | умный роутинг: RU→ens3, зарубеж→wg0→de1. Cfg `/etc/openvpn/server/openvpn.conf` |
| OpenVPN #2 | 1195/udp (`tun1`) | RU-выход (весь трафик через ens3, DNS Yandex). Cfg `/etc/openvpn/server/ruopenvpn.conf` |
| AmneziaWG `wg0` | (awg, `45451/udp`) | туннель до de1 (exit). `awg-quick@wg0`, cfg `/etc/amnezia/amneziawg/wg0.conf`, `Table=off` |
| WireGuard `wg1` | 51820/udp | VPN для клиентов (Docker `linuxserver/wireguard`), подсеть `10.8.2.0/24`, `~/wireguard/` |
| WEB-прокси Telegram | 443 (через nginx) | `tproxy-server` (relay, systemd, `127.0.0.1:8090`, admin `:8091`) → официальный MTProxy (systemd, `2398`, stats `8888`, оба закрыты nftables для не-lo). Подробно — раздел ниже |
| nginx | 80, 443 | фронт `ru.ruzzy.dev`: весь 443 → relay. Docker `nginx:alpine`, `~/gost/` |
| certbot | — | `certbot renew` раз в 12 ч, webroot `~/gost/certbot/www` |

Контейнеры: `nginx`, `certbot` (`~/gost`), `wireguard` (`~/wireguard`), агент мониторинга (`~/monitoring-agent`). Compose, nginx.conf и скрипт установки — копия в репо `stacks/tproxy/`.

## WEB-прокси Telegram (с 2026-10-09)
Новый тип прокси в клиентах Telegram (Desktop ≥ 7.1.0; мобильные — по сообщениям с 13.0, официально не подтверждено). Клиент держит скрытый WebView к `https://ru.ruzzy.dev/` и гонит по HTTPS/WSS мультиплексированные MTProxy-потоки. Сервер — официальный [`telegramdesktop/tproxy-server`](https://github.com/telegramdesktop/tproxy-server), коммит `c8adb8b` (2026-09-29).
- **Клиенту:** server `ru.ruzzy.dev`, secret — 32 hex из `profiles.json`. Ссылка: `https://t.me/webproxy?server=ru.ruzzy.dev&secret=<secret>`; получить на сервере — последней строкой вывода `setup-ru1.sh`.
- **Цепочка:** клиент → nginx `:443` (TLS, `ru.ruzzy.dev`) → relay `127.0.0.1:8090` → MTProxy `127.0.0.1:2398` → middle-end Telegram через `wg0` → fr1.
- **Mode A, без base path:** relay — единственный шлюз хоста и сам отдаёт публичный сайт из `/srv/tproxy-site` (копия маскировочного `~/gost/nginx/html/index.html`; перечитывается только при рестарте relay). Запросы без валидной capability (`?bridge=` = HMAC от секрета и имени хоста) получают обычный сайт. Base path не включали: по документации его понимает только Desktop.
- ⚠️ **NAT для MTProxy задан вручную:** `MTPROXY_NAT_ARGS=--nat-info 10.8.1.4:161.97.93.252` в `/etc/mtproxy/mtproxy.env`. Официальный MTProxy выводит AES-ключи middle-end сессии из своего адреса; трафик к Telegram с ru1 уходит в wg0 и выходит с IP **fr1**. Автоопределение апстримного `install.sh` спросило бы ifconfig-сервис через ens3, получило 85.198.109.86 — и MTProxy принимал бы клиентов, никому не отвечая, без ошибок нигде. Сменится exit-IP fr1 или адрес wg0 — править здесь. Симптом: `journalctl -u mtproxy | grep 'Disconnected from RPC Middle-End'`.
- **Юниты:** `tproxy-firewall` (nft-таблица `inet tproxy_backend`: 2398/8888 только с lo), `mtproxy`, `tproxy-server`, `refresh-mtproxy-config.timer` (ежедневно тянет `proxy-multi.conf`, рестарт MTProxy только при изменении). Бинарник relay `/usr/local/bin/tproxy-server` собран локально (`CGO_ENABLED=0 GOOS=linux GOARCH=amd64`), MTProxy — `/opt/MTProxy`, собран `deploy/install-mtproxy.sh` (закреплённый коммит + sha256).
- **Carrier: `websocket`** (с 2026-10-09, было `https` по умолчанию) — поле `carrier_mode` профиля в `profiles.json`: один WSS-канал `/api/v1/ws` на все потоки клиента вместо POST + long poll. Клиенту менять нечего, режим выбирает сервер. Relay пингует WSS раз в 25 с простоя (`long_poll`), поэтому `proxy_read_timeout 90s` в nginx канал не рвёт. Смена режима — `systemctl restart tproxy-server`, живые сессии переподключаются. `websocket-lanes` не взят: отдельный WSS на поток, на macOS WebKit сериализует рукопожатия и подключение может не уложиться в таймаут клиента. Бэкап профиля до правки — `profiles.json.bak-20261009`.
- ⚠️ Порты relay **8090/8091**, а не дефолтные 8080/8081: `*:8080` занят cadvisor из `~/monitoring-agent`.
- ⚠️ **Логи nginx выключены** (`access_log off`): в URI bridge-страницы — capability, в `Sec-WebSocket-Protocol` — токен сессии. Не включать.
- **Проверено 2026-10-09:** `readyz` 200; 10 ME-соединений с `10.8.1.4`, `Disconnected` — 0; obfuscated2 + `req_pq_multi` на `127.0.0.1:2398` → `resPQ` за ~60 мс (3/3); capability через публичный фронт → bridge-страница (200, свой CSP). **Живой клиент не проверялся.**
- **Диагностика:** `curl -s 127.0.0.1:8091/readyz`, `curl -s 127.0.0.1:8091/metrics | grep tproxy_sessions`, `journalctl -u tproxy-server -u mtproxy`.
- **Маршрут:** весь Telegram (`91.108.4/22`, `91.108.8/22`, `91.108.56/22`, `95.161.64/20`, `149.154.160/20`) — в main-таблице `dev wg0`. Упал wg0 — прокси не работает.
- **Сертификат** `ru.ruzzy.dev` (LE, webroot, только это имя; перевыпущен 2026-10-09, до 2027-01-07). Продление: `certbot` в контейнере каждые 12 ч; nginx сам делает `reload` раз в 6 ч (цикл в `command` compose).
  ⚠️ До 2026-10-09 контейнера certbot **не было вовсе**, хотя он был описан в compose: сертификат истёк 2026-07-01 и три месяца отдавался просроченным.
- ⚠️ `nginx.conf` смонтирован в контейнер **одним файлом**: замена через `mv`/редактор с новым inode контейнер не видит, `nginx -s reload` перечитает старый. После такой замены — `docker compose restart nginx` (2026-10-09 так получили минуту простоя 443).
- Открытый прокси для всех, кто знает secret; лимиты — дефолтные апстрима (128 сессий, 4096 потоков).

### История 2026-10-09
1. Под «web-proxy для Telegram» сначала понят Telegram Web в браузере: nginx-прокси на `web.telegram.org` с переписыванием адресов DC (`zws*.ru.ruzzy.dev`) — **убран** в тот же день, не то.
2. telemt (MTProxy, FakeTLS под `ru.ruzzy.dev`, был на 443, API `9091` торчал наружу) снят, возвращён, затем **удалён окончательно** по решению владельца: контейнер, образ, `~/gost/telemt-config` (со старым секретом), `telemt-data`, том `gost_mtproxy-config`.
3. Поднят WEB-прокси (выше). Бэкапы compose/nginx.conf до изменений — `~/gost/*.bak-20261009*`.

## Умный роутинг (tun0 и wg1)
- `ipset ru_ips` (~11400 подсетей, источник ipdeny.com). До routing decision (mangle PREROUTING):
  - dst ∈ ru_ips → RETURN (без метки) → main table → ens3 (RU напрямую)
  - иначе → MARK `0x64` → `ip rule fwmark 0x64 → table vpn (100)` → default dev wg0 → de1
- ⚠️ **Правило `fwmark 0x64 → vpn` ставит `PostUp` в `wg0.conf`, и его снимает рестарт `systemd-networkd`.** По умолчанию networkd при старте удаляет «чужие» ip rule (`ManageForeignRoutingPolicyRules=yes`). 2026-10-09 в 16:36 `apt-get install` из установки WEB-прокси обновил библиотеки → needrestart перезапустил networkd → правило пропало, и ~45 мин (до 17:21) зарубежный трафик клиентов OpenVPN #1 шёл через ens3 (RU IP) вместо туннеля; жаловались пользователи VPN. Вернули вручную (`ip rule add fwmark 100 lookup vpn priority 10000`). Защита с 2026-10-09: `/etc/systemd/networkd.conf.d/10-keep-foreign-routing.conf` — `ManageForeignRoutingPolicyRules=no`, `ManageForeignRoutes=no` (действует со следующего старта networkd; networkd ради этого не перезапускали). Та же мина раньше висела на unattended-upgrades. Быстрая проверка: `ip rule | grep 0x64`.
- Обновление списка: `~/smart-routing/update-ru-ips.sh`, cron вс 03:00. Восстановление при ребуте: `ipset-restore.service` (до `awg-quick@wg0`).
- tun1 — без умного роутинга (всегда RU/ens3).

## AWG Watchdog
- `~/awg-watchdog.sh` в root-cron **каждые 3 мин**: если handshake `wg0` старше 5 мин → рестарт `awg-quick@wg0` + чистка дублей iptables. Лог `~/awg-watchdog.log`. (WEB-прокси зависит от wg0: адреса Telegram с хоста идут через туннель.)

## Клиенты
- OpenVPN: `~/gen_client.sh --profile de|ru|both <имя>`, PKI `~/easy-rsa/pki`, профили `~/clients/`. CRL отключён.
- WireGuard: `~/wireguard/gen_client.sh <имя>` → `~/wireguard/clients/<имя>.conf` (горячее добавление).

## Мониторинг
- Агент `~/monitoring-agent` (node-exporter + cadvisor, **host-network** → видит ens3/wg0/wg1/tun0/tun1) → Prometheus `fr1`, instance `ru1`.
- **openvpn-exporter** (kumina, host-net :9176) — per-client метрики обоих OpenVPN (status-файлы `/run/openvpn-server/status-openvpn.log` + `/var/log/openvpn-ru-status.log`). Дашборд Grafana «OpenVPN — клиенты».
- Порты 9100/8080/9176 закрыты `iptables INPUT DROP ! -s 161.97.93.252` (только fr1, сохранено netfilter-persistent). Скрейп по публичному IP.

## Прочее в `~`
- `badvpn`, `gost`, `smart-routing`, `tun2socks.log`, `net-backup`, `works`, `telemt-build`, `cloudflared.deb`.

## Живой статус (2026-06-21)
Все юниты active (`awg-quick@wg0`, оба `openvpn-server@`, `ipset-restore`), 3 контейнера up, `wg0` handshake свежий, ipset ru_ips = 11394.

## ⚠️ Грабли (из README)
- `wg1.conf` обязан иметь `Table = off` — иначе wg-quick при рестарте сносит default route и сервер теряет SSH (восстановление: `ip route add default via 85.198.109.1 dev ens3`).
- Таблица маршрутизации — `vpn` (100), не `awg`.

## Бэкап (с 2026-10-11)
- Домашняя `rpi` каждую ночь забирает зашифрованную (age, открытый ключ) выгрузку — `stacks/server-backup/`. Ключ `server-backup@rpi` в `~mik/.ssh/authorized_keys` с `restrict,command="sudo -n /usr/local/sbin/backup-export"` (бэкап — `authorized_keys.bak-20261011`).
- `/usr/local/sbin/backup-export` (root 750) пакует `/etc`, `/opt`, `/srv`, `/usr/local`, `~mik` (без сборок badvpn/telemt-build, логов, `.claude`), `/root`, crontab; `/usr/local/bin/age` — статический v1.3.2. Архив ~17 МБ.
- Главное в нём — **`~mik/easy-rsa` (CA OpenVPN)**: без него пришлось бы перевыпускать все 43 клиентских конфига.

## Открытые хвосты
- **Умный роутинг для `wg1` не настроен** (2026-10-09): mangle-правила есть только для `-i tun0`, для `wg1` / `10.8.2.0/24` — ни одного, хотя раздел «Умный роутинг» заявляет tun0 и wg1. В `wg1` один пир, рукопожатий не было ни разу — сервисом, похоже, никто не пользуется. Не правили.
- Drop-in `10-keep-foreign-routing.conf` фактически не проверен рестартом networkd (рестарт ens3 по SSH на этой ноде — риск). Проверить при следующей плановой перезагрузке: после неё `ip rule | grep 0x64` должен показать правило.
- **Живой клиент через WEB-прокси не проверен** (2026-10-09): серверная цепочка проверена по частям (см. раздел WEB-прокси). Поддержка в мобильных клиентах подтверждена только новостью про Telegram 13.0.
- **DNS `*.ru.ruzzy.dev`** (CNAME → `ru.ruzzy.dev`, Namecheap) остался от веб-прокси Telegram Web — больше не нужен, удалить. Имена `zws*.ru.ruzzy.dev` уже попали в CT-логи через сертификат от 2026-10-09 (Let's Encrypt) — это не отменить.
- `/tmp/tproxy-server` на сервере — исходники и `setup-ru1.sh`, нужны для `deploy/update-relay.sh`; `/tmp` чистится при ребуте — при обновлении заливать заново.
- `~/gost/manage.sh` — от прежнего gost/SOCKS5, не используется.
- Замечено при снапшоте 2026-10-09, не разбиралось: `iperf3 --server` (порт 5201 наружу, пользователь `iperf3`, PPID 1), cadvisor `unhealthy`. Остальное описание (OpenVPN, AWG, клиенты) сверялось до переключения на fr1 — см. строку в `AGENTS.md`.