Files
vps/hosts/gfw.windy.lan.md
T

69 lines
2.9 KiB
Markdown
Raw Normal View History

2026-08-03 21:10:57 +08:00
# gfw.windy.lan — OpenWrt LAN gateway
## Role and access
| Item | Value |
|---|---|
| Role | LAN gateway and OpenClash transparent/explicit-proxy host |
| IPv4 | `192.168.66.1` |
| SSH | `ssh -4 root@192.168.66.1` (key-only, verified 2026-08-06) |
| OS | ImmortalWrt 25.12.0 (r37854), Linux `6.12.87`, x86/64 |
| **Host** | **PVE VM 140 (`gfw`)** — dual NIC: `net0`→vmbr0(LAN66), `net1`→vmbr1(LAN55) (verified 2026-08-09) |
2026-08-03 21:10:57 +08:00
Do not store the root password in this repository.
2026-08-03 21:10:57 +08:00
## OpenClash
OpenClash runs `/etc/openclash/clash` (clash_meta core) with configuration
2026-08-03 21:10:57 +08:00
`/etc/openclash/pass-cat.yaml`.
- Core: **Mihomo Meta v1.19.29** (linux-amd64, with_gvisor; upgraded from
`alpha-g9ae1cc2` on 2026-08-06, backup `clash_meta.bak.alpha-g9ae1cc2`) —
tracked in Linear W1N-50
- OpenClash app: **luci-app-openclash 0.47.133** (GitHub latest)
- Mode: **fake-ip + TPROXY transparent proxy** (`operation_mode=fake-ip`,
`en_mode=fake-ip`, `proxy_mode=rule`); fake-ip network `198.18.0.0/16`
- DNS path: dnsmasq → clash DNS `127.0.0.1#7874` (`server=127.0.0.1#7874` in
dnsmasq config); `mosdns` also listens on `127.0.0.1:6052` but is not the
active resolver path
- nft: OpenClash injects TPROXY/redirect + DNS-hijack rules into
`table inet fw4`; a residual `table inet passwall` exists with 0 packets (unused)
2026-08-03 21:10:57 +08:00
| Listener | Port |
|---|---:|
| HTTP | `7890` |
| SOCKS | `7891` |
| Redirect | `7892` |
| Mixed | `7893` |
| TPROXY | `7895` |
| DNS | `7874` |
| Dashboard | `9090` |
2026-08-03 21:10:57 +08:00
`8443` is not an OpenClash listener and has no runtime nftables forwarding rule.
It is included only in OpenClash's common TLS-sniffing port list.
## VLAN 10 Wi-Fi feasibility
`gfw` is a VM attached to untagged LAN 66, rather than a physical VLAN-trunk
endpoint. The U6 Lite likewise reaches the ER-X over LAN 66, whose DHCP
service supplies client addresses. Therefore `gfw` cannot currently receive an
SSID's VLAN 10 traffic merely by creating an `eth0.10` interface inside the VM.
Do not treat a local `eth0.10`/`192.168.10.1` configuration as a deployable
Wi-Fi gateway unless the hypervisor/vSwitch and the complete physical path to
the AP have first been configured and verified to carry tagged VLAN 10. The
`ubnt-upg` test receiving a `192.168.66.x` lease was the expected consequence
of the available untagged path, not evidence that this host should compete
with ER-X DHCP. See
[UniFi Network: Dedicated Wi-Fi through a third-party gateway](../docs/unifi-network.md#dedicated-wi-fi-through-a-third-party-gateway).
2026-08-03 21:10:57 +08:00
## Operational note
When OpenClash logs a LAN client request such as
`<client> --> localhost:8443` followed by a connection refusal, it is normally
an explicit-proxy client sending its own loopback request to the gateway. Fix
the originating host's `NO_PROXY` / `no_proxy` configuration; do not create a
listener on this router to mask the problem. See
[the UniFi localhost proxy note](../docs/unifi-openclash-localhost.md).