Приватный DNS Pritunl не работает? Добавьте узкий маршрут резолвера

Приватные имена разрешаются для всех в корпоративной сети и истекают по таймауту для всех в VPN. Резолвер отвечает шлюзу, маршрут к нему существует, а запрос так и не получает ответа. Не хватает не другого публичного резолвера и не более широкого маршрута: не хватает адреса источника, на который приватный DNS-сервер готов ответить.

Убедитесь, что резолвер отклоняет ваш пул клиентов

Начните с доказательства, что сбой связан с источником, а не с доступностью. С подключённого клиента напрямую опросите приватный резолвер и посмотрите, истекает ли запрос или возвращается как отказ. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 с таймаутом, тогда как тот же запрос со шлюза успешен, указывает на политику доступа на резолвере. Ответ SERVFAIL указывает совсем в другое место, обычно на зону или вышестоящий форвардер.

Запишите адрес клиента перед проверкой. ip -4 addr show tun0 на клиенте или аренда, показанная в консоли, подскажет, какой пул видит резолвер.

Затем убедитесь, что путь вообще существует. Маршрут, отправляющий адрес резолвера в туннель, — это предпосылка, а не решение; если пакеты никогда не приходят, политика источника даже не рассматривается. Проверьте это командой ip route get 10.40.0.53 на клиенте.

Добавьте один маршрут к хосту вместо трансляции всего

Руководство Pritunl по приватному DNS описывает узкое средство: маршрут /32 с включённым NAT для адреса резолвера, причём этот адрес выбран как DNS-сервер клиентов. Маршрут меняет источник, который видит резолвер, только для DNS-трафика. Трафик приложений сохраняет выбранную вами схему с сохранением источника.

Настройте его через поддерживаемого владельца маршрутов сервера, предварительно проверив существующие маршруты на пересечение. В примере выше назначение — 10.40.0.53/32 с включённым NAT, а пул клиентов остаётся 10.90.0.0/24. Не транслируйте весь приватный диапазон, чтобы исправить одну службу, потому что каждая нижестоящая политика, опирающаяся на реальный адрес клиента, начнёт видеть вместо него шлюз. Подтвердите адрес, который резолвер фактически получает, наблюдая за его журналом запросов во время тестового поиска. Один маршрут к хосту ничего не доказывает о трансляции или разрешении.

Резолвер по-прежнему должен разрешать транслированный источник по UDP и TCP, и его ответы должны иметь возможность вернуться. Изменение источника не может создать отсутствующую зону или запись.

Решите, кто отправляет запрос — сервер или клиент

Pritunl также описывает схему DNS-прокси, связанную с VPN Client DNS Mapping, где сервер пересылает вышестоящие запросы за клиентов. В этой модели вышестоящий источник принадлежит собственной сетевой среде сервера, и исключение на стороне клиента — неверное решение.

Определите, какая модель активна, прежде чем что-то добавлять. Три пересекающихся исправления, прокси, переопределение резолвера на клиенте и ручной скрипт NAT обычно означают, что никто не установил: какой компонент должен отправлять запрос. Проверьте также bootstrap: резолвер только для приватных зон не может быть единственным способом найти конечную точку до появления туннеля, а постоянное изменение резолвера не должно переживать подключение.

Проверьте приватный поиск, а не публичную веб-страницу

После применения изменения и повторного подключения проверьте действующую конфигурацию резолвера клиента, затем разрешите имя, о котором вы знаете, что оно существует только в приватной зоне. dig intranet.example.net без явного сервера показывает, что клиент действительно использует. Затем отправьте запрос на адрес, который вернул этот поиск, потому что разрешение и доступ к службе — отдельные шаги. Браузер, загружающий публичные сайты через DNS-over-HTTPS, ничего не доказывает о пути приватного резолвера операционной системы. Публичный вторичный резолвер тоже не является авторитетом для внутренней зоны.

Запишите адрес резолвера, маршрут /32 и настройку DNS клиента вместе в заметках сервера. Половина этой конфигурации, восстановленная отдельно, воспроизводит исходный сбой.

Наконец, подтвердите, что туннель по-прежнему маршрутизирует назначение приложения после успешного DNS. Маршрут, доступ к службе и аутентификация остаются независимыми от разрешения имён, а работающий поиск ничего не говорит о пропускной способности. Если приватная страница медленная, но разрешается, резолвер сделал своё дело, и проблема переместилась на путь.