Яке з’єднання відповідає: домени маршрутизації для DNS VPN із розділеним тунелем

Залиште звичайний перегляд на локальному з’єднанні, а імена компанії розв’язуйте через DNS-сервер, який надає тунель. Вимкнення маршруту за замовчуванням у VPN дає першу половину і залишає другу незібраною. Далі — налаштування, якого бракує, розділовий знак, що змінює його зміст, і єдина команда, яка показує, яке з’єднання справді відповіло. Увесь текст припускає NetworkManager і systemd-resolved, бо саме ця пара зазвичай стає початком плутанини.

Крок перший: відокремте маршрут від розв’язувача

ipv4.never-default відповідає на питання маршрутизації і не дає NetworkManager встановити це з’єднання як шлях для всього трафіку IPv4. Домен маршрутизації DNS відповідає на інше питання: які сервери імен якого з’єднання отримують запит для відповідного суфікса. Жодне не передбачає іншого, і профіль може роками мати одне, не маючи другого. Лише маршрут означає, що тунель несе підмережі компанії і його розв’язувач відповідає на імена компанії, а все інше залишається недоторканим.

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

Крок другий: додайте до профілю домен лише для маршрутизації

Припустимо, з’єднання називається corp-vpn, суфікс компанії — internal.example, а розв’язувач тунелю вже доступний. Спершу прочитайте поточні значення, бо команди нижче змінюють властивості, у яких уже можуть бути записи.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

Провідна тильда позначає домен лише для маршрутизації, тому відповідні запити йдуть на сервери цього з’єднання, а суфікс не додається до коротких імен. Приберіть тильду — той самий рядок стане ще й суфіксом пошуку, що є іншим результатом, який люди рідко мають на увазі. Обидва налаштування вище — IPv4, тому профілю з двома стеками потрібні ipv6.never-default і той самий домен маршрутизації в ipv6.dns-search, інакше бік IPv6 далі використовує маршрут за замовчуванням, і внутрішні імена там не розв’язуються.

Крок третій: запитайте resolvectl, яке з’єднання відповіло

Виконайте resolvectl status і прочитайте DNS-сервери та домени кожного з’єднання, потім виконайте resolvectl query host.internal.example для справжнього внутрішнього імені, яке вам дозволено запитувати. Друга команда — єдиний прямий доказ того, що домен маршрутизації робить свою роботу, бо вона називає з’єднання, яке відповіло. Сам список стану доводить конфігурацію; запит доводить розв’язання.

systemd-resolved вибирає найкраще відповідний домен маршрутизації, тому конкретніший домен на іншому з’єднанні все ще може виграти гонку. Якщо запит повертається з несподіваного з’єднання, прочитайте списки доменів, перш ніж торкатися DNS-сервера VPN. Кореневий домен ~. збігається з усім, і якщо він уже є, ваш конкретний домен усе одно виграє для своїх імен, поки з’єднання відповідає на значно більше, ніж ви просили. Видаліть або звузьте цей кореневий запис, коли метою були лише імена компанії.

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

Крок четвертий: коли ім’я розв’язується, а служба ні

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

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

Крок п’ятий: не замінюйте розв’язувач, щоб виправити відсутній домен

Порада, яка перезаписує файл розв’язувача або встановлює інший менеджер розв’язувача, розв’язує іншу проблему. Це зміни системної інтеграції з власними режимами відмови, і жодна з них не додає домен маршрутизації, який ніколи не налаштовувався. Визначте, який компонент володіє розв’язанням імен на машині, перш ніж його замінювати, бо на робочому столі NetworkManager із systemd-resolved це володіння вже визначене. Боротьба з ним — це спосіб, яким робоча конфігурація перетворюється на щось, що ніхто не може відтворити.

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