vps/hosts/gfw.windy.lan.md

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) — 3 NICs: net0→vmbr0(LAN66/eth0), net1→vmbr1(LAN55/eth1, up but unaddressed), net2→VLAN10/ubunt_upg(eth2, 192.168.10.1/24) (topology 2026-08-09; eth2/VLAN10 live verified 2026-08-11)

Do not store the root password in this repository.

OpenClash

OpenClash runs /etc/openclash/clash (clash_meta core) with configuration /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); OpenClash custom DNS uses mosdns on 127.0.0.1:6052 as its nameserver/default-nameserver for DIRECT-rule real-IP resolution (/etc/mosdns/config.yaml): domestic domains → AGH .36:53, foreign → 223.5.5.5/119.29.29.29 (Chinese public DNS). mosdns is not in the client query path — LAN/VLAN10 clients receive fake-ip from clash :7874.

  2026-08-12: fixed missing has_resp → accept guard after the domestic branch in /etc/mosdns/config.yaml (domestic queries were double-forwarded, final answer came from CN public DNS, bypassing AGH blocking/rewrites; verified via dup.baidustatic.com before/after); added domestic_fallback (fallback plugin: primary=AGH, secondary=CN public DNS, 500ms) so domestic DIRECT lookups survive an AGH outage. Backups: config.yaml.bak-20260812 / config.yaml.bak-fallback-20260812. See docs/lan-dns-architecture.md §1. 2026-08-13 (W1N-62): foreign branch now uses encrypted DoH https://adg.chans.xyz/dns-query (self-hosted, hk2) via new foreign_upstream / foreign_fallback plugins; non-CN queries → DoH, falls back to CN public DNS after 1000ms. bootstrap = existing CN public DNS IPs (no self-loop). Live-verified: google/youtube real IP + AAAA restored (2607:f8b0…), dup.baidustatic.com → 0.0.0.0 (AGH intercept kept), clash 7874 fake-ip plane unchanged. Final decision (2026-08-13): DoH goes DIRECT to hk2, not via clash proxy — foreign_upstream points only at the self-hosted resolver adg.chans.xyz (hk2), which is directly reachable and already encrypted (DoH/TLS) with clean answers, so forcing the proxy adds nothing and would couple the DNS plane to clash (nft output chains also show OpenClash does not currently redirect router-own TCP). Kill-test: foreign queries answered during clash outage, watchdog auto-restarted. Backups: config.yaml.bak-foreign-doh-20260813-103746 / config.yaml.bak-foreign-doh-20260813-103813.

• nft: OpenClash injects TPROXY/redirect + DNS-hijack rules into table inet fw4; a residual table inet passwall exists with 0 packets (unused)

Listener	Port
HTTP	7890
SOCKS	7891
Redirect	7892
Mixed	7893
TPROXY	7895
DNS	7874
Dashboard	9090

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

gfw's third NIC eth2 hosts the ubunt_upg interface at 192.168.10.1/24, serving the dedicated ubnt-upg SSID VLAN 10 (untagged access path from a VLAN-capable switch/trunk; AP management stays untagged on LAN66). The ubunt_upg zone runs the only DHCP server for 192.168.10.0/24 (UDP/67), allows DNS (53), and applies 192.168.10.0/24 → eth0 masquerade (NAT) for Internet egress. forward_ubunt_upg isolates VLAN10 from LAN66/55 and RFC1918 (deny counters 0, accept_to_lan passes).

Live-verified 2026-08-11: an ubnt-upg client received 192.168.10.168 (lease in /tmp/dhcp.leases), the 192.168.10.0/24 masquerade counter climbed (215 pkts/42KB), and the LAN55/LAN66 deny counters stayed 0 → VLAN10→LAN isolation holds. See docs/lan-se5420-deployment-guide.md, docs/unifi-openwrt-vlan10-implementation-examples.md

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.