Защо записът ви в /etc/hosts не достига до DNS на VPN

Добавихте име в /etc/hosts, свързахте VPN и очаквахте записът да се появи за всички. Това не се случва и изненадата обикновено идва с втори симптом: името се разрешава на вашата машина и се проваля при колега, което изглежда като счупена DNS услуга на VPN, а всъщност файлът hosts прави точно това, за което е създаден. Файлът hosts е локална конфигурация за разрешаване на имена, а не актуализация на зона и нищо в нормална VPN връзка не го качва.

Hosts е локално заместване, а не актуализация на зона

Файлът е списък от съответствия, които библиотеките за имена проверяват преди или вместо да попитат DNS сървър. Ред като 10.40.0.20 build.corp.example променя това, което приложенията на тази една машина заключават. Той не създава запис, не пътува през тунела и DNS сървърът, към който сочи тунелът, няма представа, че съществува.

Ето защо отказът е асиметричен. Вашият клиент получава отговор от файла. Друг клиент пита DNS сървъра на VPN, който не връща нищо, и приложението съобщава, че името не съществува. И двете машини се държат правилно; само едната има заместване, което другата никога не е виждала.

Две команди, два различни компонента

Най-бързият начин да спрете спора е да направите разликата видима в две команди, и двете изпълнени на клиента със записа в hosts:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Първата пита собствения път за търсене на системата, който в типична glibc система чете локални файлове преди DNS. Втората изпраща DNS заявка директно до сървъра на този адрес и изобщо не проверява локални файлове. Когато първата върне вашия запис, а втората върне NXDOMAIN, вие сте доказали, че записът не съществува в DNS и че вашата машина отговаря от локално заместване.

Редът е конфигурируем и си струва да го проверите, преди да правите изводи за конкретна дистрибуция. Вижте реда hosts: във /etc/nsswitch.conf; hosts: files dns проверява файловете първи. Не копирайте този пример върху работеща конфигурация само за да смените реда, защото реалните системи често изброяват допълнителни източници и условни записи на услуги, които примерът не съдържа.

systemd-resolved замъглява теста

В система с systemd-resolved локалният stub също обслужва имена от базата данни на hosts. Затова заявката към 127.0.0.53 не е независим тест на отдалечения сървър, макар да изглежда като DNS заявка и да се държи като такава. Можете да потвърдите какво знае резолверът и кои сървъри би попитал с:

resolvectl query build.corp.example
resolvectl status

Изходът на status изброява DNS сървърите за всяка връзка и така разбирате дали VPN връзката изобщо е получила резолвер. Този въпрос е отделен от записа в hosts и е този, който си струва да зададете, когато частно име се проваля при всички потребители, а не при един.

Приложенията могат да добавят още един слой. Браузър със своя настройка за DNS-over-HTTPS, контейнер със своя конфигурация на резолвер или среда за изпълнение, която кешира търсения за целия живот на процеса, могат да отговарят различно от системата. Тествайте приложението, което ви интересува, вместо да предполагате, че една команда описва всяка програма на машината.

Какво всъщност споделя име през VPN

Ако частно име трябва да работи за всички, то се нуждае от собственик, до когото резолверът на всеки може да достигне. Чистият отговор е да публикувате записа в управлявана зона и да направите тази зона разрешима през предвидения DNS път на VPN. Тогава записът има един източник на истина, одиторска следа и жизнен цикъл и никой не трябва да помни кой лаптоп носи локално заместване.

Разпространението на файлове hosts е законна алтернатива и това е управление на крайни точки, а не услуга за имена. Ако го изберете, файлът трябва да бъде разгърнат, версиониран и премахнат от това, което управлява парка, и точно така трябва да бъде описан в дизайна. „VPN се занимава с това“ не е описание на този процес.

Динамичната DNS регистрация е трети механизъм, със свои разрешения, удостоверяване на актуализации и живот на записа. Тя не следва от запис в hosts и не следва от просто свързване на клиент, освен ако сървърът и клиентът не са били конфигурирани и двамата за това. Запис, който се появява сам, е сигнал, че някой е включил защитени актуализации и клиент, който се регистрира сам, и тази конфигурация принадлежи в дизайнерския запис, а не в нишка за отстраняване на проблеми. Ако никой не може да назове кой притежава тази настройка, третирайте автоматичния запис като непроверен и запазете управляваната зона като източник на истина.

Разрешеното име не е маршрут

Разрешаването на имена и достижимостта са отделни и остарялото локално съответствие е класическият начин да ги объркате. Запис в hosts, който сочи към адрес, който се е преместил, ще продължи да избира остарелия хост дълго след като DNS е коригиран, а симптомът изглежда като отказ на маршрутизиране при име, което се разрешава добре.

Затова, когато докладът е „името се разрешава, но услугата е недостъпна“, сравнете системното търсене с явна заявка към DNS сървъра на VPN, след което проверете адреса, който получихте, срещу този, който услугата всъщност използва. Справката за systemd-resolved документира локалните източници, които проверява, и това е картата, която ви трябва за това сравнение.

След това поправете заместването чрез неговия собственик. Премахването на ред от вашия собствен файл hosts не прави нищо за дванадесетте лаптопа, които са получили същия ред от скрипт за разгръщане, и това е версията на този проблем, която хората всъщност имат.