[2026-09-17] eagle: family/how-to/rasputin-router.md family/how-to/zont-config-compiler.md family/tech/zont-api.md
This commit is contained in:
Alexey Martemyanov
@@ -545,20 +545,54 @@ default via 192.168.2.2 dev eth0 proto static src 192.168.2.157
|
||||
|
||||
То есть Rasputin получает адрес `192.168.2.157` **от роутера `192.168.2.2`** и выходит в интернет через него, а `192.168.2.2` — через GPON `192.168.0.1`. Топология запроса подтверждена: `rasputin → 192.168.2.2 → 192.168.0.1 (GPON) → 192.168.0.50`.
|
||||
|
||||
### План ремонта (НЕ применён, ждёт апрува)
|
||||
### ✅ ЧТО СДЕЛАНО (2026-09-17) — правило `ip rule` добавлено и работает
|
||||
|
||||
Применено и **проверено Alex руками** (80 порт на `192.168.0.50` открылся):
|
||||
|
||||
```sh
|
||||
# 1. ip rule — расширить bypass на GPON-сегмент
|
||||
# на живом роутере
|
||||
ip rule add to 192.168.0.0/24 lookup main priority 100
|
||||
# 2. та же строка в /etc/rc.local — иначе умрёт после ребута
|
||||
# 3. firewall: Allow-upstream-LAN dest_ip += 192.168.0.0/24, добавить proto icmp
|
||||
# 4. проверить, что masq зоны wan покрывает 192.168.0.0/24 (иначе ответ не вернётся)
|
||||
|
||||
# и то же записано в /etc/rc.local (чтобы выжило ребут)
|
||||
```
|
||||
|
||||
Бэкап до правки: `/etc/rc.local.bak.20260917-132639`
|
||||
|
||||
Правила после правки (две строки priority 100 — это нормально):
|
||||
|
||||
```text
|
||||
100: from all to 192.168.2.0/24 lookup main
|
||||
100: from all to 192.168.0.0/24 lookup main
|
||||
101: from all iif br-lan lookup vpn
|
||||
```
|
||||
|
||||
> 🔴 **Правка файлов на роутере — через скачивание → локальную правку → заливку.**
|
||||
> `sed -i` по живому конфигу **запрещён** (и был заблокирован в этой сессии).
|
||||
> Порядок: `scp` вниз → `patch` локально → `scp` наверх → `cat` для проверки.
|
||||
|
||||
### ⚠️ Что ОСТАЛОСЬ не сделано (осознанно, по объёму команды «ip rule»)
|
||||
|
||||
Alex дал команду только на `ip rule`. Следующие два пункта **не трогались**:
|
||||
|
||||
1. **NAT/masq для `192.168.0.0/24`** — нет. Пакет уходит с source `192.168.6.x`.
|
||||
Проверка показала, что 80 порт всё равно отвечает (GPON, судя по всему, маршрутизирует
|
||||
обратно), поэтому это **не блокер**, но и не гарантия.
|
||||
2. **ICMP** — `Allow-upstream-LAN` в nft по-прежнему только `tcp`+`udp`, без `icmp`.
|
||||
Значит **пинг из LAN в `192.168.0.0/24` не работает до сих пор**, хотя TCP/UDP проходит.
|
||||
Не путать «не пингуется» с «не работает».
|
||||
|
||||
### План ремонта (исходный, для истории)
|
||||
|
||||
```sh
|
||||
# 1. ip rule — расширить bypass на GPON-сегмент ← СДЕЛАНО
|
||||
ip rule add to 192.168.0.0/24 lookup main priority 100
|
||||
# 2. та же строка в /etc/rc.local ← СДЕЛАНО
|
||||
# 3. firewall: Allow-upstream-LAN dest_ip += 192.168.0.0/24, добавить proto icmp ← НЕ сделано
|
||||
# 4. проверить, что masq зоны wan покрывает 192.168.0.0/24 ← НЕ сделано
|
||||
```
|
||||
|
||||
Порядок работ по боевому конфигу: коммит ДО → правка → заливка → проверка Алекса руками → коммит ПОСЛЕ.
|
||||
|
||||
Три причины: (1) `ip rule 100` покрывает только `192.168.2.0/24` — трафик на `192.168.0.0/24` не матчится и уходит в `table vpn`/`tun0` вместо WAN; (2) нет NAT/masq для GPON-сегмента — пакет уходит с source `192.168.6.x`, ответ не может вернуться; (3) `Allow-upstream-LAN` создан только для `tcp`+`udp`, **без `icmp`** — ICMP из LAN падает в KillSwitch, и роутер сам отдаёт `Destination Port Unreachable`. Поэтому **пинг не индикатор**: для `192.168.0.0/24` он врёт так же, как для `192.168.2.0/24`. Проверять только тем каналом, которым будете работать (SSH/TCP), напр. `nc -zv 192.168.0.50 80` или `ssh -o BatchMode=yes`.
|
||||
|
||||
## Downstream LAN Access
|
||||
|
||||
```text
|
||||
@@ -765,6 +799,10 @@ Firewall backup from Cloudflare direct-bypass change:
|
||||
/etc/config/firewall.bak.20260714-195530
|
||||
```
|
||||
|
||||
Роутинг через туннель (`tunvpn`) — 2026-07-14.
|
||||
Firewall/Cloudflare bypass — 2026-07-14.
|
||||
GPON-транзит (`ip rule` на `192.168.0.0/24`) — 2026-09-17.
|
||||
|
||||
Rollback example:
|
||||
|
||||
```sh
|
||||
@@ -783,6 +821,18 @@ uci commit dhcp
|
||||
/etc/init.d/dnsmasq restart
|
||||
```
|
||||
|
||||
Rollback GPON-транзита (2026-09-17):
|
||||
|
||||
```sh
|
||||
# живая система
|
||||
ip rule del to 192.168.0.0/24 lookup main priority 100
|
||||
# постоянство
|
||||
cp /etc/rc.local.bak.20260917-132639 /etc/rc.local
|
||||
```
|
||||
|
||||
> ⚠️ Правки `/etc/rc.local` на роутере делать **только** через `scp`-вниз → `patch` локально →
|
||||
> `scp`-наверх. `sed -i` по живому конфигу запрещён.
|
||||
|
||||
## Notes And Pitfalls
|
||||
|
||||
- The Cloudflare bypass depends on Mac `cloudflared` using QUIC. If the Mac falls back to HTTP/2/TCP/443, the router exception will not match.
|
||||
@@ -792,8 +842,8 @@ uci commit dhcp
|
||||
- The firewall allow alone would not be sufficient, because policy routing rule `101` sends LAN ingress to `table vpn`. The direct `ip rule`s at priorities `98` and `99` must remain before priority `101`.
|
||||
- Rule order in `forward_lan` matters: Cloudflare direct allow must stay above `KillSwitch`.
|
||||
- `eth0` is the **active** WAN as of 2026-09-17 (`192.168.2.157/24`, gw `192.168.2.2`); `usb0` is idle. At the 2026-07-22 capture this was inverted (`eth0` down, `usb0` carrying the default route). Do not trust the old banner — re-read `ip route` before assuming which WAN is live.
|
||||
- 🔴 **Транзит из LAN `192.168.6.0/24` в GPON-сегмент `192.168.0.0/24` НЕ работает (2026-09-17).** Причин три: `ip rule 100` не покрывает `192.168.0.0/24`; нет NAT/masq для этого направления; ICMP не разрешён в `Allow-upstream-LAN`. План ремонта — в одноимённом разделе. **Пока не применён.**
|
||||
- 🔴 **ICMP не является индикатором доступности `192.168.0.0/24` — и подавно.** `Allow-upstream-LAN` создан только для `tcp`+`udp`, поэтому эхо-запросы из LAN падают в `KillSwitch` и роутер отвечает `Destination Port Unreachable` от себя. Проверять TCP-портом (`nc -zv 192.168.0.50 80`) или SSH.
|
||||
- 🔴 **Транзит из LAN `192.168.6.0/24` в GPON-сегмент `192.168.0.0/24` — ЧАСТИЧНО ПОЧИНЕН (2026-09-17).** `ip rule` добавлено (живая система + `/etc/rc.local`), Alex проверил 80 порт на `192.168.0.50` — работает. Было три причины: `ip rule 100` не покрывал `192.168.0.0/24` (✅ исправлено); нет NAT/masq для этого направления (❌ не сделано, не блокер); ICMP не разрешён в `Allow-upstream-LAN` (❌ не сделано). Подробности — в разделе «Транзит Rasputin → 192.168.0.0/24».
|
||||
- 🔴 **ICMP по-прежнему не индикатор доступности `192.168.0.0/24`.** `Allow-upstream-LAN` создан только для `tcp`+`udp`, поэтому эхо-запросы из LAN падают в `KillSwitch` и роутер отвечает `Destination Port Unreachable` от себя. **Пинг в GPON-сегмент не работает даже после починки `ip rule`** — TCP/UDP при этом проходит. Проверять TCP-портом (`nc -zv 192.168.0.50 80`) или SSH.
|
||||
- Различай два похожих симптома: `Destination Port Unreachable` **от роутера `192.168.6.1`** = локальное отбивание ICMP/firewall-ом, а не закрытый порт на хосте. Признак живости — ответ на TCP/SSH, а не текст ICMP-ошибки.
|
||||
- 🔴 **Ping from Mac to an unreachable `192.168.2.x` host returns `Destination Port Unreachable` from `rasputin.lan (192.168.6.1)`, NOT a plain timeout.** This is the router rejecting the attempt — it does **not** mean the host is up with a closed port. Use `arp (incomplete)` + `100% packet loss` as the liveness signal. Confirmed 2026-09-15 (see the dedicated section above).
|
||||
- Liveness of `192.168.2.0/24` hosts is best verified with the channel you intend to work through: key-based SSH (`ssh -o BatchMode=yes root@192.168.2.176 'uptime'`). Ping and web ports can mislead; an answered SSH session cannot.
|
||||
|
||||
Reference in New Issue
Block a user