Як читати маршрутизацію VPN DNS для кожного з'єднання з resolvectl
resolvectl status показує сервери, домени та маршрут за замовчуванням для кожного з'єднання. Читайте їх разом, потім запитайте ім'я і позначте, яке з'єднання відповіло.
Запустіть resolvectl status і отримаєте стіну блоків за з'єднаннями, кожен зі своїми серверами та своїм рядком доменів. Рядок, що визначає маршрутизацію, — це список доменів, а не адреса сервера імен, бо локальний stub пересилає кожен запит тому з'єднанню, яке заявляє ім'я. Прочитайте ці заявки перед тим, як читати відповідь, потім запитайте ім'я і перевірте, яке з'єднання його створило. Неправильна відповідь від правильного з'єднання — це інша проблема, ніж правильна відповідь від неправильного.
Що повідомляє кожен блок за з'єднанням
Кожен блок перелічує сервери, які резолвер використовуватиме для цього інтерфейсу, список доменів і те, чи є з'єднання маршрутом за замовчуванням. Список доменів — це набір заявок, і резолвер застосовує збіг найдовшого суфікса: запит для host.corp.example заявляє з'єднання з corp.example раніше за те, що має лише маршрут за замовчуванням. Два з'єднання, що заявляють один і той самий суфікс, залишають результат пріоритету й порядку, тому дублікати заслуговують уваги першими. Рядок поточного сервера показує, який із перелічених серверів використовується в той момент.
Stub-адреса, як-от 127.0.0.53 у /etc/resolv.conf, каже лише те, що stub попереду. Вона не називає вищестояще джерело, яке відповіло, тому діагностика, заснована лише на resolv.conf, заходить у глухий кут.
Правильно читайте три типи записів домену
| Запис | На що вона заявляє | Звичайна помилка |
|---|---|---|
| corp.example | домен маршрутизації та суфікс пошуку: імена під ним ідуть до цього з'єднання, а рядок додається до голих імен | видалено, бо маршрутизація все одно ніби працює |
| ~corp.example | лише маршрут: імена під ним ідуть до цього з'єднання, але суфікс не додається | припущено, що він потрібен для маршрутизації |
| ~. | маршрут за замовчуванням: заявляє запити, які не покриває жодне інше з'єднання | залишено активним у розділеному профілі, тож публічні імена йдуть тунелем |
Тильда змінює поведінку пошуку, а не маршрутизацію. Запис без тильди — це і домен маршрутизації, і домен пошуку, тому імена під ним надсилаються до цього з'єднання, а до односкладових імен додається суфікс. Запис із тильдою маршрутизує той самий суфікс, але тримає його поза списком пошуку. Тому видалення тильди змінює те, які голі імена розв'язуються, і тому відсутня тильда — це проблема пошуку, а не збій розділеного DNS.
Запис маршруту за замовчуванням заявляє все, чого не покриває жодне інше з'єднання. Профіль повного тунелю зазвичай хоче його, а розділений профіль зазвичай ні, бо публічні імена тоді йдуть до приватного резолвера і можуть там не розв'язатися. Читайте таблицю щодо наміру профілю, а не копіюйте прапорці між профілями. Коли два з'єднання заявляють один суфікс, вирішіть питання пріоритету, перш ніж правити щось інше.
Запитайте ім'я і подивіться, яке з'єднання відповіло
Підкоманда query друкує адресу, протокол і з'єднання або область, які створили відповідь. Перевірте одне ім'я, яке має заявити приватний суфікс, і одне звичайне публічне ім'я, потім порівняйте повідомлені джерела. Якщо приватне ім'я відповідає з бездротового з'єднання, заявки немає або тунель не працює; якщо публічне ім'я в розділеному профілі відповідає з тунелю, маршрут за замовчуванням занадто широкий. Ці два збої в браузері виглядають однаково, а в цьому виводі навпаки.
resolvectl status
resolvectl query host.corp.exampleСтежте й за повідомленим протоколом, бо відповідь із кешу або з файлу hosts може прийти без запитання до будь-якого вищестоящого джерела. Відповідь із кешу доводить, що ім'я колись розв'язалося, а не те, що поточна політика маршрутизує його правильно.
Тримайте маршрутизацію імен окремо від маршрутизації пакетів
Рішення резолвера не створює шляху. Обраний сервер усе ще потребує маршруту до своєї адреси, а повернена адреса все ще потребує маршруту до приватної мережі, тож правильна політика DNS може існувати поряд із з'єднанням, яке ніколи не відкривається. Коли ім'я розв'язується, а застосунок зазнає невдачі, огляньте адресу й маршрут замість того, щоб знову змінювати DNS. Розв'язання імен і доступність — це два питання з двома різними власниками.
Застосунки можуть повністю обійти системний резолвер через власне налаштування безпечного DNS або вбудований резолвер. Результат resolvectl описує системний шлях, і браузер, який його ігнорує, розходитиметься з кожним вашим тестом. Перевірте це налаштування, перш ніж робити висновок, що політика зламана.
Запишіть адресу, на яку розв'язалося ім'я, поряд із з'єднанням. Правильне ім'я, що вказує на неправильну адресу, — це проблема запису, а не маршрутизації.
Перевірте знову після зміни з'єднання
Перепідключення або зміна бездротової мережі заново будує стан з'єднання, і мережевий менеджер може перевстановити свої домени й сервери поверх усього, що задано вручну. Потім запитайте ті самі два імені й порівняйте із записаною базовою лінією. Якщо ручну правку зникло, виправлення належить до профілю з'єднання а не до команди оболонки. Саме запис до і після робить це видимим.
Діліться лише тими іменами й контекстом серверів, які потрібні звіту, бо внутрішні суфікси розкривають топологію. Документація systemd-resolved про маршрутизацію доменів охоплює правило найдовшого збігу й поведінку тильди, і одне прочитання запобігає більшості помилок у таблиці вище: маршрутизація запитів у systemd-resolved.