Звіт про DNS через VPN: що включити, щоб його можна було відтворити

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

Категорія імені, а не вирок

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

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

Зафіксуйте шлях до резолвера

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

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

Укажіть контрольоване порівняння

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

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

Приховайте простір імен, збережіть зв’язки

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

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