Розділений DNS і VPN: правила доменів — не IP-маршрути

Ваш ноутбук розв'язує intranet.corp через тунель, а gitlab.com продовжує йти до резолвера провайдера, і це та схема, яка працює як задумано. Її створили два окремі рішення: правило зіставлення імен вибрало резолвер, а маршрут повернув відповідь. Зламайте будь-яке з них, і браузер покаже збій, який зовні виглядає однаково. Більшість звітів про розділений DNS описують другий збій, цитуючи при цьому докази про перший.

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

Два рішення, приховані в одному запиті

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

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

Як кожна платформа виражає те саме правило імен

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

Домен збігу або маршрутизації — це перевірка суфікса, тому intranet.corp покриває git.intranet.corp і не покриває corp.intranet, і перевернути це — найпоширеніша помилка в усій конфігурації. Windows несе зіставлення як політику розв'язання імен, прив'язану до профілю, зі своїм порядком пріоритету щодо будь-якого списку суфіксів, який уже мав інтерфейс. Платформи Apple прив'язують збіжні домени до об'єкта налаштувань DNS мережевого розширення, і система застосовує їх для кожного обмеженого резолвера. Жодна з цих форм не є маршрутом, і жодна не може зробити недосяжну адресу досяжною. Довідка політика розв'язання імен Windows перелічує назви полів і правила пріоритету для цієї платформи, і вони не ті, що використовують документи Apple або systemd.

Правильній відповіді все ще потрібен шлях

Відповідь резолвера — це лише адреса, і застосунок усе ще має до неї дістатися. Схема розділеного тунелю часто проштовхує 10.20.0.0/16 і утримує маршрут за замовчуванням, тому внутрішнє ім'я розв'язується, а з'єднання потім зависає. Зворотний випадок так само частий: маршрут є, публічний резолвер відповідає на приватне ім'я NXDOMAIN, і збій записується як проблема маршрутизації. Перевірка шляху першою змушує вас дивитися на маршрути для імені, яке ніколи б не розв'язалося.

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

Перевірка імен і шляхів у фіксованому порядку

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

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Клієнт Windows ставить ті самі два питання іншими командлетами. Другий повідомляє інтерфейс, який система справді використала б:

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

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

Де порівняння зазвичай іде не так

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

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

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