Niyə daxili host adları dig-də həll olunur, amma curl-də VPN-də uğursuz olur

Noutbukunuz VPN-dədir, dig service.internal.example 10.x ünvanı ilə cavab verir, curl isə hələ də Could not resolve host ilə çıxır. Tunel problem deyil: o, dig sorğusunu şikayətsiz daşıdı. Fərq sualı kimin verdiyindədir. dig sizin adlandırdığınız bir serverə bir sorğu göndərir, curl isə əməliyyat sisteminin axtarış zəncirindən keçir və bu zəncirin hansı serverdən soruşulacağına dair öz qaydaları var.

Eyni ad üçün iki axtarış

dig öz stub resolver-idir. O, /etc/resolv.conf faylını oxuyur, ad serveri seçir, bir A və ya AAAA sorğusu göndərir və cavabı çap edir. O, nsswitch-i tamamilə atlayır və systemd-resolved və ya NetworkManager-in həmin fayldan kənarda saxladığı link üzrə vəziyyət haqqında heç nə bilmir, buna görə də dig cavabı düzgün ola bilər və yenə də tətbiqinizin nə görəcəyi barədə heç nə deməyə bilər.

Tətbiqlər getaddrinfo-nu çağırır, getaddrinfo isə daha uzun zəncirdən keçir: nsswitch modullarının sırası, sonra adı emal edən modul və nəhayət cari link konfiqurasiyasından qurulan resolver. systemd maşınında sorğu 127.0.0.53-ə gedir və systemd-resolved tun interfeysinə bağlanmış marşrutlaşdırma domeninə əsasən hər link üçün yuxarı server seçir.

İki əmr bu təbəqələri təxmin etmədən ayırır:

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

getent curl ilə eyni yoldan istifadə edir, buna görə işləyən dig-in yanında getent xətası nasazlığı paket marşrutlaşdırmasında deyil, axtarış siyasətində lokallaşdırır. resolvectl query həmçinin cavabı verən interfeysi və yuxarı serveri çap edir, bu isə qərarı tunel linkinin yoxsa fiziki linkin qazandığını göstərir.

Tətbiqin həqiqətən istifadə etdiyi resolver-i oxuyun

/etc/resolv.conf əksər iş masalarında yaradılır və VPN klientinin onunla qarşılıqlı əlaqəsinin üç yolu var: ad serverini qabağa qoymaq, faylı üzərinə yazmaq və ya öz serverlərini NetworkManager-ə vermək və daemonun onu yenidən yazmasına icazə vermək. Yalnız üçüncü nümunə link üzrə DNS-i qoruyur, çünki serverlər bir qlobal siyahıya yastılanmaq əvəzinə interfeysə bağlı qalır.

NetworkManager sistemlərində nəticə /etc/NetworkManager/NetworkManager.conf-dakı backend-dən asılıdır:

[main]
dns=systemd-resolved

dns=default ilə klientin serverləri qalib gələn sıra ilə resolv.conf-a birləşdirilir və özəl sorğu hələ də ictimai resolver-ə gedə bilər. Linkləri anlayan backend ilə, systemd-resolved və ya dnsmasq, tunelin serverləri tunellə məhdudlaşır və oraya yalnız onun marşrutlaşdırma domeninə uyğun adlar gedir. Bu məhdudlaşdırma split DNS-in praktikada ifadə etdiyi şeydir və klient onu dəstəklədiyini iddia edəndə ən çox çatışmayan hissədir.

Bir şeyi dəyişməzdən əvvəl vəziyyəti oxuyun:

resolvectl status
resolvectl dns tun0

Siz tun interfeysinin DNS serveri və özəl suffiks üçün marşrutlaşdırma domeni ilə siyahıda olmasını, ~internal.example kimi göstərilməsini istəyirsiniz. Linkdə serverin olmaması klientin heç nə göndərmədiyini bildirir. Domeni olmayan server sorğuların ya hamısının oraya getdiyini, ya da heç birinin getmədiyini bildirir, klientdən asılı olaraq, və heç biri split DNS deyil.

nsswitch-in axtarışı çox erkən bitirdiyi yer

Standart iş masası sətri belə görünür:

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

mdns4_minimal multicast DNS ilə məşğul olur və .local ilə bitən hər ada iddia edir. api.infra.svc.cluster.local kimi Kubernetes xidməti də .local ilə bitir. mDNS modulu NOTFOUND bildirdikdə, [NOTFOUND=return] əməliyyatı dns moduluna keçmək əvəzinə bütün axtarışı bitirir, buna görə ad heç vaxt VPN resolver-inə göndərilmir. dig faylı tamamilə yan keçir və məhz buna görə iki alət razılaşmır.

Bu, bu problemdə ən kəskin ziddiyyətdir və VPN-inizdən köhnə konfiqurasiya faylındakı bir sözə qədər azalır. Əməliyyatı [NOTFOUND=continue]-ə dəyişmək printerlər və yerli cihazlar üçün mDNS-i saxlayır, DNS isə adı görə bilir. Sətri hosts: files dns ilə əvəz etmək də işləyir və daha kobuddur: həqiqətən istifadə etdiyiniz printer üçün .local həllini ləğv edir.

Dəqiq bir şəbəkədə yaşayan adlar

Özəl zonalar dəqiq bir yerdə səlahiyyətlidir. ip-10-0-4-31.eu-west-1.compute.internal kimi AWS adı həmin regionun VPC resolver-i vasitəsilə cavablandırılır və yalnız VPN son nöqtəniz resursla eyni regionda olduqca. Frankfurt son nöqtəsinə qoşulun, İrlandiyadan compute.internal adı soruşun və heç bir yerli parametr kömək etməyəcək: qeydi saxlayan zona oradan əlçatmazdır.

Axtarış domenləri güzgü təsvirini yaradır. Çılpaq service resolver-in uyğun saydığı suffiklə tamamlanır və VPN linki ilə yerli domen korporativ domeni üstələyə bilər. Təxmini aradan qaldırmaq üçün sonunda nöqtə ilə soruşun, getent ahosts service.internal.example., və bu işləyib qısa ad uğursuz olursa, düzəliş tuneldəki axtarış domenidir, server ünvanı deyil.

İdarə olunan klientlər sistem resolver-inin üstünə üçüncü təbəqə əlavə edir. Windows VPN profili öz ad həlli siyasətini, tətbiq üzrə qaydaları və tunel söndürüldükdə belə qüvvədə olan NRPT cədvəlini daşıya bilər. Öz DNS keşi olan tətbiqlər, .NET və Java mühitlərində geniş yayılmış, zəncir düzəldildikdən sonra da köhnəlmiş uğursuzluğu uzun müddət saxlayır. Apple klientləri split DNS-i DNS parametrlərindəki uyğunluq domenləri ilə konfiqurasiya edir, resolv.conf ilə deyil, Chromium və ya Firefox təhlükəsiz DNS rejimində ictimai adlar üçün sistem resolver-ini yan keçə bilər. Microsoft-un VPN ad həlli arayışı bu siyasət təbəqəsinin Windows tərəfini təsvir edir.

Hansı təbəqənin düzəldiləcəyinə qərar verin

Düzəlişləri sıra ilə sınamaq əvəzinə simptomdan təbəqəyə doğru işləyin:

İki sətir əsas yükü daşıyır. Taym-aut əlçatanlıq problemidir: özəl resolver tunel vasitəsilə cavab vermir, buna görə onun ünvanına marşrutu və linkdəki DNS serverin sizin düşündüyünüz server olub-olmadığını yoxlayın. NXDOMAIN səlahiyyət problemidir: nəsə cavab verdi və adı bilmir, bu isə zonaya, regiona və ya sorğunu heç vaxt almamalı olan resolver-ə işarə edir.

Son sətir insanların qaçırdığı sətirdir, çünki hər iki yarı uğur kimi görünür. FQDN-dən fərqli həll olunan qısa ad suffiks uyğunsuzluğudur və tuneli yenidən qoşmaq klientin hansı suffiksi göndərdiyini dəyişməyəcək.

Konfiqurasiya faylını redaktə etməzdən əvvəl vəziyyəti qeyd edin ki, redaktənin nəyisə dəyişib-dəyişmədiyini deyə biləsiniz:

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

Yoxlamaları bu sıra ilə yerinə yetirin və ilk uğursuz olanda dayanın. getent və resolvectl query uyğun olmalıdır; getent uğursuz olub dig cavab verirsə, axtarış zəncirində qalın və marşrutlaşdırmaya toxunmayın. resolvectl status tun interfeysində DNS serveri və marşrutlaşdırma domeni göstərməlidir. nsswitch yoxlanılan suffiks üçün NOTFOUND ilə erkən qayıtmamalıdır. Ad son nöqtənizin qoşulduğu şəbəkədə səlahiyyətli olmalıdır, sonunda nöqtə ilə yoxlanılmış. Tətbiq öz keşini və ya təhlükəsiz DNS ləğvini saxlamamalıdır.

Yalnız ilk uğursuz təbəqəni düzəldin, sonra eyni əmrləri yenidən icra edin. Eyni vaxtda iki dəyişiklik hansının vacib olduğunu deməyə imkan vermir və növbəti nasazlıq araşdırmanı sıfırdan başlayır.