Зашто се интерна имена хостова разрешавају у dig, али не успевају у curl на VPN
dig одговара, али curl пријављује да не може да разреши хост. Упоредите оба ланца претраге, а затим поправите nsswitch, DNS по вези или погрешан суфикс претраге.
Ваш лаптоп је на 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.examplegetent користи исти пут као 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 myhostnamemdns4_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 страну тог слоја политике.
Одлучите који слој поправити
Радите од симптома ка слоју уместо да испробавате исправке редом:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
Два реда носе већину тежине. Временско ограничење је проблем доступности: приватни 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-а.
Поправите само први слој који не успева, а затим поново покрените исте наредбе. Две промене одједном остављају вас без могућности да кажете која је била важна, а следећи прекид започиње истрагу од нуле.