Эмне үчүн ички хост аттары 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 сыяктуу эле жолду колдонот, ошондуктан иштеп жаткан dig жанындагы getent катасы жараанды пакет маршруттоосунда эмес, издөө саясатында деп аныктайт. resolvectl query ошондой эле жооп берген интерфейс менен жогорку серверди басып чыгарат, бул чечимди туннель байланышы же физикалык байланыш жеңгенин көрсөтөт.
Колдонмо чындап колдонгон resolver’ди окуңуз
/etc/resolv.conf көпчүлүк жумуш үстөлдөрүндө жаралат, ал эми VPN кардарынын аны менен аракеттенүүнүн үч жолу бар: ат серверин алдыга коюу, файлды кайра жазуу же өз серверлерин NetworkManager’ге берип, демонго аны кайра жаздыруу. Үчүнчү үлгү гана байланыш боюнча DNS’ти сактайт, анткени серверлер бир глобалдык тизмеге жайылгандын ордуна интерфейске байланган бойдон калат.
NetworkManager системаларында жыйынтык /etc/NetworkManager/NetworkManager.conf ичиндеги backend’ге байланыштуу:
[main]
dns=systemd-resolveddns=default менен кардардын серверлери resolv.conf ичине жеңүүчү тартипте кошулат, ал эми жеке суроо дагы эле коомдук resolver’ге кетиши мүмкүн. Байланыштарды түшүнгөн backend менен, 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 менен бүткөн ар кандай атка талап кылат. api.infra.svc.cluster.local сыяктуу Kubernetes кызматы да .local менен бүтөт. mDNS модулу NOTFOUND деп кабарлаганда, [NOTFOUND=return] аракети dns модулуна өтүүнүн ордуна бүтүндөй издөөнү бүтүрөт, ошондуктан ат VPN resolver’ине эч качан жөнөтүлбөйт. dig файлды толугу менен айланып өтөт, жана дал ушул себептен эки курал макул болушпайт.
Бул көйгөйдөгү эң курч карама-каршылык, жана ал VPN’иңизден эски конфигурация файлындагы бир сөзгө келет. Аракетти [NOTFOUND=continue]’ге өзгөртсөңүз, mDNS принтерлер жана жергиликтүү түзмөктөр үчүн сакталат, ал эми DNS атты көрө алат. Сапты hosts: files dns менен алмаштыруу да иштейт жана одоно: ал чындап колдонгон принтериңиз үчүн .local чечилишин алып салат.
Так бир тармакта жашаган аттар
Жеке зоналар так бир жерде авторитеттүү. ip-10-0-4-31.eu-west-1.compute.internal сыяктуу AWS аты ошол аймактын 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 tun интерфейсинде DNS сервери менен маршруттоо доменин көрсөтүшү керек. nsswitch текшерилип жаткан суффикс үчүн NOTFOUND менен эрте кайтпашы керек. Ат акыркы чекитиңиз туташкан тармакта авторитеттүү болушу керек, аягында чекит менен текшерилген. Колдонмо өз кэшин же коопсуз DNS’ти кайра аныктоону кармабашы керек.
Бир гана биринчи ийгиликсиз катмарды оңдоңуз, анан ошол эле буйруктарды кайра аткарыңыз. Бир эле учурда эки өзгөртүү кайсынысы маанилүү болгонун айтууга мүмкүндүк бербейт, ал эми кийинки бузулуу тергөөнү нөлдөн баштайт.