GL-MT300N-V2（Mango）4.3.25において、次のようなWireGuard VPNを構成する。
- WAN側はDHCP（デフォルト）
- LAN側は192.168.8.0/24（デフォルト）
- VPNはターゲットドメインまたはIPに基づくVPNポリシー（スプリットトンネリング）で192.168.10.0/24のみをWireGuardへ向ける
というとても単純で一般的な構成を作るとLAN側からDNSが引けなくなる（Query refusedが返る）。ただしWireGuard VPNはちゃんと確立して192.168.10.0/24にアクセスできるし、外部（例えば8.8.8.8）へpingは到達する。
あまりに単純なので設定ミスとも考えられず、色々いじっていたところキルスイッチをオン・オフすると直ることに気づいた。更にこれは再起動すると元の状態に戻ってしまうことから、どうやら不具合であると認識した（つまりおそらく初期状態が変）。こういうことの原因究明はChatGPTが比較的向いていると認識しているので色々試行錯誤させたところ、その過程でdnsmasqをrestartすることでも直ることがわかった。
この機種は（というかGL.iNetのルータは）OpenWrtベースとはいえVPN周りは大分独自実装になっていて、その中の処理順序が何らかおかしくてdnsmasqが読むべきファイルが用意されないうちにdnsmasqを（再）起動している感じのことは大体わかるが、決定的な部分にはたどり着かなかったため/etc/hotplug.d/iface/99-dnsmasq-wgを作成してdnsmasqをrestartすることにした。
#!/bin/sh
[ "$ACTION" = "ifup" ] || exit 0
[ "$INTERFACE" = "wgclient" ] || exit 0
(
sleep 2
/etc/init.d/dnsmasq restart
) &
これをchmod r+xしておけば取り敢えず何とかなるっぽい。
(2026.10.17)