Zašto se interna imena hostova razrješavaju u dig, ali ne uspijevaju u curl na VPN
dig odgovara, ali curl javlja da ne može razriješiti host. Usporedite oba lanca pretraživanja, a zatim popravite nsswitch, DNS po vezi ili pogrešan sufiks pretraživanja.
Vaš prijenosnik je na VPN-u, dig service.internal.example odgovara adresom 10.x, a curl ipak završava s Could not resolve host. Tunel nije problem: prenio je dig upit bez prigovora. Razlika je u tome tko postavlja pitanje. dig šalje jedan upit jednom poslužitelju koji vi navedete, dok curl prolazi kroz lanac pretraživanja operacijskog sustava, a taj lanac ima vlastita pravila o tome koji se poslužitelj pita.
Dva pretraživanja za isto ime
dig je vlastiti stub resolver. Čita /etc/resolv.conf, odabire imenski poslužitelj, šalje jedan A ili AAAA upit i ispisuje odgovor. Potpuno preskače nsswitch i ne zna ništa o stanju po vezi koje systemd-resolved ili NetworkManager drže izvan te datoteke, i zato dig odgovor može biti točan i ipak vam ne reći ništa o tome što će vidjeti vaša aplikacija.
Aplikacije pozivaju getaddrinfo, a getaddrinfo prolazi duži lanac: redoslijed modula nsswitch, zatim modul koji obrađuje ime, a zatim resolver izgrađen iz trenutne konfiguracije veze. Na systemd stroju upit ide na 127.0.0.53 i systemd-resolved odabire nadređeni poslužitelj po vezi na temelju domene usmjeravanja pridružene sučelju tun.
Dvije naredbe razdvajaju te slojeve bez nagađanja:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent koristi isti put kao curl, pa getent pogreška pokraj ispravnog dig-a locira kvar u politici pretraživanja, a ne u usmjeravanju paketa. resolvectl query također ispisuje sučelje i nadređeni poslužitelj koji je dao odgovor, što pokazuje je li odluku dobila veza tunela ili fizička veza.
Pročitajte resolver koji aplikacija doista koristi
/etc/resolv.conf generira se na većini radnih površina, a VPN klijent ima tri načina interakcije s njim: dodati imenski poslužitelj na početak, prepisati datoteku ili predati svoje poslužitelje NetworkManageru i pustiti daemon da ju prepiše. Samo treći uzorak čuva DNS po vezi, jer poslužitelji ostaju vezani uz sučelje umjesto da budu spljošteni u jedan globalni popis.
Na NetworkManager sustavima ishod ovisi o pozadinskom dijelu u /etc/NetworkManager/NetworkManager.conf:
[main]
dns=systemd-resolvedS dns=default poslužitelji klijenta spajaju se u resolv.conf redoslijedom koji pobijedi, a privatni upit ipak može otići javnom resolveru. S pozadinskim dijelom koji razumije veze, systemd-resolved ili dnsmasq, poslužitelji tunela ostaju ograničeni na tunel i tamo idu samo imena koja odgovaraju njegovoj domeni usmjeravanja. To ograničenje je ono što split DNS znači u praksi, i to je dio koji najčešće nedostaje kada klijent tvrdi da ga podržava.
Pročitajte stanje prije nego što išta promijenite:
resolvectl status
resolvectl dns tun0Želite vidjeti sučelje tun navedeno s DNS poslužiteljem i domenom usmjeravanja za privatni sufiks, prikazano kao ~internal.example. Nema poslužitelja na vezi znači da klijent nije poslao ništa. Poslužitelj bez domene znači da upiti idu ili svi tamo ili nijedan, ovisno o klijentu, i ništa od toga nije split DNS.
Gdje nsswitch prekida pretraživanje prerano
Uobičajeni redak radne površine izgleda ovako:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal obrađuje multicast DNS i polaže pravo na svako ime koje završava na .local. Kubernetes usluga poput api.infra.svc.cluster.local također završava na .local. Kada mDNS modul prijavi NOTFOUND, akcija [NOTFOUND=return] završava cijelo pretraživanje umjesto da nastavi na dns modul, pa ime nikad ne ode VPN resolveru. dig potpuno zaobilazi datoteku, i upravo zato se dva alata ne slažu.
To je najstroži kontrast u ovom problemu i svodi se na jednu riječ u konfiguracijskoj datoteci starijoj od vašeg VPN-a. Promjena akcije u [NOTFOUND=continue] čuva mDNS za pisače i lokalne uređaje dok DNS može vidjeti ime. Zamjena retka s hosts: files dns također radi i grublja je: uklanja razrješavanje .local za pisač koji doista koristite.
Imena koja žive u točno jednoj mreži
Privatne zone autoritativne su na točno jednom mjestu. AWS ime poput ip-10-0-4-31.eu-west-1.compute.internal odgovara se preko VPC resolvera te regije, i to samo dok je vaša VPN krajnja točka u istoj regiji kao resurs. Spojite se na krajnju točku u Frankfurtu, upitajte compute.internal ime iz Irske, i nikakva lokalna postavka neće pomoći: zona koja drži zapis odande nije dostupna.
Domene pretraživanja daju zrcalnu sliku. Golo service dopunjuje se sufiksom koji resolver smatra primjenjivim, a s VPN vezom lokalna domena može pobijediti korporativnu. Upitajte sa završnom točkom da uklonite nagađanje, getent ahosts service.internal.example., i ako to radi dok kratko ime ne uspijeva, ispravak je domena pretraživanja na tunelu, a ne adresa poslužitelja.
Upravljani klijenti dodaju treći sloj iznad sistemskog resolvera. Windows VPN profil može nositi vlastitu politiku razrješavanja imena, pravila po aplikaciji i NRPT tablicu koja vrijedi i kad je tunel isključen. Aplikacije s vlastitim DNS predmemorijom, uobičajene u .NET i Java runtimeima, drže zastarjeli kvar dugo nakon što je lanac popravljen. Apple klijenti konfiguriraju split DNS preko domena podudaranja u DNS postavkama umjesto preko resolv.conf, a Chromium ili Firefox u načinu sigurnog DNS-a mogu zaobići sistemski resolver za javna imena. Microsoftova referenca o razrješavanju VPN imena opisuje Windows stranu tog sloja politike.
Odlučite koji sloj popraviti
Radite od simptoma prema sloju umjesto da isprobavate ispravke redom:
| 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 retka nose većinu težine. Vremensko ograničenje je problem dostupnosti: privatni resolver ne odgovara kroz tunel, pa provjerite rutu do njegove adrese i je li DNS poslužitelj na vezi onaj koji mislite. NXDOMAIN je problem autoriteta: nešto je odgovorilo i ne zna ime, što upućuje na zonu, regiju ili resolver koji nikada nije trebao primiti upit.
Posljednji redak je onaj koji ljudi propuštaju jer obje polovice izgledaju kao uspjeh. Kratko ime koje se razrješava drukčije od FQDN-a nesklad je sufiksa, a ponovno spajanje tunela neće promijeniti koji sufiks klijent šalje.
Zabilježite stanje prije uređivanja konfiguracijske datoteke, da biste mogli reći je li uređivanje nešto promijenilo:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtPokrenite provjere ovim redom i zaustavite se na prvoj koja ne uspije. getent i resolvectl query moraju se podudarati; ako getent ne uspije dok dig odgovara, ostanite u lancu pretraživanja i ne dirajte usmjeravanje. resolvectl status mora pokazati DNS poslužitelj i domenu usmjeravanja na sučelju tun. nsswitch se ne smije prerano vratiti s NOTFOUND za sufiks koji testirate. Ime mora biti autoritativno u mreži na koju je priključena vaša krajnja točka, testirano sa završnom točkom. Aplikacija ne smije držati vlastitu predmemoriju ni nadjačavanje sigurnog DNS-a.
Popravite samo prvi sloj koji ne uspijeva, a zatim ponovno pokrenite iste naredbe. Dvije promjene odjednom ostavljaju vas bez mogućnosti da kažete koja je bila važna, a sljedeći prekid započinje istragu od nule.