Зошто внатрешните имиња на домаќини се разрешуваат во dig, но не успеваат во curl на VPN

Вашиот преносен компјутер е на VPN, dig service.internal.example одговара со адреса 10.x, а curl сепак завршува со Could not resolve host. Тунелот не е проблемот: ја пренесе dig-барањето без поплаки. Разликата е кој го поставува прашањето. dig испраќа едно барање до еден сервер што вие го наведувате, додека curl поминува низ синџирот за пребарување на оперативниот систем, а тој синџир има свои правила за тоа кој сервер се прашува.

Две пребарувања за истото име

dig е сопствен stub resolver. Го чита /etc/resolv.conf, избира сервер за имиња, испраќа едно A или AAAA барање и го печати одговорот. Целосно го прескокнува nsswitch и не знае ништо за состојбата по врска што systemd-resolved или NetworkManager ја држат надвор од таа датотека, и затоа dig-одговорот може да биде точен, а сепак да не ви каже ништо за тоа што ќе го види вашата апликација.

Апликациите го повикуваат getaddrinfo, а getaddrinfo поминува низ подолг синџир: редоследот на модулите во nsswitch, потоа модулот што го обработува името и накрај resolver-от изграден од тековната конфигурација на врската. На systemd машина барањето оди на 127.0.0.53 и systemd-resolved избира нагорен сервер по врска врз основа на доменот за насочување прикачен на интерфејсот tun.

Две наредби ги одвојуваат тие слоеви без погодување:

getent ahosts service.internal.example
resolvectl query service.internal.example

getent го користи истиот пат како curl, па getent-грешка покрај исправен dig го лоцира дефектот во политиката за пребарување, а не во насочувањето на пакетите. resolvectl query го печати и интерфејсот и нагорниот сервер што го дал одговорот, што покажува дали врската на тунелот или физичката врска ја добила одлуката.

Прочитајте го resolver-от што апликацијата навистина го користи

/etc/resolv.conf се генерира на повеќето работни површини, а VPN-клиентот има три начини да комуницира со него: да додаде сервер за имиња напред, да ја препише датотеката или да ги предаде своите сервери на NetworkManager и да го остави демонот да ја препише. Само третиот образец го зачувува DNS-от по врска, бидејќи серверите остануваат прикачени на интерфејс наместо да бидат сплескани во една глобална листа.

На NetworkManager системи исходот зависи од задниот дел во /etc/NetworkManager/NetworkManager.conf:

[main]
dns=systemd-resolved

Со dns=default серверите на клиентот се спојуваат во resolv.conf по редоследот што победува, а приватното барање сепак може да биде испратено до јавниот resolver. Со заден дел што ги разбира врските, systemd-resolved или dnsmasq, серверите на тунелот остануваат ограничени на тунелот и таму одат само имињата што одговараат на неговиот домен за насочување. Тоа ограничување е она што split DNS го значи во практика, и тоа е делот што најчесто недостасува кога клиент тврди дека го поддржува.

Прочитајте ја состојбата пред да промените нешто:

resolvectl status
resolvectl dns tun0

Сакате да го видите интерфејсот tun наведен со DNS-сервер и домен за насочување за приватниот суфикс, прикажани како ~internal.example. Ниту еден сервер на врската значи дека клиентот не испратил ништо. Сервер без домен значи дека барањата или сите одат таму или ниту едно, зависно од клиентот, и ниту едното не е split DNS.

Каде nsswitch го прекинува пребарувањето прерано

Стандардна линија на работна површина изгледа вака:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

mdns4_minimal се занимава со multicast DNS и полага право на секое име што завршува на .local. Kubernetes-услуга како api.infra.svc.cluster.local исто така завршува на .local. Кога mDNS-модулот пријавува NOTFOUND, дејството [NOTFOUND=return] го завршува целото пребарување наместо да продолжи кон dns-модулот, па името никогаш не се испраќа до VPN-resolver-от. dig целосно ја заобиколува датотеката, и токму затоа двата алата не се согласуваат.

Тоа е најостриот контраст во овој проблем и се сведува на еден збор во конфигурациска датотека постара од вашиот VPN. Промената на дејството во [NOTFOUND=continue] го задржува mDNS за печатачи и локални уреди додека DNS може да го види името. Замената на линијата со hosts: files dns исто така работи и е погруба: го отфрла разрешувањето на .local за печатачот што навистина го користите.

Имиња што живеат во точно една мрежа

Приватните зони се авторитативни на точно едно место. AWS-име како ip-10-0-4-31.eu-west-1.compute.internal се одговара преку VPC-resolver-от на тој регион, и само додека вашата VPN-крајна точка е во истиот регион како ресурсот. Поврзете се со крајна точка во Франкфурт, побарајте compute.internal-име од Ирска, и никаква локална поставка нема да помогне: зоната што го држи записот не е достапна од таму.

Домените за пребарување ја даваат огледалната слика. Голо service се дополнува со суфиксот што resolver-от го смета за применлив, а со VPN-врска локалниот домен може да го победи корпоративниот. Побарајте со завршна точка за да го отстраните погодувањето, getent ahosts service.internal.example., и ако тоа работи додека краткото име не успева, исправката е доменот за пребарување на тунелот, а не адресата на серверот.

Управуваните клиенти додаваат трет слој над системскиот resolver. Windows VPN-профил може да носи сопствена политика за разрешување имиња, правила по апликација и NRPT-табела што важи и кога тунелот е исклучен. Апликациите со сопствен DNS-кеш, вообичаени во .NET и Java-окружувања, држат застарен неуспех долго откако синџирот е поправен. Apple-клиентите конфигурираат split DNS преку домени за совпаѓање во DNS-поставките наместо преку resolv.conf, а Chromium или Firefox во режим на безбеден DNS можат да го заобиколат системскиот resolver за јавни имиња. Референцата на Microsoft за разрешување VPN-имиња ја опишува Windows-страната на тој слој политика.

Одлучете кој слој да го поправите

Работете од симптомот кон слојот наместо да ги пробувате исправките по ред:

Два реда го носат поголемиот дел од тежината. Временското ограничување е проблем на достапност: приватниот resolver не одговара преку тунелот, па проверете ја рутата до неговата адреса и дали DNS-серверот на врската е тој што мислите. NXDOMAIN е проблем на авторитет: нешто одговорило и не го знае името, што упатува на зоната, регионот или resolver што никогаш не требало да го прими барањето.

Последниот ред е оној што луѓето го пропуштаат бидејќи двете половини изгледаат како успех. Кратко име што се разрешува поинаку од FQDN е несовпаѓање на суфиксот, а повторното поврзување на тунелот нема да го промени суфиксот што клиентот го испраќа.

Забележете ја состојбата пред да уредите конфигурациска датотека, за да можете да кажете дали уредувањето направило нешто:

resolvectl status > before.txt
getent ahosts service.internal.example >> before.txt

Извршете ги проверките по овој ред и застанете на првата што не успева. getent и resolvectl query мора да се совпаѓаат; ако getent не успева додека dig одговара, останете во синџирот за пребарување и не го чепкајте насочувањето. resolvectl status мора да покаже DNS-сервер и домен за насочување на интерфејсот tun. nsswitch не смее прерано да се врати со NOTFOUND за суфиксот што го тестирате. Името мора да биде авторитативно во мрежата на која е приклучена вашата крајна точка, тестирано со завршна точка. Апликацијата не смее да држи сопствен кеш или прегазување на безбедниот DNS.

Поправете го само првиот слој што не успева, а потоа повторно извршете ги истите наредби. Две промени одеднаш ве оставаат без можност да кажете која била важна, а следниот прекин ја започнува истрагата од нула.