`wg syncconf "$IF" <(wg-quick strip "$IF")` падал тихо в окружении, где
process substitution не сработал, и файл /etc/wireguard/wg0.conf
обновлялся, а ядерное состояние wg-интерфейса оставалось старым.
В итоге peer добавлен в .conf, но `wg show` его не видит и трафика нет.
Теперь после регенерации конфига делаем `systemctl restart wg-quick@$IF`.
Это пересоздаёт интерфейс целиком — дороже, чем syncconf, но гарантирует
применение. Если systemd-юнит не enabled, остаётся fallback на syncconf
через временный файл (без process substitution).
После handshake траффик упирался в UFW на сервере (открывали только
51820/udp, не сам интерфейс wg0). Добавляем `ufw allow in/out on wg0`
в server-install.sh — теперь ICMP/HTTP/SSH внутри туннеля проходят.
На клиенте AllowedIPs по умолчанию = 10.99.0.1/32 (только сам VPS),
а не /24. Это устраняет возможный конфликт с существующими маршрутами
для 10.99.0.0/24, если у Keenetic другие WG-интерфейсы используют ту
же подсеть. Hub-and-spoke (роутер→VPS) — типичный сценарий, /32
достаточно. Кому нужен peer-to-peer через хаб — WG_SUBNET=10.99.0.0/24.
`wg setconf` принимает только базовый формат (PrivateKey/ListenPort + [Peer]),
без wg-quick-полей (Address/DNS/Table/...). Раньше клиентский wg0.conf
содержал `Address = ...`, на котором setconf падал и не дочитывал [Peer].
Интерфейс поднимался, но без peer-а — handshake не отправлялся, сервер
не знал endpoint, пинги через туннель не шли.
Исправление:
- Убираем Address из тела conf, ставим как ip addr add (это уже было).
- В init.up добавили проверку: если после wg setconf нет блока `peer:`
в `wg show`, печатаем ВНИМАНИЕ — чтобы такая поломка не оставалась
тихой.
Многострочная команда с backslash-переносами падала в BusyBox ash, если
её вставляли построчно: первая строка превращалась в команду, остальные
терялись. Меняем формат на 4 строки `export VAR=...` + 1 строка `curl ...`.
В таком виде вставка работает и блоком, и по одной строке, в любом shell.
Решает доступ к роутеру с серым IP через белый VPS — поднимаем WG-туннель
(UDP 51820, подсеть 10.99.0.0/24), и любой сервис на VPS обращается к
роутеру по 10.99.0.X. SSH, HTTP, что угодно — без проброса портов и
без изменений в keenetic_ssh-web/keenetic-unified/Domain Hydra/etc.
Что добавлено:
- tunnel/server-install.sh — установка WG-сервера на Ubuntu VPS,
генерация ключей, запуск wg-quick@wg0, открытие 51820/udp в ufw.
- tunnel/kssh-tun — утилита управления peer-ами на VPS:
add/list/show/remove. add генерит ключи и IP, печатает ENV-блок
с одной командой для роутера.
- tunnel/tunnel-install.sh — клиент для роутера (Entware), принимает
4 ENV (VPS_ENDPOINT/VPS_PUBKEY/CLIENT_IP/CLIENT_PRIVKEY), ставит
wireguard-tools, поднимает wg0 и init-скрипт автозапуска.
- tunnel/README.md — пошаговая инструкция массовой установки.
- README.md: краткая ссылка из основного раздела.
Параметры подсети/порта/имени репо — через ENV для масштабной установки.
- urllib теперь идёт на HTTPS с unverified context (Keenetic админка
обычно с самоподписанным сертификатом)
- .env по умолчанию содержит и HTTP, и HTTPS, и :81 для LAN-IP, плюс
my.keenetic.net и loopback — пробуется всё подряд
На Keenetic админка часто не слушает loopback — биндится только на
LAN-интерфейсах. Делаем ROUTER_HOST списком (через запятую), пробуем
все по порядку.
- auth.py: keenetic_validate_any() — обходит список, на каждом шаге
пишет в лог конкретную причину отказа: unreachable / нет realm /
POST HTTP <code> / неверный логин-пароль
- app.py: парсит ROUTER_HOST как список (csv); login fail логируется
- install.sh: при создании свежего .env подставляет в ROUTER_HOST
обнаруженный LAN-IP, my.keenetic.net и loopback (через запятую)
- .env.example: тот же дефолт, комментарии обновлены
- В Entware на Keenetic обычно нет /opt/bin/nohup; init-скрипт пробует
setsid → nohup → сабшелл с trap '' HUP. Демон больше не падает на
старте с «nohup: not found».
- После запуска ждём 1 сек и проверяем kill -0 — если упал, пишем
внятную ошибку и подсказку посмотреть лог, а не молчаливое «started».
- Финальная подсказка ищет именно LAN-IP роутера (192.168/10/172.x с
октетом .1), а не первый попавшийся 192.168.x.x с другого интерфейса.
- В конце install.sh демон запускается автоматически (NO_START=1 чтобы выключить)
- Если в /opt/etc есть rc.d, ставим симлинк автозапуска при ребуте
- Подсказка в браузер сразу с реальным IP LAN
- pip install --target=lib теперь с --upgrade — без WARNING при повторной установке
- bootstrap.sh не упоминает nano (его нет в Entware), и не дублирует подсказку
На многих сборках Entware (включая aarch64-k3.10) пакет python3-venv
недоступен и `python3 -m venv` падает с `No module named venv`.
Делаем установку без venv:
- если venv создаётся — используем его (как раньше)
- иначе ставим зависимости в $INST/lib через `pip install --target=lib`
- run.sh и init-скрипт автоопределяют режим (PYTHONPATH=lib для второго)
Также: opkg install python3-venv стал опциональным (как и был, но без
обязательного завершения цепочки).
- opkg update больше не валит install.sh при 404 у hoaxisr/ground-zero
- opkg install python3 — фолбэк цепочкой, без выхода по set -e
- Финальный блок «Готово» с явным путём INST/INIT, чтобы оборвавшаяся
установка сразу была заметна
- README/install: vi вместо nano (на Entware nano по умолчанию нет),
заметка про частичные ошибки opkg update
