95 lines
6.2 KiB
Markdown
95 lines
6.2 KiB
Markdown
---
|
||
title: OpenWRT Router (192.168.1.1)
|
||
type: entity
|
||
tags: [hardware, networking, openwrt, nat, dhcp]
|
||
sources: [../sources/nas-recovery-session-2026-05-18.md]
|
||
updated: 2026-08-24
|
||
---
|
||
|
||
# OpenWRT Router
|
||
|
||
Домашний роутер, через который идёт весь публичный трафик к клиентским сайтам.
|
||
|
||
## Hardware / OS
|
||
|
||
- **Hardware:** MediaTek MT7622 (aarch64), 6 disk-bay шасси (с роутером не связано)
|
||
- **OS:** OpenWRT 23.05.4 (r24012-d8dd03c46f)
|
||
- **Uptime:** 13+ дней на момент recovery
|
||
- **LAN-IP:** 192.168.1.1
|
||
- **LAN-subnet:** 192.168.1.0/24
|
||
- **WAN-public:** 94.19.247.14
|
||
|
||
## Access
|
||
|
||
- SSH: `root@192.168.1.1:22` — ssh-key `id_ed25519_openwrt` установлен в `/etc/dropbear/authorized_keys`
|
||
- LuCI web: http://192.168.1.1
|
||
- Конфиг через `uci` (UCI infrastructure)
|
||
|
||
## Текущий port forwarding setup (после recovery patch)
|
||
|
||
Активные:
|
||
- `firewall.@redirect[0]` (SSL): WAN **443** → 192.168.1.143:**4443** (Windows-PC, где traefik)
|
||
- `firewall.@redirect[1]` (HTTP): WAN **80** → 192.168.1.143:**8000** (Windows-PC, где traefik)
|
||
- `firewall.@redirect[9]` (Wireguard): WAN 48820 → 192.168.1.239 (отдельный хост, не трогали)
|
||
|
||
Старые (всё ещё активны, но смотрят на мёртвую синку 192.168.1.10 — на которой ничего нет):
|
||
- DSM 5000 → 192.168.1.10:5000
|
||
- FTP 21, SFTP 22, MariaDB 36063, SQLServer 23056, PassiveFTP 55536-55899, Cloud Station 6690, SSH 1322
|
||
|
||
В рамках recovery эти **не отключали** (по решению пользователя). Можно отключить через `uci set firewall.@redirect[N].enabled='0'` для снижения шума атак.
|
||
|
||
## DHCP-резервации (актуальные)
|
||
|
||
| Хост | IP | MAC | Назначение |
|
||
|---|---|---|---|
|
||
| `windows-recovery-pc` | 192.168.1.143 | 88:66:5A:2F:AA:68 | [[windows-recovery-host]] |
|
||
| `snolla` (исторически) | 192.168.1.15 | 02:11:32:2A:7C:B9 | Раньше — VM мёртвой синки. Сейчас MAC присвоен новой [[snolla-recovery-vm]], но VM в NAT-режиме и LAN-IP не получает. |
|
||
| `diskstation` | 192.168.1.10 | 22:06:7C:32:00:6F (+ ...:70) | Мёртвая синка [[dead-synology-diskstation]] |
|
||
| Прочие | разное | разное | wled-1, hifiberry, и т.д. — не трогаем |
|
||
|
||
## Firewall zones
|
||
|
||
- **lan:** input=ACCEPT, output=ACCEPT, forward=ACCEPT (внутри LAN всё открыто)
|
||
- **wan:** input=REJECT, output=ACCEPT, forward=REJECT, masq=1 (стандарт)
|
||
- LAN→WAN forwarding: ALLOW
|
||
|
||
Дополнительные input rules для wan (стандартные OpenWRT): Allow-DHCP-Renew, Allow-Ping, Allow-IGMP, Allow-DHCPv6, Allow-MLD, Allow-ICMPv6-*, Allow-IPSec-ESP.
|
||
|
||
## DNS (https-dns-proxy / DoH)
|
||
|
||
- LAN DNS обслуживает dnsmasq (`192.168.1.1:53`), который форвардит на локальные `https-dns-proxy`: `127.0.0.1#5053` (resolver 1) и `#5054` (resolver 2).
|
||
- Резолверы после фикса 2026-08-24:
|
||
- `https://1.1.1.1/dns-query` (Cloudflare)
|
||
- `https://one.one.one.one/dns-query` (Cloudflare)
|
||
|
||
### ⚠️ Инцидент 2026-08-24: провайдер режет DoH
|
||
|
||
Весь DNS локальной сети умер: dnsmasq логировал `Maximum number of concurrent DNS queries reached (max: 150)`, у https-dns-proxy куча соединений в FIN_WAIT1 к 8.8.4.4:443 и 104.16.249.249:443, клиенты получали таймауты.
|
||
|
||
**Побочный эффект:** пока DNS был мёртв, роутер не мог резолвить NTP-пул (`0.openwrt.pool.ntp.org`) — часы стояли на ~2.5 месяца назад (Jun 12 при реальном Aug 24). После фикса DNS NTP доехал и время синхронизировалось. Проверить: `date` на роутере. Если DNS снова ляжет — ждать рассинхрона часов (логи/крона).
|
||
|
||
Проверено с роутера: **рабочие** — `https://1.1.1.1/dns-query` (HTTP 200, отвечает), UDP 8.8.8.8:53, UDP 1.1.1.1:53, ICMP. **Нерабочие** — `https://dns.google/dns-query`, `https://cloudflare-dns.com/dns-query` (таймаут TCP 443), `https://dns.quad9.net/dns-query`. Обычный TCP 443 наружу работает (1.1.1.1:443 → 301), т.е. блокировка точечная по DoH-резолверам.
|
||
|
||
**Фикс:**
|
||
```
|
||
uci set https-dns-proxy.@https-dns-proxy[0].resolver_url='https://1.1.1.1/dns-query'
|
||
uci set https-dns-proxy.@https-dns-proxy[1].resolver_url='https://one.one.one.one/dns-query'
|
||
uci commit https-dns-proxy
|
||
/etc/init.d/https-dns-proxy restart
|
||
/etc/init.d/dnsmasq restart # при необходимости; dnsmasq_config_update='*' обычно сам
|
||
```
|
||
|
||
## Config backup (с 2026-06-12)
|
||
|
||
Daily UCI/config backup → [[kreknin-synology]]:
|
||
- `/root/uci-backup.sh` — `sysupgrade -b /tmp/uci-backup.tar.gz` → `dbclient -i /root/.ssh/id_kreknin -y vitya@195.19.90.188` (pipe stdin).
|
||
- Cron `/etc/crontabs/root`: `30 3 * * * /root/uci-backup.sh`.
|
||
- Ключ роутера `/root/.ssh/id_kreknin` (dropbear ed25519) авторизован на kreknin с **forced-command** `cat > /volume1/NetBackup/openwrt/openwrt-latest.tar.gz` + `no-pty,no-*-forwarding` — ключ умеет только записать один файл (роутер публично-доступен → ограничение обязательно).
|
||
- Latest-only (без истории снапшотов); tarball ~15 КБ. См. [[../concepts/backup-inventory-2026-06]].
|
||
|
||
## Что нужно сделать (на потом)
|
||
|
||
- Отключить устаревшие redirects на 192.168.1.10 (DSM/FTP/SQL/Cloud Station) — снижает attack surface.
|
||
- Запланировать DDNS для случая смены публичного IP (REGRU domains всё ещё указывают на 94.19.247.14).
|
||
- При планировании [[future-resilient-architecture-goals]] — добавить **second WAN** (3G/4G/LTE через USB-modem) на роутер? OpenWRT поддерживает multi-WAN.
|