Problem statement
Does an active OpenVPN service prove private names should resolve?
No. First distinguish a missing private route from a name-only failure. Review the actual client config for script-security/up/down and the helper path. Ubuntu installs the helper only if supplied locally; CentOS 7/Anolis 8 can generate a helper. --no-dns on those two skips new DNS work but does not remove existing hooks.
The supplied helpers may use systemd-resolved, NetworkManager or direct resolv.conf writes, depending on the helper and host. Inspect that exact source and its configured defaults (including 10.7.7.53/114.114.114.114 and reshub.cn) instead of assuming they match your network. CRLF or a non-executable helper is one candidate cause, not a confirmed diagnosis.
Official references
What to check
- Read-only: ip route; ls -l /etc/openvpn/update-resolv-conf; grep -nE "^(script-security|up|down) " /etc/openvpn/client/client.conf
- Where available, resolvectl status and nmcli device show reveal resolver state. Also inspect readlink -f /etc/resolv.conf and its contents. Do not run the hook manually as a “check”: it can change DNS.
- Inspect journalctl -u openvpn-client@client -n 100 --no-pager locally; adapt custom names and redact secrets. Confirm the cause before a separately planned change.
Parent topic
Choose the distribution-specific client and inspect resolver ownership before changing DNS hooks.