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

Додадовте име во /etc/hosts, се поврзавте со VPN и очекувавте записот да се појави кај сите. Тоа не се случува, а изненадувањето обично доаѓа со втор симптом: името се разрешува на вашата машина и не успева кај колега, што изгледа како расипана VPN DNS услуга, а всушност датотеката 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 барање и се однесува така. Можете да потврдите што знае resolver-от и кои сервери би ги прашал со:

resolvectl query build.corp.example
resolvectl status

Излезот на status ги наведува DNS серверите по врска, и така дознавате дали VPN врската воопшто добила resolver. Тоа прашање е одделно од записот hosts и е она што вреди да се постави кога приватно име не успева за сите корисници, а не за еден.

Апликациите можат да додадат уште еден слој. Прелистувач со сопствено DNS-over-HTTPS поставување, контејнер со сопствена конфигурација на resolver или извршна околина што ги кешира пребарувањата за целиот животен век на процесот можат секој да одговори поинаку од системот. Тестирајте ја апликацијата што ви е важна наместо да претпоставувате дека една команда го опишува секој програм на машината.

Што навистина дели име низ VPN

Ако приватно име треба да работи за сите, му треба сопственик до кој resolver-от на сите може да стигне. Чистиот одговор е да го објавите записот во управувана зона и да ја направите таа зона разрешлива преку предвидениот DNS пат на VPN. Тогаш записот има еден извор на вистина, аудиторска трага и животен циклус, и никој не мора да памети кој преносен компјутер носи локално препишување.

Дистрибуирањето на датотеки hosts е легитимна алтернатива и тоа е управување со крајни точки, а не услуга за имиња. Ако го изберете, датотеката мора да биде распоредена, верзионирана и отстранета од она што управува со флотата, и така треба да се опише во дизајнот. „VPN се грижи за тоа“ не е опис на тој процес.

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

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

Разрешувањето имиња и достапноста се одделни, а застарено локално мапирање е класичен начин да се збунат. Запис hosts што покажува на адреса што се преместила ќе продолжува да го избира застарениот домаќин долго откако DNS ќе се поправи, и симптомот изгледа како рутирачка грешка на име што добро се разрешува.

Затоа, кога извештајот е „името се разрешува, но услугата не е достапна“, споредете го системското пребарување со експлицитно барање до DNS серверот на VPN, потоа проверете ја добиената адреса наспроти онаа што услугата навистина ја користи. референцата за systemd-resolved ги документира локалните извори што ги консултира, и тоа е картата што ви треба за таа споредба.

Потоа поправете го препишувањето преку неговиот сопственик. Отстранувањето на линија од вашата сопствена датотека hosts не прави ништо за дванаесетте преносни компјутери што ја добија истата линија од скрипта за распоредување, и тоа е верзијата на овој проблем што луѓето навистина ја имаат.