---
date: 2026-04-21
type: decision
tags: [decision, network, wireguard, znamenskoye, ohothozyistvo, backup-channel]
---

# 2026-04-21: Восстановление резервного WG-канала для охотхозяйства

## Контекст

Объект «Знаменское Охотхозяйство» работает на LTE через MikroTik hAP ax lite LTE6 (CGNAT), единственный канал управления — Netbird через Orange Pi R1+ LTS (OpenWrt 21.02). Нужен резервный канал на случай деградации Netbird. Ранее пробовали WG на MikroTik — ломал интернет (default route hijacking через distance=2). Физического доступа к объекту нет.

Существующий WG на Orange Pi (wg0 → VPS 89.111.140.86) числился в документации как «сломан из-за port mismatch», но на самом деле не работал по **двум** причинам:

1. Orange Pi `wg0` endpoint port: `51820` — VPS слушает `51821`.
2. VPS `/etc/wireguard/wg0.conf` пира `10.5.0.3` имел pubkey `zZ4UoWNwTxBODr8xZmoCREBL2zXJcmdcxKIPGp/xBC8=` (вероятно, старый ключ MikroTik-овского `wg-vps`), а Orange Pi шлёт от ключа `QK2SMILEfG+kRccU3QJVDZafuf108z6qPDK1XusLGVI=`.

## Варианты

1. Починить существующий WG на Orange Pi (минимум правок, WG не трогает default route на OpenWrt).
2. Поднять AmneziaWG на Orange Pi по схеме НИИКН (требует OpenWrt 22.03+, Orange Pi на 21.02 — обновление sysupgrade без физдоступа = риск окирпичивания).
3. Включить WG на MikroTik заново — известная проблема с default route, отпадает.

## Решение

**Вариант 1.** Починить WG на Orange Pi, оставить MikroTik `wg-vps` disabled.

Изменения:
- На Orange Pi: `uci set network.wg0_peer.endpoint_port='51821'` → `ifdown wg0 && ifup wg0`.
- На VPS: `sed` в `/etc/wireguard/wg0.conf` (бэкап `.bak-20260421-1512`) — PublicKey пира `10.5.0.3` заменён на `QK2SMILE...`. Перечитано атомарно `wg syncconf wg0 <(wg-quick strip wg0)` — **другие пиры не затронуты** (10.5.0.4 Home 4.37 TiB трафика, 10.5.0.2 З-29).

Проверено:
- VPS ↔ Orange Pi (10.5.0.3): 0% loss, RTT ~40-107 мс
- VPS ↔ MikroTik (192.168.8.1): 0% loss, RTT ~40 мс
- VPS ↔ NVR (192.168.8.247): 0% loss
- DNAT публичных портов: `http://89.111.140.86:8180/` (NVR Web) → HTTP 200 за 0.22s
- Интернет на объекте не пострадал

## Последствия

### Что обновлено
- [Документация охотхозяйства](../claude-memory/znamenskoye-ohothozyistvo.md) — актуализированы разделы 2, 3, 5, 6.
- Netbird IP Orange Pi изменился: `100.70.63.67` → `100.70.106.227` (Connected P2P, не Relayed как писали ранее).

### Новый ключ доступа к VPS
SSH-ключ ранее был «на clawdbot LXC 129», но clawdbot больше нет (только LXC 137 openclaw). Заведён новый ключ:
- Локальный файл: `~/.ssh/vps_znam_key` (RSA-2048, сгенерирован панелью sweb.ru)
- Имя ключа в sweb.ru: `claude`
- **TODO (Олег):** сохранить приватный ключ в Bitwarden `bit.dttb.ru` как `VPS znam (89.111.140.86)` — чтобы не потерять снова.

### Резервные каналы объекта (после фикса)
| # | Канал | Путь |
|---|-------|------|
| 1 (основной) | Netbird mesh | Mac → 100.70.106.227 → 192.168.8.0/24 |
| 2 (резерв) | WG через VPS | Интернет → VPS → WG 10.5.0.1↔10.5.0.3 → 192.168.8.0/24 |

DNAT камер/NVR через VPS 89.111.140.86:8xxx теперь реально работает (до фикса транспорт был мёртв).

### Отложено (опционально)
- Второй WG-peer на VPS `:443/udp` — защита от DPI LTE-оператора, если начнёт блокировать `:51821`.
- `autossh` reverse tunnel с Orange Pi на VPS — третий канал на случай падения и Netbird, и WG.
- Обновление Orange Pi до OpenWrt 24.10 + AWG по схеме НИИКН — отложено из-за отсутствия физдоступа.

### Почему документация была неверной
В старом `znamenskoye-ohothozyistvo.md` описан только port mismatch (51820 vs 51821) — но смена порта одна handshake не восстанавливает, т.к. pubkey пира на VPS тоже не соответствовал Orange Pi. Вероятный источник путаницы — пир на VPS создавался когда WG пытались поднять на MikroTik (свой keypair), потом переключили на Orange Pi (другой keypair) и на VPS ключ не обновили.

## Теги
`#znamenskoye` `#ohothozyistvo` `#wireguard` `#openwrt` `#backup-channel` `#vps` `#fix`