--- title: Rusonyx VPS onboarding quirks (Astra Облако / myvm.rusonyx.ru) type: concept tags: [rusonyx, vds, bootstrap, onboarding, gotchas, vendor] sources: [../sources/vds-kzntsv-bootstrap-2026-05-20.md] updated: 2026-05-20 --- # Rusonyx VPS onboarding quirks Quirks first-boot опыта на Rusonyx VDS (Astra Облако, https://myvm.rusonyx.ru) — для memory будущих сессий. Зафиксировано при активации [`vds-kzntsv`](../entities/vds-kzntsv.md) 2026-05-20. ## 1. VNC console не открывается с первого раза В Управление сервером → Консоль HTML5 noVNC может не загружаться (зависание на индикаторе соединения). Помогает кнопка **«Остановить VNC»** в той же панели — force-disconnect stale attachment'а на hypervisor side. После клика подождать ~5 сек, открыть консоль заново. Если не помогает — ticket в support, без VNC реальной возможности зайти в box нет (см. quirk 2). ## 2. Stale системный образ Ubuntu — обязательный upgrade через VNC Поставка содержит сотни pending updates, включая `openssh-server` и kernel. Письмо при активации **прямо рекомендует** последовательность: ```bash apt update apt upgrade apt --fix-broken install apt upgrade ``` И ключевая часть: **«строго через VNC-консоль»**, потому что `openssh-server` upgrade'у переключают сервис, что разрывает SSH session и бьёт upgrade на половине. По дороге будет **5+ dpkg interactive prompts** (conffile conflicts). Ответы: | Prompt | Правильный ответ | Reasoning | |---|---|---| | `/etc/ssh/sshd_config` | **2** (keep local) | Rusonyx-modified sshd_config форсит `PermitRootLogin yes` + `PasswordAuthentication yes` для первого захода. Maintainer-версия дефолтит `prohibit-password` — потеряешь SSH-доступ если ключ ещё не залит. | | `/etc/cloud/cloud.cfg` | **N** (keep current) | Rusonyx модифицировал под свой provisioning (network, ssh-key inject). Maintainer-версия может сломать их хуки. | | `grub-pc /dev/vdaX target` | **1** (`/dev/vda` whole-disk MBR) | Опция 2 (на partition) — blocklist mechanism, less reliable. Опция 3 (skip) = box не загрузится. | | `cloud-init local config` (если появится) | keep | По той же логике. | После завершения — `reboot` (или ждать пока apt сам запустит). ## 3. SSH initial password — одноразовый Активационное письмо даёт `root` + одноразовый пароль. Первый шаг bootstrap'а (после VNC-upgrade) — push своего SSH key и harden sshd: ``` PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes ``` Через **drop-in file `/etc/ssh/sshd_config.d/00-hardening.conf`** (префикс `00-` чтобы выиграть first-match precedence над `50-cloud-init.conf` который форсит `PasswordAuthentication yes`). ## 4. Подключение через SSH с password на Windows OpenSSH for Windows **не имеет** `-pw` flag (как `plink`/PuTTY) или `sshpass`. Для одноразового password-bootstrap: - **plink.exe** (`C:\Program Files\PuTTY\plink.exe`) — supports `-pw`, доступен если PuTTY установлен. - Pipe `echo y | plink ...` для auto-accept first-time host key (plink кэширует в registry). - После push pubkey → переключаемся на native OpenSSH `ssh -i` (plink больше не нужен). ## 5. Hypervisor-side VNC ≠ guest-side VNC service В гостевой системе **нет** VNC service'а — VNC console работает на qemu/KVM hypervisor side. Поэтому request «зайди и передёрни vnc service из гостя» невозможен. Управляется только через Rusonyx web panel. ## 6. Default firewall — open? Из наблюдений 2026-05-20: после reboot SSH:22 поднимался автоматом, не было видно guest-side ufw default-deny. Но **ICMP ping проходил до VNC-fix**, при том что **все TCP-порты были filtered**. Похоже, Rusonyx имеет perimeter firewall, который автоматически allow'ит TCP только когда VPS становится «active» в их учёте — корреляция с моментом первой VNC-сессии. Не воспроизводимо post-factum; для будущих VDS — стоит сначала открыть VNC, потом ждать что SSH станет доступен. ## 7. Tariff именования «160 SSD» переименован в «160 NVMe» (та же цена, апгрейд по IOPS). Если в старой переписке/доках видите «160 SSD» — это actually 160 NVMe. Аналогично могут быть переименования для 80/220+ тарифов. ## 8. Welcome-email рекомендации Содержит только команды apt upgrade, **не упоминает**: - Что VNC может быть stale. - Какие dpkg prompts и правильные ответы. - Initial password — одноразовый, нужно сменить на ключ. См. также: support-ticket draft в [`vds-kzntsv-bootstrap-2026-05-20`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) с конкретными suggestions для Rusonyx. ## 9. Сеть = /18, не /24. Gw в той же subnet Rusonyx прописывает VM в **/18** (`netmask 255.255.192.0`), не в /24. Адреса `89.253.192.0 – 89.253.255.255` — это один большой L2 broadcast domain, gateway `89.253.192.1` сидит **внутри** него. Каноническая ifupdown-конфигурация (то что прописывает их `start/ipadd` procedure): ``` auto eth0 allow-hotplug eth0 iface eth0 inet static address 89.253.255.94 netmask 255.255.192.0 post-up ip ro add 169.254.0.0/16 dev eth0 metric 400 post-up ip ro add 89.253.192.1 dev eth0 metric 400 post-up ip ro add default via 89.253.192.1 dev eth0 metric 400 post-up ip ro add 89.253.192.0/18 via 89.253.192.1 dev eth0 src 89.253.255.94 metric 400 post-up ip ro del 89.253.192.0/18 dev eth0 proto kernel scope link src 89.253.255.94 ``` Тонкость: их post-up сначала добавляет 89.253.192.0/18 **через gw** (routed), потом удаляет автоматически добавленный kernel-route (directly attached). То есть весь трафик внутри /18 идёт **через gw**, не L2-broadcast — типичный hosting-pattern для изоляции клиентов друг от друга (`proxy-ARP` / routed-on-host). Эфемерная статика для recovery (если конфиг утерян): ```bash sudo ip addr add 89.253.255.94/18 dev eth0 # /18 — gw сам в подсети, link-route не нужен sudo ip route add default via 89.253.192.1 dev eth0 ``` Если по какой-то причине /18 не приемлем — fallback с /24 и link-route к gw: ```bash sudo ip addr add 89.253.255.94/24 dev eth0 sudo ip route add 89.253.192.1 dev eth0 # link-scope route к gw sudo ip route add default via 89.253.192.1 ``` DNS resolvers: `89.253.252.30`, `89.253.252.31`. Как обнаружить gw/netmask для конкретной VM: 1. **Соседний VPS у того же хостера** — `ip route` + `ip addr` покажут. 2. **`/etc/network/interfaces.d/ifcfg-`** на самой VM (если конфиг present) — provider's canonical setup. 3. Cached DHCP lease (если уцелел): `cat /run/systemd/netif/leases/*` → поле `ROUTER=`. 4. Активационное письмо при выдаче VPS. 5. Support ticket — последний resort. Подробный кейс где это пригодилось — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md). ## 10. Network stack: ifupdown (NOT netplan) Rusonyx provisioning ожидает **`ifupdown` + `networking` service**, не netplan/systemd-networkd. Их `start/ipadd/ipdel` procedure (вызывается при start VM / IP add-remove / network reset) кладёт `/etc/network/interfaces.d/ifcfg-` и ребутает networking. Header в их `/etc/network/interfaces`: ``` # Autoconfigured by Provider's start/ipadd/ipdel procedure. # !!! DO NOT MANUALLY EDIT OR DELETE THIS FILE !!! ``` **Проблема**: Ubuntu 24.04 base ships netplan + systemd-networkd. cloud-init часто оставляет `/etc/netplan/50-cloud-init.yaml` с `dhcp4: true`. После первого boot оба стека активны параллельно. Скорее всего **8 дней работает потому что DHCP сам всё резолвит**. Но если что-то на стороне хостера разорвёт DHCP-binding (rare, но случается — см. инцидент 2026-05-28), **их auto-recovery `start/ipadd` не сможет применить static config**, потому что networkd «держит» eth0. → VM лежит до тикета. **Канон setup после bootstrap для Rusonyx Ubuntu VDS:** ```bash sudo systemctl disable systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service sudo systemctl mask systemd-networkd.service systemd-networkd.socket systemd-networkd-wait-online.service sudo systemctl mask netplan # preventive # leave networking enabled (default) ``` **Безопасно на running system** — `disable`/`mask` без `stop` не убивают текущий процесс. Изменение вступает только при следующем boot. **Anti-pattern:** прописывать persistent статику через `/etc/netplan/*.yaml`. Использовать ifupdown (`/etc/network/interfaces.d/*`), а лучше — попросить хостера через тикет «настройте дефолтную конфигурацию» — они через `start/ipadd` пропишут это сами. Подробный кейс — [`vds-kzntsv-dhcp-outage-2026-05-28`](vds-kzntsv-dhcp-outage-2026-05-28.md). ## Когда применять - Любой новый Rusonyx VDS (Astra Облако). - Возможно частично применимо к другим Russian VDS-providers с custom OS templates (REG.RU, FirstByte, RuVDS), но конкретные dpkg prompt'ы вендор-specific. ## Ссылки - [`vds-kzntsv-bootstrap-2026-05-20`](../sources/vds-kzntsv-bootstrap-2026-05-20.md) — где впервые столкнулись. - [`vds-kzntsv`](../entities/vds-kzntsv.md) — текущий live host.