Prečo sa interné názvy hostiteľov vyriešia v dig, ale zlyhajú v curl na VPN
dig odpovedá, ale curl hlási, že nedokáže vyriešiť hostiteľa. Porovnajte obe vyhľadávacie reťaze a potom opravte nsswitch, DNS na prepojenie alebo nesprávnu vyhľadávaciu príponu.
Váš notebook je na VPN, dig service.internal.example odpovedá adresou 10.x a curl stále končí s Could not resolve host. Tunel nie je problém: preniesol požiadavku dig bez sťažností. Rozdiel je v tom, kto kladie otázku. dig pošle jednu požiadavku jednému serveru, ktorý určíte vy, kým curl prechádza vyhľadávacím reťazcom operačného systému, a ten reťazec má vlastné pravidlá o tom, ktorý server sa pýta.
Dve vyhľadania pre ten istý názov
dig je vlastný stub resolver. Prečíta /etc/resolv.conf, vyberie menný server, pošle jednu požiadavku A alebo AAAA a vypíše odpoveď. nsswitch úplne preskočí a nevie nič o stave na prepojení, ktorý systemd-resolved alebo NetworkManager držia mimo tohto súboru, a preto môže byť odpoveď dig správna a napriek tomu vám nič nepovie o tom, čo uvidí vaša aplikácia.
Aplikácie volajú getaddrinfo a getaddrinfo prechádza dlhší reťazec: poradie modulov nsswitch, potom modul, ktorý spracúva názov, a napokon resolver zostavený z aktuálnej konfigurácie prepojenia. Na stroji so systemd ide požiadavka na 127.0.0.53 a systemd-resolved vyberie nadradený server pre každé prepojenie podľa smerovacej domény priradenej rozhraniu tun.
Dva príkazy oddeľujú tieto vrstvy bez hádania:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent používa rovnakú cestu ako curl, takže zlyhanie getent vedľa fungujúceho dig lokalizuje chybu vo vyhľadávacej politike a nie v smerovaní paketov. resolvectl query vypíše aj rozhranie a nadradený server, ktorý odpoveď poskytol, čo ukazuje, či rozhodnutie vyhralo prepojenie tunela alebo fyzické prepojenie.
Prečítajte si resolver, ktorý aplikácia skutočne používa
/etc/resolv.conf sa generuje na väčšine pracovných plôch a klient VPN má tri spôsoby interakcie s ním: pridať menný server na začiatok, prepísať súbor alebo odovzdať svoje servery NetworkManageru a nechať démona ho prepísať. Iba tretí vzor zachováva DNS na prepojenie, pretože servery zostávajú priradené k rozhraniu namiesto toho, aby boli sploštené do jedného globálneho zoznamu.
V systémoch NetworkManager výsledok závisí od backendu v /etc/NetworkManager/NetworkManager.conf:
[main]
dns=systemd-resolvedS dns=default sa servery klienta zlúčia do resolv.conf v poradí, ktoré vyhrá, a súkromná požiadavka môže byť stále odoslaná verejnému resolveru. S backendom, ktorý rozumie prepojeniam, systemd-resolved alebo dnsmasq, zostanú servery tunela obmedzené na tunel a idú tam iba názvy zodpovedajúce jeho smerovacej doméne. Toto obmedzenie je to, čo split DNS znamená v praxi, a je to časť, ktorá najčastejšie chýba, keď klient tvrdí, že ho podporuje.
Prečítajte si stav, kým čokoľvek zmeníte:
resolvectl status
resolvectl dns tun0Chcete vidieť rozhranie tun uvedené so serverom DNS a smerovacou doménou pre súkromnú príponu, zobrazené ako ~internal.example. Žiadny server na prepojení znamená, že klient nič neposlal. Server bez domény znamená, že požiadavky idú buď všetky tam, alebo žiadna, podľa klienta, a ani jedno nie je split DNS.
Kde nsswitch ukončí vyhľadávanie príliš skoro
Bežný riadok pracovnej plochy vyzerá takto:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal spracúva multicast DNS a nárokuje si každý názov končiaci na .local. Služba Kubernetes ako api.infra.svc.cluster.local tiež končí na .local. Keď modul mDNS hlási NOTFOUND, akcia [NOTFOUND=return] ukončí celé vyhľadávanie namiesto pokračovania do modulu dns, takže názov sa nikdy neodošle resolveru VPN. dig obchádza súbor úplne, a práve preto sa oba nástroje nezhodujú.
To je najostrejší kontrast v tomto probléme a zúži sa na jedno slovo v konfiguračnom súbore, ktorý je starší ako vaša VPN. Zmena akcie na [NOTFOUND=continue] zachová mDNS pre tlačiarne a lokálne zariadenia, pričom DNS môže názov vidieť. Nahradenie riadku s hosts: files dns tiež funguje a je hrubšie: vynecháva rozlíšenie .local pre tlačiareň, ktorú skutočne používate.
Názvy, ktoré žijú presne v jednej sieti
Súkromné zóny sú autoritatívne presne na jednom mieste. Názov AWS ako ip-10-0-4-31.eu-west-1.compute.internal sa odpovedá cez resolver VPC daného regiónu, a to iba dovtedy, kým je váš koncový bod VPN v rovnakom regióne ako zdroj. Pripojte sa ku koncovému bodu vo Frankfurte, požiadajte o názov compute.internal z Írska a žiadne lokálne nastavenie nepomôže: zóna, ktorá drží záznam, odtiaľ nie je dostupná.
Vyhľadávacie domény vytvárajú zrkadlový obraz. Holé service sa doplní príponou, ktorú resolver považuje za platnú, a s prepojením VPN môže lokálna doména poraziť firemnú. Pýtajte sa s koncovou bodkou, aby ste odstránili hádanie, getent ahosts service.internal.example., a ak to funguje, kým krátky názov zlyháva, oprava je vyhľadávacia doména na tuneli, nie adresa servera.
Spravovaní klienti pridávajú tretiu vrstvu nad systémovým resolverom. Profil VPN vo Windows môže niesť vlastnú politiku rozlišovania názvov, pravidlá pre jednotlivé aplikácie a tabuľku NRPT, ktorá platí aj vtedy, keď je tunel vypnutý. Aplikácie s vlastnou vyrovnávacou pamäťou DNS, bežné v runtime .NET a Java, si držia zastarané zlyhanie dlho po oprave reťazca. Klienti Apple konfigurujú split DNS cez zodpovedajúce domény v nastaveniach DNS namiesto resolv.conf a Chromium alebo Firefox v režime zabezpečeného DNS môžu obísť systémový resolver pre verejné názvy. Referencia Microsoftu k rozlišovaniu názvov VPN opisuje stranu Windows tejto vrstvy politiky.
Rozhodnite, ktorú vrstvu opraviť
Postupujte od príznaku k vrstve namiesto skúšania opráv v poradí:
| 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 |
Dva riadky nesú väčšinu váhy. Časový limit je problém dosiahnuteľnosti: súkromný resolver neodpovedá cez tunel, preto skontrolujte trasu k jeho adrese a či je server DNS na prepojení ten, ktorý si myslíte. NXDOMAIN je problém autority: niečo odpovedalo a nepozná názov, čo ukazuje na zónu, región alebo resolver, ktorý požiadavku nikdy nemal dostať.
Posledný riadok je ten, ktorý ľudia vynechávajú, pretože obe polovice vyzerajú ako úspech. Krátky názov, ktorý sa rozlíši inak ako FQDN, je nesúlad prípony a opätovné pripojenie tunela nezmení, ktorú príponu klient odošle.
Zachyťte stav pred úpravou konfiguračného súboru, aby ste mohli povedať, či úprava niečo urobila:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtSpustite kontroly v tomto poradí a zastavte pri prvej, ktorá zlyhá. getent a resolvectl query sa musia zhodovať; ak getent zlyhá, kým dig odpovedá, zostaňte vo vyhľadávacom reťazci a nedotýkajte sa smerovania. resolvectl status musí zobraziť server DNS a smerovaciu doménu na rozhraní tun. nsswitch sa nesmie vrátiť skoro s NOTFOUND pre príponu, ktorú testujete. Názov musí byť autoritatívny v sieti, ku ktorej je pripojený váš koncový bod, testovaný s koncovou bodkou. Aplikácia nesmie držať vlastnú vyrovnávaciu pamäť ani prepísanie zabezpečeného DNS.
Opravte iba prvú zlyhávajúcu vrstvu a potom znova spustite tie isté príkazy. Dve zmeny naraz vám nedovolia povedať, ktorá bola dôležitá, a ďalšia porucha začína vyšetrovanie od nuly.