Приватний 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. Маршрут, доступ до служби й автентифікація залишаються незалежними від розв’язання імен, а робочий пошук нічого не говорить про пропускну здатність. Якщо приватна сторінка повільна, але розв’язується, резолвер зробив свою справу, і проблема перемістилася на шлях.