Спрямувати клієнти OpenVPN на резолвер Pi-hole на іншому хості

Вписати адресу Pi-hole у профіль OpenVPN не означає створити шлях до неї, дати право її опитувати чи гарантувати, що клієнт нею скористається. Коли Pi-hole стоїть на окремій машині в LAN, мають збігтися чотири речі: маршрут від клієнта, переспрямування від шлюзу, зворотний шлях до пулу та політика прийому на самому Pi-hole. Кожен збій виглядає в журналі по-своєму. Пройти їх у цьому порядку швидше, ніж спершу лагодити останній. Звичайне спрощення, відкрити рекурсію для будь-якого джерела, міняє малу проблему на постійну.

Що робить і чого не робить проштовхнута опція DNS

Сервер оголошує резолвер директивою нижче, припускаючи, що 192.168.50.53 — хост Pi-hole. Клієнт отримує опцію і, залежно від платформи та інтеграції резолвера , застосовує її до інтерфейсу тунелю або ігнорує на користь локального stub. Рядок маршруту важливий не менше рядка DNS, бо резолвер, до якого клієнт не дістається, — зовсім не резолвер. Нічого з цього не видно з боку сервера.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Отримати опцію — не те саме, що використовувати її. Linux-клієнт із менеджером резолвера може прийняти проштовхнутий сервер і надсилати до нього лише певні домени; клієнт, який сам керує DNS, може повністю перезаписати налаштування. Проштовхнуті маршрути на деяких платформах теж обмежені, і резолвер лишається недосяжним, хоча опцію було прийнято. Перевіряйте на клієнті, який сервер відповідає, а не на сервері, що було надіслано.

Опція також нічого не каже про бік сервера. DNS-трафік усе одно має пройти від клієнта до шлюзу і від шлюзу до Pi-hole, перш ніж будь-яка опція почне щось означати. Відсутній маршрут і відхилений запит виглядають з боку клієнта однаково, тож спершу підтвердьте переспрямування на шлюзі.

Зворотний шлях від Pi-hole до пулу

Якщо адресу джерела клієнта збережено, Pi-hole відповідає на адресу всередині пулу VPN. Його власна таблиця маршрутизації, ймовірно, нічого не знає про цей пул, тому відповідь іде на його шлюз за замовчуванням і зникає. Журнал запитів показує запит без відповідного відповіді, що легко сприйняти за проблему брандмауера.

Дайте LAN-роутеру статичний маршрут до пулу зі шлюзом OpenVPN як наступним переходом або транслюйте джерело на шлюзі перед переспрямуванням до Pi-hole. Перше залишає адреси кожного клієнта видимими в журналі запитів Pi-hole. Друге прибирає вимогу зворотного маршруту, але робить кожен запит таким, ніби він прийшов від шлюзу. Жодне не є неправильним; вони відповідають на різні питання.

Якщо важливі звіти чи політика за кожним клієнтом, статичний маршрут — кращий обмін. Якщо LAN керує хтось інший і маршруту немає, трансляція — прагматичний варіант, із зафіксованою втратою ідентичності клієнта. Запишіть, який варіант ви обрали, бо кожне подальше питання щодо журналів залежить від цього.

Режим прослуховування Pi-hole для маршрутизованих клієнтів

Спадний список поведінки прослуховування інтерфейсів на сторінці налаштувань у розділі DNS вирішує, яким джерелам відповідає Pi-hole. Найсуворіший варіант приймає лише клієнтів у безпосередньо підключених мережах; варіант, що дозволяє пристрої не далі одного переходу, поширює це на підмережі за сусіднім маршрутизатором, і саме так виглядає маршрутизований клієнт VPN. Пакет справді приходить на інтерфейс LAN, але його адреса джерела належить іншій підмережі. Це відмова за політикою, а не збій маршрутизації, і різниця важлива, коли читаєш журнали.

Посібник Pi-hole з прослуховування відокремлює локально підключені джерела від маршрутизованих і не вважає інтерфейс прибуття критерієм. Виберіть режим, який дозволяє пул VPN, не дозволяючи весь інтернет, а потім додайте до нього правило брандмауера, що приймає DNS лише з пулу.

Відкрити рекурсію для всіх джерел, щоб запрацював перший запит, — неправильне виправлення. Воно перетворює приватний резолвер на відкритий, а виправлення полягає в обмеженому дозволі, а не глобальному.

Зіставте відповідь із журналом запитів

Запитайте клієнт, потім перевірте сервер і порівняйте обидва. На клієнті з systemd-resolved команди нижче показують, який резолвер дав відповідь і які сервери налаштовані для кожного з'єднання. Використовуйте ім'я, яке знає лише Pi-hole, бо прямий запит на адресу Pi-hole доводить доступність, а не конфігурацію.

resolvectl query intranet.example.lan
resolvectl dns

Очікувана відповідь називає 192.168.50.53 сервером і повертає адресу, яку знав би лише цей резолвер. Потім подивіться на власне подання Pi-hole: pihole -t стежить за журналом запитів у реальному часі, і кожен рядок несе адресу джерела. Якщо джерело — тунельна адреса клієнта, маршрут пулу цілий. Якщо це адреса LAN шлюзу, працює трансляція джерела, і власна адреса клієнта ніколи не з'явиться.

Якщо в журналі взагалі нічого не з'являється, запит так і не дійшов до Pi-hole, і наступне, що треба перевірити, — переспрямування на шлюзі. Якщо запит з'являється, а відповідь не повертається, проблема у зворотному шляху, тобто в попередньому розділі. Таке розділення збою не дає сприйняти помилку маршрутизації за правило брандмауера.

Перевірте правило переспрямування шлюзу

Шлюз має переспрямовувати DNS-пакети клієнта до Pi-hole, і правило, яке це робить, варто прочитати, а не припускати. Команди нижче перелічують правила, що торкаються порту 53, з лічильниками, на хості nftables і на хості iptables. Правило, яке існує, але показує нуль збігів, — сигнал, що трафік відкидається до трансляції.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Читайте лічильники, а не лише правила. Правило, яке ніколи не збігається, означає, що пакет виходить через інший інтерфейс або клієнт його взагалі не надсилав. Правило, яке збігається при кожному запиті, означає, що переспрямування працює, а проблема далі на шляху.

Який би інструмент не використовував хост, тримайте перевірку вузькою: пул як джерело, порт 53 як призначення і Pi-hole як єдина дозволена ціль. Широке правило переспрямування, що дозволяє ще й порт 80, — інша проблема, яка лише чекає свого часу.