Окей, решил проблему. Похоже, что внутри UDM не используются статические маршруты, политики и прочее. В итоге пришлось настроить скрипт для добавления маршрутов на уровне UDM через ssh. Проверю, нужно ли интегрировать это в постоянное хранилище или запускать при включении, а также какие изменения конфигурации могут сломать интеграцию. (Кстати, я выяснил, что мой VPN-туннель, о котором я говорил, назывался wgclt1 (я узнал это, выполнив команду `ip a`), у тебя может быть другой).

#!/usr/bin/env bash
# Пример: добавление маршрута 10.100.0.0/24 через 10.100.20.1 через wgclt1 с отдельной таблицей

DEV="wgclt1"
TABLE_ID=200
TABLE_NAME="wgclt"
PEER="10.100.20.1"
NET="10.100.0.0/24"

# 1) Зарегистрировать пользовательскую таблицу (если она еще не создана)
grep -qE "^${TABLE_ID}\s+${TABLE_NAME}$" /etc/iproute2/rt_tables \
  || echo "${TABLE_ID} ${TABLE_NAME}" | sudo tee -a /etc/iproute2/rt_tables

# 2) Заполнить таблицу
ip route add ${PEER}/32 dev ${DEV} table ${TABLE_NAME}
ip route add ${NET} via ${PEER} dev ${DEV} table ${TABLE_NAME}

# 3) Правила политики, чтобы направлять совпадающий трафик в нее
ip rule add to ${PEER}/32 lookup ${TABLE_NAME} priority 100
ip rule add to ${NET} lookup ${TABLE_NAME} priority 200

# 4) Очистить кеш маршрутов, чтобы изменения вступили в силу немедленно
ip route flush cache

echo "✔ Маршрутизация для ${NET} через ${PEER} на ${DEV} (таблица ${TABLE_NAME}) применена."

Это исправление не выживает перезагрузку, поэтому ты можешь настроить загрузочный скрипт udm (ссылка на github), чтобы правила добавлялись при запуске. Теперь DNS-переадресация работает как ожидалось. Я могу пинговать app.local.client.co из любой точки моей сети, и DNS-переадресация будет обрабатываться UDM. Как приятный бонус, теперь я могу подключаться и использовать удаленную подсеть через VPN без настройки policy-routing, кажется, вышеуказанных шагов достаточно для маршрутизации трафика по мере необходимости.

Так вот, клиентская ОС не использует 10.100.10.15 в качестве DNS, как указано в файле *.conf. У меня тоже похожая настройка, но с некоторыми отличиями. Я использую сертификат Let's Encrypt (так как у меня есть домен), загруженный на мой UCG MAX, который выступает в роли WireGuard-сервера. Мои сервисы работают через Docker на NAS, а на UCG я просто добавил DNS-записи (типа A) в Policy Engine > DNS, указывающие все поддомены на IP-адрес NGINX Proxy Manager, который работает на том же NAS. Я не изменял файл .conf WireGuard вручную. Когда я подключаюсь, например, со смартфона, я ввожу поддомен как subdomain.mydomain.com и могу получить доступ к сервису без проблем. Я не понимаю, чего не хватает в твоей конфигурации, чтобы внутренняя DNS работала так, как тебе хотелось бы. Надеюсь, кто-нибудь сможет прояснить ситуацию для нас.