Firwat sech intern Hostnimm am dig opléisen, awer am curl op enger VPN scheiteren

Däi Laptop ass op der VPN, dig service.internal.example äntwert mat enger 10.x-Adress, an curl geet nach ëmmer mat Could not resolve host eraus. Den Tunnel ass net de Problem: hien huet d’Dig-Ufro ouni Beschwéier befërdert. Wat sech ënnerscheet, ass wien d’Fro stellt. dig schéckt eng Ufro un een Server, deen s du nenns, wärend curl duerch d’Opsschlossketten vum Betribssystem geet, an déi Kette huet hir eege Reegelen, wéi ee Server gefrot gëtt.

Zwee Opléisunge fir deen een Numm

dig ass en eege Stub-Resolver. Et liest /etc/resolv.conf, wielt en Nimmserver, schéckt eng eenzeg A- oder AAAA-Ufro a dréckt d’Äntwert aus. Et iwwerspréngt nsswitch komplett a weess näischt vum Per-Link-Zoustand, deen systemd-resolved oder NetworkManager baussen där Datei hält, an dofir kann eng dig-Äntwert korrekt sinn an dir trotzdem näischt soen iwwer dat, wat deng Applikatioun wäert gesinn.

Applikatioune ruffen getaddrinfo op, an getaddrinfo geet eng méi laang Kette of: d’Moduluerdnung vun nsswitch, duerno de Modul, deen den Numm behandelt, an da de Resolver, deen aus der aktueller Link-Konfiguratioun opgebaut gëtt. Op enger systemd-Maschinn geet d’Ufro op 127.0.0.53 an systemd-resolved wielt een Upstream-Server pro Link op Basis vum Routing-Domän, deen un d’tun-Interface gebonnen ass.

Zwee Kommandoe trennen déi Schichten ouni ze roden:

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

getent benotzt deeselwechte Wee wéi curl, also lokaliséiert e getent-Fehler nieft engem funktionéierende dig de Fehler an der Opsschloss-Politik an net am Paket-Routing. resolvectl query dréckt och d’Interface an den Upstream aus, deen d’Äntwert geliwwert huet, wat weist, ob de Tunnel-Link oder de physesche Link d’Entscheedung gewonnen huet.

Lies de Resolver, deen d’Applikatioun tatsächlech benotzt

/etc/resolv.conf gëtt op de meeschten Desktops generéiert, an e VPN-Client huet dräi Méiglechkeeten, domat ëmzegoen: en Nimmserver virun ze setzen, d’Datei z’iwwerschreiwen oder seng Serveren un NetworkManager ze ginn a den Daemon se nei schreiwen ze loossen. Nëmmen dat drëtt Muster behält DNS pro Link, well d’Serveren un eng Interface gebonne bleiwen, amplaz an eng global Lëscht flaach gemaach ze ginn.

Op NetworkManager-Systemer hänkt d’Resultat vum Backend an /etc/NetworkManager/NetworkManager.conf of:

[main]
dns=systemd-resolved

Mat dns=default ginn d’Serveren vum Client a resolv.conf fusionéiert an där Uerdnung, déi gewënnt, an eng privat Ufro kann nach ëmmer un den ëffentleche Resolver goen. Mat engem Backend, deen Links versteet, systemd-resolved oder dnsmasq, bleiwen d’Serveren vum Tunnel op den Tunnel begrenzt, an nëmmen Nimm, déi zum Routing-Domän passen, ginn dohinner. Déi Begrenzung ass dat, wat Split DNS an der Praxis bedeit, an dat ass dat Stéck, dat am dacksten feelt, wann e Client behaapt, et z’ënnerstëtzen.

Lies den Zoustand, ier s eppes änderst:

resolvectl status
resolvectl dns tun0

Du wëlls d’tun-Interface opgelëscht gesinn mat engem DNS-Server an engem Routing-Domän fir de privaten Suffix, ugewise wéi ~internal.example. Kee Server um Link bedeit, datt de Client näischt geschéckt huet. E Server ouni Domän bedeit, datt Opsschlëss entweder all dohinner ginn oder guer net, jee no Client, an keen vun deenen zwee ass Split DNS.

Wou nsswitch d’Opsschloss ze fréi ophält

Eng Standard-Linn op engem Desktop gesäit esou aus:

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

mdns4_minimal behandelt Multicast-DNS a reklaméiert all Numm, deen op .local ophält. E Kubernetes-Service wéi api.infra.svc.cluster.local hält och op .local op. Wann de mDNS-Modul NOTFOUND mëttelt, beendet d’Aktioun [NOTFOUND=return] déi ganz Opsschloss, amplaz weider un den dns-Modul ze goen, also gëtt den Numm ni un de VPN-Resolver geschéckt. dig geet komplett ëm d’Datei, an dat ass genee firwat déi zwee Geschier sech net eens sinn.

Dat ass de schäerfste Kontrast an dësem Problem, an et kënnt op ee Wuert an enger Konfiguratiounsdatei eraus, déi méi al ass wéi deng VPN. D’Aktioun op [NOTFOUND=continue] änneren behält mDNS fir Drécker an lokal Apparater, wärend DNS den Numm ka gesinn. D’Linn duerch hosts: files dns ersetzen funktionéiert och a ass méi grob: et fält d’.local-Opléisung fir den Drécker ewech, deen s tatsächlech benotz.

Nimm, déi an genau engem Netzwierk liewen

Privat Zonen sinn op genau enger Plaz autoritativ. En AWS-Numm wéi ip-10-0-4-31.eu-west-1.compute.internal gëtt iwwer de VPC-Resolver vun där Regioun beäntwert, an nëmmen esou laang, wéi däin VPN-Endpunkt an der selwechter Regioun ass wéi d’Ressource. Verbann dech mat engem Endpunkt a Frankfurt, frot en compute.internal-Numm aus Irland of, an eng lokal Astellung wäert hëllefen: d’Zone mat dem Record ass vun do aus net erreechbar.

Sichdomänen erzeugen d’Spigelbild. E blosse service gëtt mat deem Suffix komplettéiert, deen de Resolver als passend ugesäit, an mat engem VPN-Link kann den lokalen Domän deen vun der Firma iwwerwannen. Frot mat engem Punkt um Enn of, fir d’Roden ewech ze huelen, getent ahosts service.internal.example., an wann dat funktionéiert, wärend de kuerzen Numm feelt, dann ass de Sichdomän um Tunnel d’Léisung, net d’Serveradress.

Gestioun Klienten fügen eng drëtt Schicht iwwer dem Resolver vum Betribssystem derbäi. E Windows-VPN-Profil kann seng eege Numm-Opléisungspolitik, Reegelen pro App an eng NRPT-Tabell droen, déi och gilt, wann den Tunnel aus ass. Applikatiounen mat engem eegene DNS-Cache, heefeg an .NET- a Java-Runtimes, behalen e verale Fehler nach laang, nodeems d’Kette reparéiert ass. Apple-Cliente konfiguréieren Split DNS iwwer Match-Domänen an den DNS-Astellungen amplaz iwwer resolv.conf, a Chromium oder Firefox am Secure-DNS-Modus kënnen de Systemresolver fir ëffentlech Nimm ëmgoen. Dem Microsoft seng Referenz iwwer VPN-Numm-Opléisung beschreift d’Windows-Säit vun där Politiks-Schicht.

Entscheeden, wéi eng Schicht ze reparéieren

Schaff vum Symptom zu der Schicht, amplaz Korrekturen an der Rei ze probéieren:

Zwou Zeilen droen de meeschten Gewiicht. En Timeout ass e Erreechbarkeetsproblem: de private Resolver äntwert net duerch den Tunnel, also préif d’Route zu senger Adress an ob den DNS-Server um Link deen ass, deen s mengs. NXDOMAIN ass en Autoritéitsproblem: eppes huet geäntwert an et kennt den Numm net, wat op d’Zone, d’Regioun oder e Resolver weist, deen d’Ufro ni hätt solle kréien.

Déi lescht Zeil ass déi, déi d’Leit iwwersinn, well béid Hälfte wéi Succès ausgesinn. En kuerzen Numm, deen anescht wéi den FQDN opgeléist gëtt, ass eng Suffix-Mismatch, an den Tunnel nei verbannen ännert net, wéi ee Suffix de Client schéckt.

Halt den Zoustand fest, ier s eng Konfiguratiounsdatei beaarbecht, fir datt s ka soen, ob d’Ännerung eppes gemaach huet:

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

Féier d’Kontrollen an dëser Uerdnung aus a stopp bei der éischter, déi feelt. getent a resolvectl query mussen iwwerenee stëmmen; wann getent feelt, wärend dig äntwert, bleif an der Opsschlossketten a loosst d’Routing a Rou. resolvectl status muss en DNS-Server an e Routing-Domän op der tun-Interface weisen. nsswitch däerf bei NOTFOUND net ze fréi zréckkommen fir de Suffix, deen s test. Den Numm muss an dem Netzwierk autoritativ sinn, un deem däin Endpunkt hänkt, getest mat engem Punkt um Enn. D’Applikatioun däerf kee eegene Cache an keng Secure-DNS-Iwwersteierung halen.

Reparéier nëmmen déi éischt Schicht, déi feelt, a féier duerno déi selwecht Kommandoen nach eng Kéier aus. Zwou Ännerungen op ee mol loossen dech net soen, wéi eng gezielt huet, an de nächsten Ausfall fänkt d’Enquête vun Null un.