Неге ішкі хост атаулары 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-ті қайта анықтауды ұстамауы керек.
Тек бірінші сәтсіз қабатты түзетіңіз, содан кейін сол командаларды қайта орындаңыз. Бірден екі өзгеріс қайсысы маңызды болғанын айтуға мүмкіндік бермейді, ал келесі ақау тергеуді нөлден бастайды.