DNS OpenVPN на шлюзі: dnsmasq і охоплення міжмережевого екрана

Запустіть dnsmasq на адресі тунелю, дозвольте DNS лише з пулу клієнтів, проштовхніть резолвер, потім перевірте прямі запити та власний пошук застосунку.

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

Слухач — це локальна служба з двома напрямками

На вході клієнт надсилає запит на адресу тунелю шлюзу через порт 53. На виході демон пересилає цей запит своєму налаштованому вищому серверу. Обидві половини мають працювати, і вони відмовляють по-різному.

Тайм-аут, про який повідомляє клієнт, і тайм-аут, видимий на шлюзі, — не та сама несправність.

Прив'яжіть адресу тунелю, а не кожну адресу

Окремий екземпляр dnsmasq для цього завдання потребує явної адреси прослуховування, режиму прив'язки, який терпить появу тунелю після запуску, і одного ясного вищого сервера. Це найменша версія, яку я використовую:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic прив'язує окремі адреси і дає раду, коли tun0 з'являється пізніше, що важливо на хості, де служба VPN перезапускається. Перелік loopback зберігає роботу локальних інструментів, не додаючи публічного слухача. no-resolv не дає демону успадкувати вищі сервери з конфігурації резолвера хоста, а no-hosts не дає цьому екземпляру публікувати файл hosts шлюзу. Жоден із цих варіантів не дає нікому права опитувати службу.

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

Дозвольте вхід DNS, а не транзит тунелю

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

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS працює через TCP так само, як через UDP, тому правило лише для UDP залишає великі відповіді в відмові так, що це виглядає періодично. Це не ufw route дозволи, і вони не повинні стати широким дозволом на tun0. Порядок важливий не менше вмісту: раніше правило, яке відкидає весь вхід з tun0, усе одно перемагає, а додавання дозволу нижче остаточного скидання нічого не створює.

Якщо DNS шлюзу тепер частина проєкту, свідомо перегляньте ту попередню політику і запишіть чому.

Вища половина — окремий шлях

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

Не додавайте необмежений вихід тунелю, щоб відповіді працювали; відстежувані відповіді цього не потребують.

Проштовхніть параметр, потім перевірте передачу

Сервер може оголосити резолвер клієнтам проштовхнутим параметром. Це параметр, а не інструкція, якій операційна система зобов'язана підкорятися:

push "dhcp-option DNS 10.90.0.1"

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

Мета — один власник конфігурації резолвера клієнта, і проштовхування зазвичай є цим власником лише тоді, коли платформа клієнта погоджується.

Перевірте те, що ви справді збудували

Запитайте одне приватне повне доменне ім'я і одне дозволене зовнішнє ім'я напряму за адресою тунелю, через UDP і TCP. Потім повторіть звичайним шляхом пошуку застосунку.

Якщо прямі запити працюють, а застосунок усе ще відмовляє, несправність у передачі, а не на сервері:

  • Клієнт так і не застосував проштовхнутий параметр.
  • Пізніше було задано інший резолвер, і він виграв гонку.
  • Застосунок використовує власну бібліотеку резолвера або кешовану відповідь.

Заверште підтвердженням, що джерело поза схваленим шляхом VPN взагалі не може використовувати слухача. Успішне розв'язання не дає прав на повернуту адресу, тому тримайте ці два питання окремо.

Схожі статті